Do you really know what motivates your dev team?

The following is a guest post from Anton Drukh, who led the engineering team at Snyk for 5 years.

-------------------------------------------------------------------------------------

I spent the past five years on an incredible adventure: building the engineering organization at Snyk from 1 to 150 people, while the company itself soared from the seed stage to a $4.7 billion valuation.

What I discovered along the way is that most of what’s written about engineering leadership misses one crucial insight. Too often, we view people as interchangeable (and occasionally inconvenient) tools in the quest to build great technology.

But real engineering leadership is about solving people problems in a technology setting – not the other way around.

This is a radical mindset shift from the orientation of an individual contributor or even an engineering manager: one that requires an understanding of motivation, and a commitment to building a system and culture designed to promote ongoing engagement.

Here’s what I’ve learned.  ‍

First principles in solving people problems

There are lots of good resources on people management, but I often find myself returning to the question of motivation. Simply put, what drives engineers to do world-class work? ‍

Daniel Pink’s argument – that autonomy, purpose, and mastery are the keys to understanding human motivation – resonates with what I’ve learned over the course of my career. Every engineering leadership decision that I made at Snyk was filtered through this lens: will it make engineers more aligned and self-directed, more fulfilled, and more effective? ‍

Autonomy

‍There’s an understandable misconception that autonomy means total independence. But that’s simply not realistic in an engineering context. Even the most thoughtfully designed team structure can’t (and shouldn’t) completely avoid dependencies.

I would argue instead that real self-directedness and empowerment come from knowing what’s expected of you – and what you can expect of others. The problem gets harder as a team grows because it’s more daunting to navigate the roles and responsibilities of different stakeholders. But it’s a problem urgently worth solving.  

That’s why at Snyk, we made two decisions early on:

• We structured our engineering team around specific user problems (rather than parts of the code base). I’ll dive into the decision to cultivate a product-oriented mindset shortly – the tl;dr is that autonomy works best when you not only have control not over your day-to-day work, but can identify deeply with the definition of success. For example, a surgeon can’t take full pride in an operation without considering what success means from the patient’s perspective (which might involve not just clinical outcomes but subjective feelings of wellness). Similarly, aligning our engineering teams with success from the perspective of our end users laid the groundwork for truly self-directed decision-making and prioritization.  
• We introduced a simple, clear career ladder. Actions as straightforward as clarifying the distinction between “Software Engineer” and “Senior Software Engineer” provide team members a strong sense of professional growth and what is expected of them.

These considerations weren’t top-of-mind when we were 10 people. At 100 people, we couldn’t have lived without them. Counterintuitively, I’m convinced that absolute clarity around expectations and the definition of success – embodied in a clear organizational structure and professional growth path – is a precondition for real autonomy.  ‍

Purpose

‍Engineers derive motivation from vastly different areas. Some are motivated by continuous improvement. Others are motivated by compensation, or public acknowledgment, or the inherent mission of the company.

But one thing that we all have in common is the desire to know where we’re going. We want to know that our individual and collective journeys have a purpose: that the hard work we put in today will help move us meaningfully forward in some way.

Our career ladder also served us well in creating a clear, vivid picture of what progress looked like for team members. It helps team members know that they aren’t just reliving the same quarter again and again, and articulates what the organization values and why. ‍

Mastery

‍Engineering leaders are often (rightfully) skeptical of managerial overhead, worrying that too many layers will dissipate accountability and create unnecessary complexity. But I actually came to the opposite conclusion in my own journey. When we hit somewhere in the 50 or 60 range, we introduced second-line management.

At the time, I was managing 10 people directly. But I sensed that the people on my team were paying the price of my fragmented attention. Even if I felt I was capable of that number of direct reports, the people on my team deserved more than 10% of my time.

Introducing second-line managers enabled our organization to invest substantially more in the coaching and success of individual contributors, making them more successful in turn. It also allowed me to look further ahead and provide a longer-term vision for the organization.‍

Case study: structuring the team to unlock engineering potential

This framework for managing team members – with the goals of promoting self-directedness, purpose, and ongoing improvement – was a critical input in major engineering leadership decisions at Snyk.

As I hinted at earlier, one of the big forks in the road that we faced at Snyk was how to organize our engineering team.

