There doesn’t have to be tension between engineering managers and individual contributors

Engineering managers and individual contributors usually want the same thing: to produce quality work in a way that feels creative and collaborative, all while doing so in a predictable and sustainable way. I’d even say you would struggle to find someone who doesn’t want this type of work agreement. 

It’s also important to note that there’s healthy tension and unhealthy tension between engineering managers (EMs) and individual contributors (ICs). Great teams work well when they have a healthy amount of tension — they ask questions and challenge each other respectfully to get to the best solution.

But there are a lot of moving parts to make the EM–IC relationship work, and it’s the friction between these parts that can create unhealthy tension.

Reasons why there might be tension between EMs and ICs

When it comes to measurement and evaluation, EMs and ICs have different perceptions of what  adds value. This can be based on several tension-causing factors.

(1) Different goals based on roles. The jobs themselves bring inherent tension. EMs want to make sure that things are predictable and the team is operating well. ICs focus on doing creative work that is, at times, hard to predict and deliver with quality. One wants to measure things that the other can’t always deliver predictably.

(2) The partition of work. EMs and ICs are tasked with thinking at different levels. EMs think one rung higher than ICs — about coordinating many people and roles such as ICs, product managers, and designers, and shielding ICs from the inputs that come from all of those perspectives. 

These worries don’t always correspond to what ICs think about — such as tech debt, their development process, their CI/CD flow. It’s not that EMs don’t worry about these things; it’s just a different hierarchy of worries. 

(3) Bad EMs/Bad ICs. Sometimes there are bad EMs who don’t think their job is to create a team of ICs who are unblocked and functioning well. This can create a very adversarial relationship, where a manager says, “I need this done now,” and an IC says, “You don’t understand what it takes to get that done.” 

Conversely, there can be bad ICs who are hard to work with and lack empathy for the concerns that EMs worry about. This can lead to the “managers are just pushing paper and don’t actually ‘do’ anything” narrative.

(4) Measurements that “don’t matter.” EMs measuring things that ICs feel don’t matter creates a disconnect. I’ll talk about measurement more later, but the tension here comes, in part, because of the nature of our industry. 

Software engineering is creative work, which is by nature difficult to measure. Yet, the EM has to deliver quality products on time, which requires some degree of measuring. 

(5) Well-intentioned processes gone awry. EMs might put in place processes or guardrails to help their teams ship things faster with higher quality, but they end up being too time consuming, inefficient or onerous for the team. I’ve seen teams with so many onerous process-related tasks that they don’t even feel like they do much work. It’s just checking a lot of boxes, and the ICs are miserable.

So, what to do? You have to align on measuring what matters.

A great place to ease the tension is within the developer workflow or the software development life cycle — the process of taking things from concept to launch. Within that life cycle:

Measure things that matter, not the BS stuff. Avoid what we know hasn’t worked in the past in our industry — tracking lines of code, pull requests, happiness sentiment.

Measure things with consistency that correlate to team performance. It’s important to measure from the real work ICs are performing instead of just gathering statistics. Focusing on the team’s performance focuses the measures on how everyone can improve versus calling out individuals and creating a toxic stack-rank environment.

Measure in a blameless culture so that if something goes wrong, you’re not pointing fingers. A blameless culture reinforces a focus on the team’s performance, not the individual’s. You talk in terms of the team’s outcomes and how to improve as a team.

Automate, automate, automate. Our industry has almost always moved itself forward because we automated away the human, error-prone things. If you find yourself saying “Make sure you always…” that’s an indication that it’s time to automate. Automate the guardrails instead of making manual processes. 

Automate the developer workflow, CI/CD, alerting, the definition of done, etc. You can even think of it as linting for the developer workflow, where you build rules between alerting, CI/CD, issue trackers, and code hosting tools to automate things that will help your team be more efficient and effective.

Finally, be open and transparent about what matters, what you are measuring and what your goals are. In doing so, you’re helping to drive a team effort that everyone owns. It’s a bottom-up approach where you declare that you want to get better. You’re asking the team, “Do we believe in these things?” to ensure you measure what developers want to be part of, and they have the ability to see how they’re doing and where they have opportunities to improve.

And by doing this, you’re measuring the right things. You’re measuring the things that people are actually working on, and you’re using those measurements to evaluate your team. That’s the stuff that matters.

It’s not easy to keep tension in check before it veers into an unhealthy state, but it’s critical to do so. EMs and ICs will respect each other more for it, and you’ll get a more collaborative, efficient team as a result. And within efficiency, the real gains for your organization start to materialize.