It's an infinite journey, but never forget the ultimate goal: you build highly effective, durable teams that ship software.

Effective means the team is productive, and executing in the right direction. Autonomous, aligned, making good decisions but also knowing when to escalate. Durable means the team’s morale is high, they buy into what you're doing and how it's being done, they feel a duty of care and sense of ownership to the whole. As a result they are committed.

From outside the team durability can seem more of a binary switch. It’s fine until it’s not, and suddenly HR is getting involved. But along that path there are a million different actions and tradeoffs in all to make and you’re responsible for all. That ambiguity and gray area is the joy and pain of management. It's also why we created this guide to touch on some more practical aspects.

It's extremely easy to get caught up focusing on inputs. As an example, it's very easy to optimize for short term happiness and your own popularity. You can let everyone manage their own time, pick their own projects, refactor at will. It's easy to spend more time building systems that maximize engineer output than doing the unsexy part of building the actual product itself.

This will come back and bite you when company deadlines hit and your team can’t map their technical work to business priorities. When they get frustrated that their technical excellence isn’t translating into business success. When their individual performance scores are average even though they've been writing loads of code. So remember the ultimate goal: building highly effective and durable teams that ship software.

If you're coming in to management from an engineering role it can seem a perplexing thing. Crafting software is a much more ordered exercise, and the process of learning how to be a software engineer is really learning how to bring that order. You take some wobbly half-baked product spec and lovely-looking but impractical Figma files and turn them into something that not just runs well but is crafted well. It's tested and resilient, it can be updated and extended without effort. At the end of the day, it's easy to know and be satisfied with a good day's work, because the thing you built does what you intended it to do.

Management is not like this: it is all gray areas, and this is one of the hardest things to accommodate for when starting as a manager.

You may try to develop architectures and processes for your team, and deal with them as you'd deal with software. Abstracting complexity away with simple, regularly invoked interfaces like standups and weekly syncs. Creating deterministic systems with clear, measured inputs and outputs, like SMART goals at your 1-1s. You'll try to minimize side effects by explaining everything in detail.

The obvious problem is that people are not software. They process instructions differently and at different speeds; they will break your well-designed processes in unexpected ways, or they'll openly dislike them and say they're a waste of time. Side effects with teams of people are misunderstandings; trying to show off; the fear of asking questions.

So how should we think about this? Simply put, it's your job to provide an environment where your team can do their job. You don't build software any more, you build and maintain a place where software can be built. Product specs are continually half-assed? You fix it. Some TPM is constantly badgering your team over Slack for micro updates? You fix it. Are your junior engineers terrified and making poor decisions because layoffs are happening? You fix it.

This also extends into the future. Supporting your team is one thing but you also need to champion them. You want your team to be a place where people don't just survive but thrive: they get to work on important things, receive recognition and the rewards that come with it. This is not free. You will need to shout about what they do and advocate for more.

You are the interface for your team to the company, and for the company to your team.

For the former, you will in turns: create a mission, goals and success metrics for your team; represent their work; champion their successes; take responsibility for misses; be accountable for timelines; provide individual and collective expertise to others who need it.

For the latter you will: explain and contextualize the business and their part in it; describe how to be successful both individually and collectively; explain decisions and priority changes in a non-destructive way (and this can be hard when people feel their time is being wasted).

You will be more successful on both sides by being true to yourself and your beliefs, and being consistent in how you talk about things.

Happily this part is straightforward: your value is the productivity and the morale of your team. The more the better.

Productivity and morale are connected. Teams that get more done are nearly always happier places. The inverse is also true. You can make trade-offs here: productivity can be gamed with micromanagement, or with crunch and long hours. But in both cases you’ll see the costs. Stressed people cut corners and make bad decisions. Micromanaged people don’t learn new skills and care less about what they do. It’s also good to reflect that from the company’s standpoint, it’s all about productivity. You and your team are winning when you’re getting more done.

So to sum up, morale is your thing to work with. Really doing well is finding a steady state of keeping everyone motivated and getting a bunch done and making sure that stuff is the right stuff.

Think about the scope each of the engineers on your team have. Your junior folks probably aren’t SME’s on anything yet, they have a fairly narrow, task based focus. Your mid-level folks are probably starting to run projects on their own, and accumulate areas of expertise. Your most senior folks are looking at team technical decisions not just now but for how your architecture will evolve over time. Working cross-functionally to make sure it fits with the rest of the company, probably participating in company-wide technical initiatives. For you as a manager it’s no different, just replace the software with strategy.

As a direct manager you focus on the immediate strategy, and how your team is translating that into software. How you will deliver that over the next months to a quarter. What immediate corners need looking around, what your immediate hiring needs are etc. Then as you grow and become more senior as a manager you simply look farther into the future, and this will naturally dictate a different set of actions you should start to take. You’re always a builder but how you spend your time and energy changes.