Quick background: in my experience, engineers almost always care passionately about doing right by the customer. But I had seen firsthand how good intentions fall short when people are put in a context where it’s hard for them to do the right thing. For example, with technically-organized teams (e.g., a frontend and backend team), it’s not uncommon to see issues “ping pong” back and forth without clear ownership or resolution.

It’s not that engineers don’t care about a customer bug or issue. It’s just that no one is incentivized to pick up and solve the problem – especially when there are other fires blazing all around.

So instead of clustering around technical areas of responsibility, we ended up organizing our engineering teams around personas and problem domains: for example, our Security and Developer teams respectively build products for those key stakeholders. Teams exist because a problem domain exists in our space, and this group is uniquely positioned to solve it.

Organizing our product team in this way aligned well with motivation drivers:

• Autonomy: our teams are product-oriented and largely independent, consisting of a product manager, an engineering manager, and 2-5 engineers. They are empowered to make investment decisions and tradeoffs in the context of delivering value in the context of their problem domains.
• Purpose: organizing around user problems to be solved and personas instills tremendous purpose into the work – connecting engineers to the larger mission of the customer and fostering genuine empathy for his or her challenges.
• Mastery: one of the benefits of focusing on one problem area for a sustained period of time is a deep, fine-grained understanding of that domain. And by owning a problem end-to-end, engineers gain experience with all systems that touch on that experience.

Don’t get me wrong: there are absolutely costs (like redundancy) associated with organizing a team around problem areas. You’re much more likely to have to spend time managing issues like multiple teams building the same billing system or multi-tenancy system.

But I’m a firm believer that a good decision is not the one that has the fewest drawbacks. A good decision is the one where you know the benefits and the costs. In Snyk’s case, organizing our engineering team around jobs to be done enabled us to promote alignment and engagement – and ultimately unlock the full potential of our engineering team.‍

Building systems to solve for people problems

As helpful as guiding principles are, they’re unlikely to become the main currency of decision-making until they’re encoded in self-reinforcing systems within the company. At Snyk, our KPIs and our culture represented two such systems. They provided a common frame for us to evaluate tradeoffs and ensured that we continuously optimized for the success and health of our engineering team. ‍

Our KPIs. Snyk lives by three categories of engineering KPIs: quality, predictability, and team growth and happiness. Quality and predictability metrics are fairly standard amongst engineering teams; team growth and happiness metrics are not. But they’re essential for keeping us relentlessly focused on how well we’re meeting the needs of our team members – both on an aggregate level and especially when we factor in the company’s goals around diversity.

We introduced team happiness metrics because we never wanted to find ourselves in a position where engineers were “voting with their feet.” So instead of using attrition (a lagging indicator), we instead decided to use forward-looking signals of engagement and sentiment. Elevating team happiness to a core company-level KPI – alongside, for example, our commitment to three-9s – ensures that it’s a central consideration of any strategic decision made on the engineering team.‍

Our culture. Maintaining a healthy and productive culture in high-growth mode requires a culture of experimentation and iteration. This is sometimes painful as it involves people having to give away their Legos.

Any technical incident at Snyk involves a writeup from the team involved. But our weekly engineering meeting – a longstanding tradition – had always been a chance to bring up recent post-mortems in the spirit of technical discovery.

At a team size of 12, these meetings were spirited group discussions. Little by little as the team grew, they gradually morphed in static lectures, losing so much of what made them a useful forum in the first place. So we made the decision to turn back time. We made weekly meetings group-level, so that we have three weekly meetings.

The decision was painful. But it was the right call. It restored intimacy, discussion, and ultimately influence on one another to our weekly meetings. Decisions like this require a culture that values continuous experimentation and improvement.   ‍

Parting words

When friends used to ask me what it was like to transition from developer to engineering leader, I would joke: “Thank you to my left arm muscles for bringing me this far. Now I need to use and grow my right arm muscles.”

In retrospect, that’s a pretty accurate analogy.

Being an effective engineer is all about solving technical problems in the context of people. In contrast, world-class engineering leadership elevates people to the spotlight: how to get the best out of them and ensure that they’re positioned for success.

Ultimately, unlocking engineers’ potential requires deep sensitivity to the drivers of motivation – and a set of organizational systems that reinforce and build up the human capital of the engineering team.