Management Style: Standard-Bearer

One of the common questions that is asked of Engineering managers as they go through the gauntlet of an interview process, or even just reflecting on their impact in an organization is “What is your leadership style?”.

This is such a tricky question because the Engineering Manager role is demanding: you have to be a coach and a leader for your team, but lose sight of the strategic and business goals of the company and you risk building many beautiful things with 0 business impact. You didn’t achieve what you were hired to do.

Therefore I think it’s really true that your leadership style has to match the stage or needs of your company. You have to be flexible – which requires a situational leadership model of management.

But I haven’t always found that to be a satisfying answer when I asked what my style is. Saying you are a situational leader doesn’t get to the core of who you are – its kind of a mealymouthed way of avoiding your default mode and how you prefer to act when in seat as an EM.

So, in the spirit of elucidating my default mode I’ve put together a set of principles that are the bedrock of how I prefer to manage technical teams and build organizations.

1. High Standards for myself and the team
   • Senior Engineers are expected to drive their solutions end to end, tie them to business outcomes and own quality and communication of those solutions. These are the table stakes for good outcomes in an organization. Similarly as a manager or leader I’m accountable for outcomes in the organizational unit and have to be able to create the structure, players and team dynamic that sets things up for success.
2. Always stay technical. Behold the power of the prototype.
   • It’s never a good idea as an Engineering Leader to get too far from the details. Even if you are loaded up with a full schedule of interviews, you always need to retain some time to write solutions and express them in code. Especially in the age of AI there is no excuse for not being able to exercise this muscle.
   • This is an extension of (show) not tell. Teams can argue for weeks over a direction on a technical solution, but a clean prototype can cut through FUD like a hot knife through butter.
3. Keep the (business) outcome in mind – and be rigorous.
   • Why are we building this system? Is our hypothesis that it will increase marketplace conversion by x%? If it’s a technical system, what technical debt are we paying down or avoiding? What are the scaling properties of this system, the risk and the dependencies that we are introducing? We need to be rigorous around our actions and keep the outcomes in mind when taking them.
   • This also means thinking about which product and business outcomes that you are looking to ladder to. In what way are you targeting your product to be best in class? How does this engineering approach support that?

So if I had to reduce my principles down to a catchy archetype name – I would call myself a Standard Bearer.

A leader who stays close to the code, sets a high bar for technical and business rigor, and rallies teams around clear, uncompromising execution.

At least, that’s what I’m doing on my best day.