Here’s something no one tells you early enough: software is the easy part. Tech debt? You can refactor. Architecture mistakes? You can migrate. In engineering leadership, the truly hard part is people. Once you realize that, you’re on your way to leading better.
Think about it: refactoring a codebase is a pain, but refactoring a team? Good luck. It’s harder to realize that someone you promoted isn’t cutting it as a manager. It’s harder to shut down a team when you were the one who created those “nano teams” that now add nothing but overhead. Moving people between teams is harder because you have to navigate politics, personal relationships, and bruised egos.
People are Like Hardware
Unlike code, people don’t “compile” after a refactor. Good leadership requires an acute awareness that the human side of the org is far less elastic than the tech side. You can’t treat them the same way. And while some leaders decide that “fixing” means firing people at the first hiccup, that’s a surefire way to build an org no one actually enjoys being part of. (And newsflash: those don’t win.)
Instead, better leaders engineer their organizations with this constraint in mind from the start. Take a client of mine: they knew a key leader was turning into a single point of failure—and wasn’t that good in the role anyway. He wasn’t hiring strong people around him, wasn’t mentoring, but “things were fine” and no one wanted to rock the boat. Until it was too late, and everything collapsed.
Another client let the QA team balloon in size for over a year, despite the team not showing meaningful ROI. No one trusted their output, yet quality issues were rampant. Fixing it now would mean admitting they’d wasted a small fortune. The human cost of “undoing” people decisions dwarfed the technical debt by orders of magnitude. Technology is forgiving. People systems aren’t.
Avoid the Hassle
If you want to be an effective leader, consider some changes to that approach. Set up experiments, not irreversible commitments. Before a formal promotion, giving people the responsibility for a trial project can allow both sides to realize before it’s too late and undoing becomes a challenge.
Avoid “zero-sum” titles that make org changes into political issues. Resist the temptation to create too much structure too early. It’s better to be slightly late than prematurely rush into it. Don’t create micro-teams that might make your org chart more orderly right now, but add virtually nothing day-to-day (if not make things harder).
Most of all, be deliberate and intentional in how you manage people. If everyone’s expected to receive feedback regularly, and it’s part of the company’s rituals, it’s a lot easier to talk about these things. When you take the time to do basic expectation setting with people who might get a promotion about the definition of the role, what they will be measured by, and maybe define a trial period, you avoid surprises.
Aim to have cross-functional, end-to-end teams that are capable of executing varying business needs and that don’t define themselves based on a short-term goal. Avoid associating teams and people with specific products or technologies, so changes are easier. Talk about this expectation of elasticity and the fact that things will definitely change and more than once. Set up your team to expect the expected (we’ll cover the unexpected in a different article).