Little Giants of Tech

Mirror mirror on the wall, whose role is most impactful of them all?

“What a dumb and easy question”, you may think. Yet the part of your thought that followed immediately, could be radically different from what the mirror might actually reply. Scores of mirrors would chant: “You, the CTO!”, something that many CTOs are expecting to hear every morning. Some others - the smartass mirrors - would insist  “the CTO’s admin or chief of staff if such exists”, and those of a modern design would go all the way and claim that the individual contributor, the engineer - is the one. After all, what are generals without an army, right?

The single most important and impactful role in engineering is, in fact, the first-line Engineering Manager. It is the EM who really holds the key and has the most influential position in the mid-sized technology department. Here is why, and what to do with it:

Far far away, also known as the Internet, is swamped with resources that are aiming to help engineering managers to grow and do their job well. It is full of advice on how to work with people, and how to transition from the individual contributor role to the first managerial one. How to accept the fact one will start distancing from technology and the fact that managing people is quite different from pushing a change to production. Some of those resources are quite useful. “The Manager’s Path” comes to mind. This book helped many people to understand what is that they have stepped into. Another recently released book “Engineering Management for the Rest of Us” is also quite ok, although I find it a bit basic and too emotional.

To avoid repetition of all the great, middling, and not-so-great, advice those resources provide, I prefer to look at the position of EM from a different perspective - and that is top-down. As a senior leader joining the existing organization or building one up from scratch, you are responsible for its performance. You are responsible for all the people in it, for the quality and speed of delivery, and many more. You are the “one throat to choke” figuratively speaking. Regardless of how strong, energetic, and driven by principles you are, you cannot do it alone.

The Engineering Manager is situated at that pivotal point of the organizational chart: the demarcation line between the managerial domain and the individual one. Being social animals, people naturally are strongly aligned with hierarchy in their heads, and they often willingly play the role according to a position. An individual contributor (IC) would be more inclined to associate themselves with the “common folks”, with the “proletariat”, while managers, understanding the duality of their loyalty, are looking at themselves as parts of the “system”, against which many ICs would rather vent.

Alignment with organizational goals

Regardless of how many all-hands and town halls you hold, and regardless of how charismatic you are, it is the engineering manager who receives the first wave of any feedback to what you have presented. They are the ones who field sarcastic remarks from the talented “jerks” and change resisters, they are first confronted by the critics, and they hear the praise from those touched by your performance. EMs then have a variety of options on how to react. They find themselves in a position of power where they can decide whether to laugh along with the jokes, to take the side of the “people” cultivating an “us vs. them” mindset, to reiterate the vision and adapt the message to those who need more clarity (Hint: all of us, people), or to remove themselves entirely from the conversation. The latter has the potential of leaving their teams vulnerable and in the dark. All of it tends to happen in private channels to which you have no access (and this is good), and have no control whatsoever. All that is left for you, is to listen to the mirror.

Technological vision and strategy

As a CTO, working for a mid-size org where being a senior technical leader actually means something, you are responsible to ensure the technological direction chosen for the tech department is aligned with what the business needs to fulfill its ambitions. You have probably made a lot of research, consulted with your peers, friends, and communities, and reviewed your previous experiences before coming up with the changes to the technology plan. Right? And you have gone the extra mile to facilitate an inclusive discussion with your EMs about it. The same EMs are coming from different places, though, bringing different sets of experience and baggage to the next role, just like you, they are opinionated, and they think GitHub is the best tool ever and that Kubernetes is a solution for everything. You can convince them by bringing data, but you might also fail. Then you will pull rank, finish the endless, circular discussion, and off we go on the new shiny journey. If your EMs are not convinced, or not capable of changing their mind - consider that you have not only lost them as your support but the majority of the team they are managing.

Engineering principles/ways of working

The publication of “Accelerate,” described many interesting and sometimes counter-intuitive correlations between quality, speed, and agility. The book hasn’t highlighted something that wasn’t there already. It does provide extensive data and scientific research to support the findings. It is not new either, that majority of the organizations are not in the high-performing or elite groups. You as a technology leader, a head of, a CTO, want the org to be there. So you bring up metrics, the data, you make everyone read the right books, and you expect people to experience the same level of enlightenment you had. Some engineers do. Some engineers don’t, but they don’t debate or challenge the idea, they turn to their manager and look for support. If the EM does not understand the value of working in small batches, the value of real continuous delivery (not that thing you call CI based on the git-flow), fast feedback, and limited WIP (Hint: it equals 1), the same managers will form a movement of gaming every metric you have put in place to reflect on engineering and delivery performance. The numbers will be skewed or taken out of context. Looking good to you, those metrics will not reflect reality. They will be solely misused to protect the old ways of working. Shield the team from your “innovative crap”. Delivering a presentation is never enough to foster a culture, so you will have to dive deeper. Very soon you’ll find yourself in a maze of excuses and promises. One late afternoon I had the pleasure to eavesdrop on a conversation that went like this: “Here is another wannabe chief with his out-of-his-mind ideas. Don’t worry guys, I will make sure he gets the info he is looking for and hopefully leaves us alone. Business as usual”.

You're doomed. Unless, of course, you do something. Surprisingly, you have more options than the Queen had with Snow White.

What to do?

There are two possible scenarios in which you may find yourself trying to manage an inadequate engineering management layer. The first, where there are simply no EMs and you need to find some quickly as the organization is growing, is relatively straightforward, although not necessarily easy. You need to hire or promote individuals who are in agreement with your concepts and principles or, more importantly, understand data, know how to derive conclusions from it, and are ready to accept/challenge certain concepts. These are the types of people you can work with, debate with, learn from, and trust. Well, unless they are professional sociopaths. This you will find out quite fast though.

It is the second and more common scenario that demands even harder choices. It is when you join an existing organization and inherit a team of engineering managers, each one with a different story and history in the company. You want to make them your allies, you want to help them grow, and you want to make sure that all the changes you have carefully picked to implement, are supported and driven by those EMs into the teams, but there is always one or some, that just won’t do. They just won’t get it, intentionally or due to mental imprints of past experiences. They just won’t accept the change. And you will continue to invest in changing their mind, dedicating scarce energy, and pouring it into this bottomless pit. If it would be an IC, that would be somehow acceptable, because peer pressure and conformity are very strong factors. The team will align the individual, or they will leave. Yet as this is an EM, the whole team is in danger, and the same EM will find a comforting echo chamber in their own team that will make your job of pushing the change exponentially harder. Now, instead of one person who disagrees with you, you have the whole team that secretly thinks you are out of your mind. Should I remind you that you are responsible for the happiness of your people and the delivery speed and quality? Good luck with that.

• Success is determined by the strength and alignment of your first-level engineering managers.
• You need to achieve this alignment as fast as possible.
• Any inward-facing change you plan to introduce will either work or fail, depending on that alignment.

Despite the best intentions and leadership principles associated with constructive feedback, giving second and third chances, career growth, and other sociotechnical factors, time is not on your side with it comes to Engineering Managers.

They have the most influential role in the whole technology organization and most of your success is also going to be thanks to them! Don’t wait for a magic mirror to surprise you one of those mornings.

Onboard, Convince, Align, or Fire.

Yesterday.

—

In the upcoming “Part II” of this article, I will share practical points on what does work and what doesn’t in those three magical pillars: Onboarding, Convincing, and Alignment, as well as how to fire a manager while causing minimal “disturbance in the force” (not getting into labor laws of different countries, though).

Do subscribe, and leave me some feedback in the comments below about what you liked or didn’t and what else you think needs to be covered in the upcoming articles.

Here to help,

Snarky Doodle