Every piece of software begins with a single line of code and grows from there. Walmart.com was no exception to this. We launched a slew of features over the last couple of years and our sales grew at a phenomenal rate. For the user transaction flow alone (Cart & Checkout) — our engineering team doubled in size and along with it — so did our codebase.
With growing pains, software entropy kicked in and product developers had to manage several cross-cutting concerns along with their feature work and timelines. To be efficient — there was a need to build common abstractions, interface with other internal platforms, fix common issues and leave no windows broken. For this, we need to solve problems holistically to handle multiple teams and applications instead of just the projects at hand. To help address this in a more focused manner, we formed a dedicated team to help improve our platform.
The key is to scale our platform for both our developers and end users.
But what does improving the platform really mean?
It is too broad of an avenue to chase after and what we need here is direction and focus. To help answer this, start with these three simple questions
To quote Simon Sinek — Start with “Why?”
“Why does our team exist?” — Seems like a fundamental question and sort of a no brainer, right?
However, digging deep and clearly defining your core purpose and mission is foundational to figuring out what you do and don’t do in your team. It is essential for every team member to have clarity in their role, reason it exists, and thereby find real meaning in the work they do.
Once we know the “Why?” — The next step is to break it down further and identify the “What?”
“What are our key focus areas?”
With this, we list down key goals that help achieve our overarching mission. These goals help provide much needed focus, that in turn translates to identifying the right avenues to tackle.
Now that we know our “Why” and “What” — a key element that guides our execution is knowing “How?”
“How do we operate?”
We now define our core values and operating principles that help set the right culture and mindset in our team.
Let’s now see how we used “Why? What? How?” questions to lay the foundations for our platform team.
Our Mission — “Why does our team exist?”
“To enable developers to build scalable applications with high speed, quality and performance”
Goals — “What are our key focus areas?”
“The speed at which a company innovates is limited by its iteration speed.” ~ Erik Bernhardsson
The core tenet of this philosophy is that it is important to move fast and get things out there for users and then iterate on top of it based on learnings. For a developer, this pretty much means being able to deliver features faster and with confidence.
Speed up different phases of software delivery for a developer.
Our focus can be broken down into 2 parts here:
Development Workflow — The goal here is to make local development and testing as fast and painless as possible.
Infra Specific — Beyond merging a pull request, getting this out to production involves working with various tools and infra. This requires strong collaboration between teams/platforms.
On-boarding a new employee isn’t tremendously hard, but it is high-impact. Done well, it will improve team-work, give employees a sense of belonging and decrease turnover.
It’s important to lower the barrier to entry for new developers by building the right tools and documentation that enables us to onboard faster and say no to tribal knowledge.
A platform prevents teams from reinventing the wheel by solving common problems and enabling us to be more efficient overall.
To figure out common problems, start by understanding developer pain points and friction areas that cause slow down in development. We can get this info both qualitatively by gathering feedback and quantitatively via engineering KPIs. This combined with an understanding of the future direction of the product can help shape a great roadmap and pick the right battles to fight.
Make it fast by default —Performance optimizations should be baked right into the application. The goal here is to give developers the right capabilities to make their features performant with least effort.
Collectively define best practices and architectural guidelines. Advocate and encourage them via tooling, reviews, documentation. Provide coaching, participate in discussions and help engineers deliver high quality code.
Ensuring we have the right tools/process in place to empower developers to validate and check for common pitfalls like code smells, bugs and perf degradations eg. Regression checks, CI hooks, bots and synthetic tests for performance.
“The secret to becoming a 10x engineer is to help 10 engineers around you to become twice as productive.”
Sharing your knowledge, experiences best practices through tech talks and documentation is a great way to inspire and elevate our team’s collective expertise.
Define best practices and architectural guidelines. Advocate and enforce them via tooling, reviews, documentation. Provide coaching, participate in slack discussions and help engineers deliver high quality code.
Participate in architectural design reviews for new functional projects and propose best practices/common ways of development across track teams.
“No idea is true just because someone says so. Test ideas by the evidence gained from observation and experiment. If a favorite idea fails a well-designed test, it’s wrong!”
- Prof Richard Feynman
As a platform team it’s important to try out different solutions, embrace newer technologies and think out of the box to keep improving and break new ground. Whenever we identify promising approaches to any problem, it’s encouraged to try them out through POCs, review results afterwards and make choices accordingly. Key features should always be AB tested and analyzed before complete rollout.
Users evolve and code does too. What was a pattern a year back could become an anti-pattern in future. New requirements come up constantly while a product evolves and an architecture that was great earlier could very well be a limiting factor to honor a new requirement. In order to arrive at the best solutions for problems, being able to question existing choices is essential and key part of the experimentation mindset.
Principles — “How do we operate?”
“It’s all about leading from any position and in any direction. The whole structure of organizations today requires people to step into a leadership mindset, drive ideas, projects and initiatives from whichever level they are — the scale is what differs”
Accountability is holding yourself responsible for what you say you will do. It is about following through and delivering on things that you own. Doing so makes you feel trusted because the team knows you will deliver on your commitments. This builds a chain of trust which is the foundation for any successful team.
“Lots of times we have very good ideas. But they’re not as good as the most important thing we could be doing for our customer. And we have to make the hard choices.”
~ Sheryl Sandberg
Know why we are doing what we are doing and the impact it brings to our developers. Now ruthlessly prioritize our short-term goals and activities so that they support our long-term vision.
Famously popularized by Sheryl Sandberg — always ask, “Is this absolutely necessary to do?” This mindset helps us prioritize and focus on work that matters the most. Know your constraints (timelines, dependencies etc.) and estimate ROI before picking up any task.
You tend to get 80% of your impact from 20% of your work.
The 80/20 rule helps focus your attention on the things that can have the biggest impact on our goals. By focusing on those things, you can have a much better influence and impact.
It’s really important to get things out there for developers/users, learn from it and iterate on top of it. This helps us validate ideas faster, course correct of needed and eventually keep getting better over time.
Choose your battles wisely. It’s a cliché, but it’s true. Complaining about things not fully in your control only leads to negativity and resentment. Success comes when we stop worrying about those factors and instead focus our attention on things we can control.
The platform we build is our product and teams we support are our users. We collaborate like an Internal Open Source (aka Inner source) Team. We do not want any one person or team making decisions on how we solve problems for all teams. The key is to share your plan with teammates and encourage open feedback and suggestions through design reviews or other communication channels.
Make changes less painful by supporting teams through it. Platform level changes rely heavily on communication for announcing new features and breaking changes. Always look into ways to have a gradual migration path for any big changes that might affect multiple teams.
“Without data, all we have is an opinion” ~ Edward Deming
Strong teams are data driven. Capture data and develop metrics to drive decisions, priorities and evaluating trade offs. Value data and facts over assumptions and opinions.
No question is off the table, no question is a bad question. The only way for teams to develop a shared understanding is for them to ask questions and distinguish facts from assumptions. This dialogue is critical in order to get a firm understanding of what and how to get things done and to help drive building a better product.
“Allow your intuition to guide you to a conclusion, no matter how imperfect — this is the ‘strong opinion’ part. Then –and this is the ‘weakly held’ part– prove yourself wrong. Engage in creative doubt. Look for information that doesn’t fit, or indicators that pointing in an entirely different direction. Eventually your intuition will kick in and a new hypothesis will emerge out of the rubble, ready to be ruthlessly torn apart once again. You will be surprised by how quickly the sequence of faulty forecasts will deliver you to a useful result.” ~ Paul Saffo
The ability to have strong opinions while being open to change— encourages different points of view, surfaces conflicting opinions that might poke holes into our current options and enable us to learn and iterate faster.
It’s not just about “failing fast”, but equally about “winning fast”. The goal is to conduct quick, cheap experiments to gain invaluable insights and change course based on integrating new learnings into the system.
It is important to treat our skills as dynamic things which need continuous upkeep and upgrading. The key is to constantly learn and evolve to adapt to new situations. In short — Read, listen, accept what you don’t know, do things and teach.
We are one team. We should constantly put ourselves in the shoes of other developers. Questions can help a lot here, for example -
Building a diverse team enables us to ask questions from different vantage points, empathize better and help make the right choices for our developers.
At the end of the day we are just a bunch of humans working together churning out a pattern of zeros and ones for the computer to make sense of. It’s important to see the human side of people, appreciate diverse opinions and respect each other’s differences. The best products are always built by great teams, not just great individuals.
Over the last couple of years since forming the platform team, everything we worked on was guided by our mission, goals and principles. It really helped provide us clear focus and direction irrespective of changing priorities at organization level. Improving site speed by over 50% was one of our major accomplishments. We did this without impacting existing features nor doing any huge rewrites that impacted other projects. You can learn all about it in this talk. Few other key contributions include enabling faster local development with a new mono repo setup, storybook integration, automated perf & a11y checks, streamlining logging/monitoring across web-apps to get to root cause of issues in 10 minutes and improved tooling.
I want to leave you all with one last note — platforms and software evolve and what we build today will most certainly change and become obsolete over time. This is just progress. The things that we ultimately carry forward with us are our learnings, friendships and memories. It’s important to foster the right culture in the team to enable engineers to be happy, take pride in what they do and grow together as a team. Work hard but do remember to have fun. Cheers!
Thanks a lot for reading. If you would like to hear more about a specific area or share your experiences on building up teams, do post a comment below or reach out to me on twitter.