The Happy Matrix: Unlocking the First Rule of Exceptional Engineering Leadership

Recently, I posted about a recruiter who reached out to me with a Senior EM role that required managing 10-12 engineers and hands-on coding 50% of the time. This was a role set up to fail, and my post about it on LinkedIn generated quite a response. 

The top-notch technology companies I’ve been a part of, like Microsoft, Adobe, and Amazon understand what it takes to run successful teams, and structure their role requirements appropriately. But the same cannot be said of technology-second companies, like fintech, healthcare, retail, and so on.  This creates a toxic feedback loop of hiring EMs who are then quickly overwhelmed by the job requirements, leading to aspects of the job suffering, usually starting from their engineers not getting the support they need. This then results in disaffected, toxic teams, a lack of engagement, and lowered productivity. 

 Then those very same hiring managers who set up the role for failure wonder why the team is failing, blaming the poor EM for the miss. 

 Today I’d like to explore what it is a top-notch Engineering Manager should be doing on a day-to-day basis. I will also explore what happens if those things don’t get done. 

Manager Priorities 

I once asked a skip-level manager at Microsoft what my priorities as an engineering manager should be. He said: 

1. A happy team. 
2. Customer love. 
3. Don’t ship stupid. 

I’ve thought a lot about what he said. There’s a lot of wisdom in these priorities, but each of these categories can easily expand into an article of its own. Note, though, that these priorities are in priority order. In other words, the priority for an engineering manager should be to ensure that their team is “happy.” 

 What does “happy” actually mean in this context? This is the subject of the first part of this three-part series. 

Let's dive in! 

 A Happy Team 

 A lot of philosophy and psychology books have been written about happiness. Somewhat less so in the context of business settings, with the notable exceptions of the “follow your passion” crowd and the contrarian and terrific “So Good They Can’t Ignore You” book by Cal Newport. The common theme is for people to be happy in their work, a set of requirements need to be met. 

Vision

The team must believe that what they’re doing matters. In other words, they must be clear about not just the team vision, but the vision of their organization, and they must subscribe to that vision. This is one of the primary jobs an Engineering Manager must take on. The EM is in effect a translator between business-speak of Marketing, BizDev, and Product Management, and the more technical language of their direct reports. They must explain this vision to their team and show them why it matters in the wider scheme of things. 

 These explanations will typically occur in prioritization meetings, in team meetings, and in one-on-ones. It’s important for the EM to encourage questions from their team members along the lines of “How does what I’m doing now map to the company’s vision?” They should also encourage challenges to this mapping, as in “I think X would support the team vision far better than Y.” 

Prioritization

The team must believe that they’re working on the most important thing in service to that vision, and that they have a voice in deciding what that most important thing is. Whether it is organizationally feasible or not, the Engineering Manager must be able to empower their teammates to question priorities, offer alternatives, and ruthlessly raise and prune work that’s not in the service of the greater vision.  

The EM and the team should constantly ask themselves three questions: 

1. What is the most important thing I should be doing right now? 
2. Am I actually doing this most important thing? 
3. If not, why not? 

The standup meetings are a great medium for these questions.  

 Work-Life Balance 

They must have a sustainable work-life balance. No death-marches. No weekends. No late nights. Sure, sometimes that might be necessary, but those times should be very very rare. It is the Engineering Manager’s job to make sure that this balance is struck by appropriately setting expectations with the team’s stakeholders, managing in-progress work by wisely allocating team resources, and surfacing emerging risks to the stakeholders as they come up instead of trying to absorb them through overtime.  

 A team death-march is primarily a failure of leadership, except in specific industries such as gaming, where it seems to be mostly a way of life. The vast majority of IT domains should not be asking for overtime, much less requiring it. Studies have shown over and over again that overtime does not actually yield greater productivity if done for longer than 1-2 weeks at a stretch. The engineers get tired and bug density increases. Then they have to spend more time fixing the bugs introduced at 9pm on Saturday than if the person in question had just stayed home. 

Career Development 

The team members must be clear about what the path to the next career level is for them. In other words, they must understand the reason they aren’t at the next level already, and what specifically they need to work on to get there.  

It is the Engineering Manager’s job to make this clear, and to shepherd them along the path thus laid out. This means having clear role guidelines and checking in with them often to identify growth areas and act on them through specific, actionable tasks. 

Psychological Safety 

The team members must feel psychologically safe within the environment of their team.  

1. The Engineering Manager must set up this dynamic through leading by example, through proper and timely praise, and through showing that mistakes, when they do happen, do not result in blame games or public shaming.  
2. Additionally, the Engineering Manager must be generous with assigning credit for successes while taking the blame for failures onto themselves.  
3. They must also shield the team members from any toxicity in the wider org. That means standing up for them when they have a negative interaction, or empowering other team members to do this in their stead. 
4. They must encourage and protect diversity of genders, cultures, races, levels, and thoughts on the team. A diverse team that accepts each others’ differences functions better because it approaches the problems it faces from a wider array of perspectives and ways of thinking. But those will only surface if the individuals involved feel safe expressing them. 
5. They must get involved in and mediate any personality conflicts on the team in a way that de-escalates the situation while not alienating the team members involved. 

Performance Management 

The EM must guard the team against underperforming members. This takes several possible forms, from working one-on-one with the underperformer, to soliciting champions on the team to help the underperformer with the issue they’re tackling, to managing out the underperformer, obviously the very last, and very undesirable step. 

The key thing here is to make sure the team isn’t burdened by having the carry the underperformer. In effect that means that the amount of work placed on the team tends to align with the number of team members. If one of those team members isn’t carrying their share, that means more work for everyone else. That situation may be acceptable if the underperformer in question is on the improvement path, but if no such improvement is evident it’s important for the EM to act, and be seen acting, lest the team members get disaffected by the unfairness of the situation. 

 Process 

The team must have a day-to-day process they buy into and that doesn’t get in their way. It doesn’t matter what that process is (though I have some strong feelings on that subject) if the team is happy with it and doesn’t feel like it’s management overhead. Scrum, Kanban, Waterfall, whatever: the EM must make sure that the team has set something up, that the process is clear with the team’s stakeholders, and then must work day-to-day to protect the team against process entropy. 

 Conclusion 

Concluding part 1 of this series, I hope you can see that even the first priority of an EM, Happy Team, is no small task. There are a lot of moving pieces involved, and each take conscious, deliberate thought. And we haven’t even gotten to all the other parts of this priority stack. 

 Stick with me for next week’s part 2, Customer Love. 

What about you? What priorities do you set for yourself on your team? How do they align with what we’ve discussed here?