Little Giants of Tech
Ilya Sakharov
High-Impact engineering leader | CTO | Championing Scalable Solutions and Engineering Excellence. Expect no bullsh*t.
Mirror mirror on the wall, whose role is most impactful of them all?
“What an easy and even somewhat dumb question”, you may think. Yet the part of your thought that followed immediately, could be radically different from what the mirror might reply. Scores of mirrors would chant: “You, the CTO! [replace with any title representing the most senior tech leader role]”, something that many CTOs are expecting to hear every morning. Some others - the smartass mirrors - would insist ?“the CTO’s admin assistant or chief of staff, if such exists”, and those of a modern, slick, and Scandi 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?
I claim that the single most important and impactful role in engineering is, in fact, the first-line Engineering Manager (EM). It is the EM who really holds the key and has the most influential position in the mid-sized technology organization.
Here is why, and what to do with it
The Badlands, also known as the Internet, is swamped with resources that are aiming to help engineering managers grow and do their jobs 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 that one will start distancing from technology and 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 personalized with the author's experience.
Observation: there are many more resources to teach first-time managers to be good at what they do, compared to those available for higher roles. Somehow no one talks about what it means to be a good tech Director or a VP without immediately diving into general management and common leadership principles.
To avoid repetition of all the great, middling, and not-so-great, advice those resources provide, for the sake of making a point I will 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 a 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, at least those who understand the duality of their loyalty, are looking at themselves as parts of the “system”, about which many ICs would rather complain.
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 on what you have presented. They are the ones who absorb the sarcastic remarks of the "talented jerks” and change-resisters, the critics first confront them, and they first to 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 (1) laugh along with the jokes, take the side of the “people” and cultivate an “us vs. them” mindset, (2) reiterate the vision, and adapt the message to those who need more clarity (Hint: all of us, people), or (3) to remove themselves entirely from the conversation. The latter has the potential to leave their teams vulnerable and in the dark. All of it tends to happen in private channels and conversations to which you have no access (and this is good), and have no narrative 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 for ensuring the technological direction chosen for the tech department is aligned with what the business needs to fulfill its ambitions. You have probably done 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 or ways of working. Right? And you have gone the extra mile to facilitate an inclusive discussion with your EMs about it. The aforementioned 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 might 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 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 tho. It is not new either, that the majority of the organizations are not in the "high-performing" or "Elite" groups. So many of them that the latest DORA reports have removed the "Elite" category completely. You as a technology leader, a head of, a CTO, want the org to be there. So you bring up metrics, the data, you attempt to make everyone read the right books, and you expect people to experience the same level of enlightenment you had. Some engineers will. Some engineers won’t, but they won’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 that does not work in real life”.
领英推荐
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 big chief with 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 you think.
What to do?
There are two possible scenarios in which you may find yourself trying to assemble an adequate 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 understand and agree 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. This is the type 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 were 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.
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 Manage Out.
—
In the upcoming addendum to this article, I'll reflect on the EM onboarding process. Stay tuned!
—
As I find my way, and style in LinkedIn, I appreciate every bit of feedback in the comments about what you liked or didn’t and what else you think needs to be covered in the upcoming articles.
Senior Project Manager | Product Owner | Helping companies run software projects (SAFe, Waterfall, Agile)
11 小时前Ilya, awesome !