Dear manager of managers,
I may or may not be interested in your open position for engineering management. Let me be more precise. The model of the manager you intend to hire that currently lives in your head is simply that, a creation of hope and imagination. That image is good to have, and sets a course for your search. Like all mental models, however, it can only represent a perception or expectation of reality, not reality itself. 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 exactly like the manager in your mental model. Chances are just as good that you or your organization don't want that, either. By holding strictly to that expectation, you could be missing out on a range of skills, experience, and ways of thinking from any number of candidates that don't live up to the manager in your mind, yet might very well satisfy your needs and exceed your expectations.
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, ways of addressing the immediate and long term needs you are intending to solve by hiring an Engineering Manager, and a shared direction for continuous improvement.
Qualifications You Are Likely Prioritizing
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 final interviews, the deciding factor is often that one of the other candidates is "slightly better at" or "has 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.
Interview Intent and Design
We should pause here to consider what interviews for this role are attempting to accomplish. I have experienced a significant number of interviews, on both sides of the table, that could be considered successful except that whatever was accomplished had little to do with either competency for the role or culture fit.
Interviewing is challenging, and I have conducted my share of less than ideal interviews. I have made candidates uncomfortable, have wasted both our time, and have delayed when I should have acted. By critiquing those who have interviewed me, I'm putting myself in their shoes, and trying to learn the less hard way myself. I have attempted to learn how to better design and react during an interview, whichever side of the table I'm on, to maximize for what I believe is the intent of that specific interview.
Why, then, are technical qualifications such a deciding factor so often for an EM role? Does the company lack senior levels of engineering talent? This need for the EM role to wear the tech lead or principal engineer hat is common at small companies and startups. Is that your org? Or the concern may be credibility as a leader. Is any decent senior level experience enough to secure that respect? Or does everyone on the team absolutely need their manager to be the smartest person in the room?
There are no right answers to these questions. They will, however, have a huge impact on the direction of your interviews. Are technical contributions by this role critical to your business? Or is the management role solving other priorities, such as process transformation, employee retention, performance accountability, or some other elephant in the zoom call?
Disparities Between the Role and the Qualifications
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…
To be true to what was stated, it was about confronting poor performing engineers with accountability. I'm extrapolating that out to the ultimate threat that is the undercurrent in all those conversations, even if only because that is what the poor performer thinks of first. The times I have had those conversations, a mutually happy direction and commitment for improvement was reached. Termination was necessarily brought up, but only to communicate that we were nowhere near that, and that it would be discussed early if it did become a concern.
But I digress. The disparity throughout the series of interviews was such that a single immediate need that the hiring manager wanted (understandably) to find help in addressing dwarfed the greater dysfunction across the company that the role was also intended to address. If the latter was resolved as the top priority, how might that have impacted motivations and incentives for those causing the former? Might there have been other hardships and roadblocks frustrating those who would otherwise shine in their work that were as yet uncovered? I'll likely never know, yet I've faced this enough to know that poor performance is rarely as simple as a case of the lazies with a one step solution.
This is but one example of many disparities between what was advertised, what was discussed throughout the interview process, and what was ultimately the deciding qualification that manifested as a rejection of my candidacy. Let's make a stab at mitigating future disparities should we meet in an interview; I'll give you my take on the role, nuanced as it may be in your particular situation, and then we can take another look at qualifications.
The Role
My take on the role of Engineering Manager is that I am ideally focused all day every day on 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.
Are there times when an EM should shoulder technical work? Again, that depends on your org or the needs of the team. Given the ideal, that is always a tradeoff. It may be freeing someone else to complete another priority task, but more often than not it removes as much or more value than it adds. Any task that shifts my focus to solving problem X with technology Y as an individual contributor is detracting from my ability to do what I see as my job. Am I willing to reprioritize to meet immediate needs of the business and my team? Of course. If it becomes a pattern or habit, however, that is a clear signal something else is out of alignment, which implies a deeper solution.
Rethinking Qualifications
If the picture of the role that I am painting is more in alignment with the business need you are hiring to solve than can be met with a more technical lead, what qualities are you really looking for? What will be the deciding factors when choosing one candidate over another? How can they be demonstrated in an interview? How can they be measured, analyzed, compared? Again, these are challenging to consider, and there are no right answers.
The skills that I bring to this role involve the ability to build trust with many personalities, systems thinking, 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? Probably 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. I should provide context that isn't easily visible about downstream impact or mission alignment. I should bring 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 know anything about systems architecture? Some, enough to contribute to discussions with engineers who live and breathe and implement such things. Do I give two shakes about React? Or Ruby? Or Java? Go? PHP? TypeScript? K8s? Azure? Jira? Dynamo node replication and failover configurations? AWS / GCP Thing One? Thing Two? Nope. Well, only in the sense of does this technology bring value to the end user, execute on the mission, and benefit the business.
Whatever the tech and my personal experience with it, or lack thereof, can I lead a team of _______ engineers? All. Day. Long.
Back to the Beginning
Now we arrive where we started (a good hero's journey storytelling move). Do our goals, aspirations, and assumptions regarding the Engineering Management role for which you are hiring align? Has this inspired any rethinking? I hope so, even if you have arrived at the same perspective you had previously. Does this reveal an alignment between what I bring and the gap you're hiring to fill? Or misalignment such that neither of us would be satisfied? Either way, I hope this serves your choice whether or not to invest time exploring that fit further with me.
This is the revised version of this article after receiving a lot of great feedback from Plato mentors and amazing folks in Rands Leadership Slack. I present both on the off chance a reader is interested in analyzing how I’m able to receive and act on feedback, given the purpose of the article itself.
Top comments (0)