Early on as an engineering manager, I made one of those rookie mistakes that seems obvious in retrospect, but in the moment was absolutely confounding. I had heard about another team needing some help with building a landing site for their new product, and intending to be helpful, I tried lining up a very senior front end engineer to the project, only to get stymied by layers of product and (other) engineering management, to the point where I got flustered and inadvertently threw that engineer under the bus. Of course, they caught wind of my judgement, and proceeded to chastise me in a 1:1 meeting room for almost an hour, and subsequently—and reasonably—kept me at arm’s length for the rest of the time we overlapped at the company1.
Looking back on this scenario now almost a decade later, the obvious advice would be, well, to generally not throw colleagues under the bus. But, a more experienced manager would also try to figure out how we got there in the first place, where a resourcing gap surfaced on the other side of the organization. Indeed, my manager afterwards—as they were fixing cleaning up the mess—mentioned that the dynamics were a bit more complicated than I appreciated at the time, and I should have tread more carefully instead of naïvely rushed in with a half-baked solution. When dealing with people, in the long run, staying ignorant of the politics is not sustainable.
Of course, it shouldn’t be a surprise that there are political aspects to the job2. I’m reminded of a book I started reading, Cracking the PM Career, that tried to explain why the PM role differs so widely across teams: it cites that one major reason for the discrepancy is that Product Managers often end up taking on roles that aren’t filled by others on the team. Since each team has its own set of both unique and overlapping skills, the role ends up evolving over time to encompass these gaps, filling in negative space to take on unowned responsibilities.
Politics, as it relates to navigating people, feels the same way. It’s one of the reasons why good, concrete advice is difficult to apply to specific situations; the applicability depends on some combination of:
- The skill and style and experience of the manager themselves,
- The historical context of how the team got here in the first place,
- The attitudes and personalities of peers and folks above you in the organization,
- Likely, the shadow structure of influence,
- The state of the team, business and industry at this moment in time.
All of those factors can and do change up what you should do as a manager.
Granted, in reading my fair share of management books and articles3, there is plenty of actionable advice that can be situation-specific. Processes and tactics, detailed in books like An Elegant Puzzle, are worth experimenting with to establish a baseline, especially if none had existed prior. On the flip side, an article like this one—Principles of Engineering Management—are well-intentioned but somewhat generic so the utility largely depends on how much it maps to the reader’s own mental models. And to be fair, I’m totally guilty of doing this exact thing on this blog!
This is where individual mentoring and coaching has a leg-up on management advice from articles and books. I’ve been volunteering with the mentorship program Plato for the past 5 years, and have been involved in adjacent programs like peer coaching circles and discussion groups. The difference is that in working with other managers, though there will always be some amount of pattern-matching, we can also debug the politics and smooth out any wrinkles. That’s kinda the point of having all that experience in the first place; doubly so if that experience has crystalized into wisdom.
