I may or may not be interested in your open position for engineering management. To be more precise, the model of the manager you intend hire that currently lives in your head is simply that, a creation of hope and imagination. I am not that manager. Chances are good that neither is anyone else. In that context, I may or may not be interested in attempting to prove myself to be or even willing to become like the manager in your mental model.
Let's explore what you are likely imagining, and I'll tell the story of the manager I believe I am now. Perhaps then we can find alignment on the manager I could be for you on day one, and a direction for mutual continuous improvement.
I've been on the hunt for an Engineering Manager role for a while now; I have seen a variety of requirements and nice-to-have's in job postings, and have uncovered as many unstated expectations through interviews. In the aggregate, these reveal that what is generally meant by "Engineering Manager" is "A Clone of Our Best Staff Engineer Plus Some People Skills".
Based on this definition, when I'm stacked up against the handful of other candidates who have also reached the seventh interview, the deciding factor is that one of the other candidates is "slightly better at" or "had more experience with" some specific technical operation. That could be a particular code language, a specific infrastructure stack, or a modern engineering process religion ritual.
In one memorable case, I took the lead on every interview, and guided the focus of the conversation with each interviewer, including the director who would be my boss, senior engineers who would be on my team, a product manager with whom I would be coordinating, and a c-level something or other to whom I would be indirectly reporting. Each of these individuals arrived at the conclusion that the primary need I would be solving was communication - visibility, clarity, and alignment - up, down, and sideways.
The result? A rejection email arrives in my inbox offering feedback (an appreciated rarity in rejection emails), which turned out to be that I just didn't have enough experience firing engineers. I'll let you ponder the layers of disparity there; it's okay, take your time...
My take on the role of Engineering Manager is that I am focused all day every day on systems thinking, lean process improvements, one on one coaching and career discussions, value stream flow, value delivery and observability, aligning product + engineering + security + infra + ops + compliance + business, reducing risk, leading long term change, guiding collective rethinking, recruiting and hiring, continual monitoring of psychological health and safety, and encouraging a culture of learning. Any task that shifts my focus to solving problem X with technology Y as an individual contributor is detracting from my ability to do my job.
The skills pertinent to this role involve the ability to build trust with many personalities, story telling to reveal what could be, tactical questioning to guide and discover solutions not my own, communicating complexity for clarity, applying mental models and knowing when to discard them, crafting conversations and decision frameworks, using silence, choosing and interpreting measures, balancing empathy and accountability, identifying incentives, celebrating the successes of others, turning failures into learnings, and understanding the customer. To name a few. And always maintaining what is best for the business is the thread that runs through them all.
Should I be technically savvy and conversant? Of course. Should I be determining the specific X for deploying microservice Y? Good grief, absolutely not. Rather, I should be asking tough questions of the engineers, product owners, and designers to make sure their exciting and shiny new trees will help the forest grow, and bringing in other stakeholders with whom I've invested time building a foundation of trust, and... and... and....
Do I know anything about React? Sure, I spent a couple days playing around with it, and have a very broken public repository on GitHub. Do I give two shakes about React? Or Ruby? Or Java? Go? PHP? TypeScript? K8s? Azure? Jira? AWS / GCP Thing One? Thing Two? Nope. Can I lead a team of _______ engineers?
All. Day. Long.
This is the first draft of thoughts that had been brewing for a while, and the revised version is here. This draft coalesced at a coffeeshop after a fantastic conversation with a newly met fellow engineering manager. He was facing the same frustrations after being hired into the role for the first time.
Feedback on this draft was solicited from mentors and colleagues in my network, which is paraphrased and summarized as follows:
- Realistic but idealistic to expect EMs to only focus on people management and for interviewers to be awesome
- Sounds like you’re opposed to adapting to the needs of the team
- Intent is unclear - commentary on hiring practices, your hiring experiences, your view of the role, or the type of job you’re not interested in?
- Overwhelming impression of anger and hubris, pretty sure not your intent
- All engineering leaders should strive to remain connected to the work, so you can continue to connect with the people you’re managing
- The best EM’s are engineers who become leaders
- EM’s deal with less than ideal situations much more than an IC does, and should be willing to do whatever is necessary
- I hope your future boss doesn’t read this
- Your lists of priorities and skills are two or more steps away from results, and not everyone will see the connections and value - a hard sell
- Titles and positions are vague, and expectations and competencies for a role can vary, depending on size or state of the org, defined by business need
- Non-technical management has been rejected generally, and technical credibility is important
Top comments (0)