WHOOP is an ambitious and innovative company powered by equally ambitious and innovative engineers. We want to nurture that aspect of our culture by having it reflected in our values. We set out to define a set of principles that empowers our team to be effective stewards of that spirit.
1. Programmer mindset → Product engineering mindset
One thing we talk about here at WHOOP is the progression from the ‘Programmer mindset’ to the ‘Product engineering mindset’. More often than not, engineers start their careers in the programming mindset. This is where they cultivate and refine their programming fundamentals by working on prescribed and focused tasks. Once they acquire a grasp on those fundamentals, the next step is to integrate those skills into the needs of a fluid and fast paced commercial software company. This often transpires into broadening the autonomy of that individual.
We drew a lot of inspiration of what the definition should look like from Gergely Orosz’s post on ‘The Product-Minded Software Engineer’. Our high level take is that engineers need a firm grasp on the product and the problem it’s attempting to solve in order to calibrate their intuition. On top of that, they possess a granular understanding of how to apply trade-offs pragmatically.
2. Tooling over processes
First and foremost, not all processes are bad but the creation of them is often abused and you only need a small handful of them to bring your team’s delivery cadence to a snail’s pace.
A lot of processes are created in response to something you don’t want to encounter again. It’s a pretty low effort to create a process but the fact remains it requires a piece of someone’s cognitive load in perpetuity to follow. This is an important trade-off to think about when considering how you want engineers to budget their time. Netflix articulated this problem well in their culture deck and we subscribe to the mindset they laid out.
One way to drastically reduce or perhaps entirely remove that cognitive load is solving the problem the process was meant to address with tooling. This route of course has the exact opposite cost of adding a new process in that it’s a much higher price up front but saves time and therefore money over the long term.
Favoring tooling over processes will not only save you resources in the long term, you’ll have much higher compliance because a machine will be carrying out the intent, not a human. More importantly though, the day to day of building software will feel nimble because engineers can allocate more of their focus to delivering value to customers instead of checking boxes and memorizing processes.
3. Polyglot → Monoglot
We’ve prioritized one language to build all of our backend services in. We see this as a strategic and tactical advantage despite the understanding that different languages are better suited for some problems than others.
Every product and team has unique nuance and a set of use-cases that require proprietary tooling. Simply put, having multiple languages demands that most, if not all of that tooling to be replicated. As an example, WHOOP has a five person infrastructure team dedicated to developer tooling and common libraries. Spoiler alert, we’re not even close to being adequately staffed. The level of investment for just one language is massive.
By focusing on creating leverage around one language, we enable engineers to increase their focus and efficacy on solving product problems and delivering value to our members.
4. Embracing (but prioritizing) burning fires
One of the byproducts of having a lot of traction with a product in a growing company is having to choose which critical priority should come first.
The mindset in which you approach this reality is key to being able to manage it. Having the wrong point of view will understandably translate into feeling overwhelmed or that everything needs to be fixed before other progress can be made. A consistent test for every engineer here is absorbing as much context about what the company is trying to accomplish, paired with the complexity to put that fire out. This is a skill area that we spend a great deal focusing on in 1:1’s.
The ability to correctly prioritize and advocate for which fires to put out and when is arguably just as valuable as perfecting one’s coding craft. We hold this in high regard as it empowers us to delegate large areas of autonomy and responsibility. This in turn unlocks our ability to scale up teams quickly.
5. Product oriented teams
Within software, we align teams around product domains. Our intent is to have teams develop deep expertise in the area of the product they own. This ties into our desire to promote a product mindset across all of our engineers.
As a result of our teams being product forward, there is less emphasis on chasing down the latest and greatest technology for technology’s sake. We are intentional about guiding our engineers to draw most of their professional fulfillment from delivering value to our members and genuinely changing the way the world thinks about managing their health.
As an example, WHOOP is the first wearable to be used in a stage 3 clinical trial for COVID-19. We didn’t get there because we chose the best or newest technology. We got there because we spent a great deal of our energy acquiring a deep understanding of a problem the entire world was facing. From there, we looked to see how technology could enable the solution rather than prioritizing technology and searching for problems it could solve.
6. Infrastructure teams & Developer leverage
We have a few infrastructure teams that focus on platform oriented projects that enable product features to be built in a straightforward way. Additionally, one of our infrastructure teams focuses on making developers more productive by leading and maintaining toolset development. This ranges from common libraries to monitoring & alerting built in to everyday components.
The meta goal for these teams is to make developers at WHOOP more efficient and enable them to focus more intently on the product domains they own. Another way to think of these efforts are these groups are the product teams for the entire engineering team.
These teams actively seek out where they can add value by engaging with their peers and understanding how they work and the problems they face. Even our infrastructure teams are product minded!
7. Automated testing over manual testing
While we believe that engineers should own and be responsible for testing, it’s obviously more efficient to have automated testing largely achieve this goal. Beyond the efficiency of it all, automated testing increases our confidence to take calculated risks and increases our delivery cadence.
Our automated testing approach encompasses unit tests, API integration tests, and UI based tests for mobile and web applications.
Another important benefit of having engineers own quality is it promotes them to design and build software that is more straightforward to test. It also notably keeps the developer that much closer to the product experience and yields higher quality feature output.
8. Exchange dollars for iteration speed
We’ve been fortunate to have consistent growth in our business which has unlocked our ability to use money to solve certain problems or defer larger refactoring efforts where rapid solutions are a higher priority.
Where it makes sense, we will easily spend money to put a band-aid on something we can come back to and properly fix later if it means the outcome is delivering value to customers sooner.
The biggest take away for us is it’s ok to be inefficient in the short and medium term as long as it is in pursuit of growth that is likely to occur.
9. Establish clear and flexible paths for career progression
One of the most obvious things about professionals is they desire and appreciate clear and concise definitions of what progression looks like.
At WHOOP, we made a big investment in defining what professional growth looks like and weaved it into our culture early on. Our approach is to establish two main career tracks that would cover different career interests; Individual Contributors and Engineering Managers.
Individual contributors (IC) are engineers that want to focus mainly on technical work including design and writing code. That being said, individual contributors can still exert leadership through mentorship, setting technical directions, and organizing large scale projects that span teams and departments. The more senior an IC is, the more of these leadership characteristics we expect. Senior ICs are expected to work with product managers and designers to advise and shape the milestones of projects flowing into engineering as well as articulate progress outward. Senior ICs are also expected to guide architecture decisions and/or establish consensus amongst the teams.
Engineering Managers (EM) are responsible for the career progression of the IC’s in their team. In some cases, the EMs will share the same technical background as ICs on their team so they may also take on the responsibility of mentoring these individuals. If the backgrounds do not align, they will facilitate the cultivation of IC’s progress by partnering with other senior leaders within WHOOP to provide mentoring.
Engineering Managers are also responsible for the successful execution of technical and product projects within their team. They often drive and/or participate in one or more large scale technical projects that are critical for the business. This may take on the form of helping shape product specs, architecture & design, technical direction, and staffing decisions. EMs also contribute their point of view on how to map top of mind business objectives to technical projects and initiatives.
Another key element to how we approach career progression is we set up a matrix of the different levels within the two career tracks and pinned corresponding levels across that matrix to the same salary band. This enables folks to be eligible to earn the same compensation as their peers in other tracks. Since we value each of these career focus areas, we apply the same compensation framework to each level.
10. Ownership through and through
Product minded engineers quickly learn that in order to be successful, ownership must be core to how they approach product development. We also view the spectrum of ownership as expanding past shipping a feature to a customer. We obsess over the performance and impact of the products we build.
At WHOOP, engineers take ownership of technical design, development, testing, deploying, and supporting the features they build. Code or engineering efforts are not thrown over a wall to be handled by disparate teams, but rather driven over the finish line by the same individuals who have driven each step in the development process. This builds well rounded engineers that are capable of a high level of autonomy and promotes mastery over their product domain.
Because ownership is at the root of our development culture, people are empowered to drive product improvements themselves, in part because they are responsible for their product domain but also because they understand the impact they can have when holding a high level of ownership.
If these principles resonate with you, check out our software team openings.