I’ve been a “leader-of-leaders” for a long time. It’s changed post-covid. But when I talk to some Engineers about the difference between “Leader of Others” and “Leader of Leaders” they don’t know what I’m talking about. So I thought I’d blog about it, and maybe even learn more myself.
The Best Book on Leadership (to me)
When I first became a Director my boss made me read this book and we would discuss it in our 1:1 meetings. It’s the single best book I have read on Leadership in the business world. I highly recommend it.
/a>
The “Leader-of-Leader” Role
The “LoL” role is not “laugh out loud,” but sometimes it can make you do that. Sometimes it can make you want to cry too. It certainly can also make you feel tremendously proud and grateful. I don’t see enough discussion about the role, frankly. I’ve had a lot of conversations on this topic over the last few months with a variety of people. It seemed like a good idea to write some notes.
A “Leader-of-Others” is the first rung of the management ladder. what I call a “Line Manager” or “People Manager.” This person is supervising and developing others directly. This is the first real role in management. Transitioning to that role is difficult for many since some folks get promoted to manager because they are great Engineers. That’s not enough. Management is a completely new skill and has goals and activities that are sometimes orthogonal to what one does as an Engineer. More on that later.
The manager of those managers is a “Leader-of-Leaders.” In tech the typical LoL job titles can span from “Senior Manager” to “Director” to “Vice President” depending on the size of the team and the span of control. The single absolute requirement is that this role manages other managers.
And that changes the game completely. It’s the first place in the chain where the “people stuff” matters more than the “technical stuff.” Not that LoL’s are not technical. In my opinion, the best ones are quite technical. But the actual work done weekly - and the skills to do that work - is drastically different than the work of an Engineer and a Line Manager.
The absolutely wonderful book Leadership Pipeline has a short passage that sums it up best:
“They are supposed to select and develop the leaders-of-others and hold them accountable for leading.” Wow. What does that really mean? And how has that changed in the post-COVID era?
Selecting and Developing Leaders-of-Others
I have developed an alergic reaction to the term “hold them accountable.” It’s just got a ring of “fire them” to it. Yes, at the end of the day if someone cannot develop into the role then you have to either move them into a new role or yes, move on.
But if you get to that point, the “blame” lies on the LoL, not on on the Line Manager. But “blame isn’t the right concept. My management style tries to operate a blameless culture. So it’s not really blame. It’s “responsibility.”
The LoL is responsible to ensure that the line managers are being effective. Just as important, the LoL is responsible for recruiting, selecting and training the managers. The “pipeline” of folks to be managers does not happen by accident. It happens through planning and development and a recruiting process that is not transactional.
So really “holding them accountable” means “doing the daily job of being a Leader-of-Leaders.” It’s really “holding yourself responsible.
Detecting When Line Managers are Struggling
I can’t recommend the book Leadership
Pipeline enough. So I’m going to quote it a lot here.
A LoL must be extremely aware of these typical issues and be ready to coach the manager through them. The fundamental problem is that a new manager is usually a very good Engineer, and it’s human nature to lean on those skills instead of developing the new skills of being a manager.
Now, for the LoL to be able to coach the manager through this transition they need to have done it themselves. When the LoL was a manager if they didn’t learn to delegate, didn’t learn to be comfortable letting Engineers arrive at solutions themselves, didn’t master the skills of being an effective manager then how do they coach and mentor new managers through that transition? And what if that LoL didn’t spend enough time (or any time) as a manager before becoming an LoL? This happens a lot in fast-growing teams, especially founders or early start Engineers.
This is the most common problem I have seen - and something the book covers extensively. If the LoL didn’t develop these skills then he or she is going to be blind to the problem. Often the LoL just reverts back to the behavior they did as a manager or star Engineer and the whole team structure comes apart.
Timescales
My observation is that line managers can make changes in work breakdown, assignments, coaching of a person, etc. and actually see results in a matter of days or weeks. The atomic unit of time for a change is pretty much one sprint.
The atomic unit of change that an LoL can make is going to be much, much longer. Probably multiple sprints. If that LoL is expecting changes too soon they are probably doing the work of a manager. That may be needed in an emergency, but if the organization is going to scale and grow then the LoL needs to coach the manager to make the needed changes. And it likely isn’t just that one manager that needs it. You should be asking yourself “is this systemic? Do I need a process to make this standard across my teams?” Writing that process, training folks on it, and getting it in place is NOT something that happens in days.
You can slam it in place, sure. But then you have to slam it again as your teams grow, or you add another team. Scaling out means adding just the right amount of process. THAT is what an LoL needs to be thinking about.
So if you are moving towards being an LoL (or working for one) you should always ask “what timescale do we think this can be done in?”
And the higher up the rungs you go, the longer the timescales.
LoL Responsibilities
“Leaders of Leaders translate strategy into operational plans.” That’s the work. That and mentoring and developing managers. Note: I didn’t mention writing code. Or designing system architecture. No code reviews. This is where it gets mushy.
A good LoL needs to be able to dive down when needed. They may not be specialists but they should have enough experience that they can spot (or smell) things that don’t look right. They ask questions and especially ask the teams to explain their thinking and how they arrived at answers. But that really is the manager’s job. The LoL should be observing and coaching the managers to do that work.
And more importantly, the LoL should be spending time across the company/organization to really understand the business strategy and how the technology aligns to that. Then he or she should be working with the managers and senior Engineers to break down the goals and map them to how to build the technology.
One area where I am currently weak is not getting too much into the weeds on system architecture. I LOVE system architecture and I think I’ve been pretty good at it. And my current company is fairly lean on staffing verses the large amount of code and functionality we support and plan to build. So I find myself dropping into that role more than I should. That’s not bad but it’s not good either. Seeing this in myself means I really must be pushing the right people on my team towards that work.
One of the most important attributes of a LoL is self-inspection. Humility. The abililty to say “I was wrong.” And especially taking extra steps to “farm dissent.” When the LoL is also the most experienced and best Engineer and starts to act like that then you are headed into dangerous territory.
Post-COVID Era
My original premise: how does all this change in a post-COVID era? The short answer is that it doesn’t. The longer answer:
- it’s a lot harder to do well
- developing junior Engineers is going to be a LOT harder
- having an org with a lot of junior Engineers and an LoL that didn’t learn to be a manager well is a bigger trap
Harder to Do Well
In a word: remote. Other than some companies being obstinate about return to office (RTO) the new reality is that we work at least some (most?) remote now. Especially the younger Engineers. During COVID we told them they could study and work from home so they didn’t get sick or worse. Then some companies tell them they have to return to the office. And they smell the disconnect. The genie is out of the bottle folks: remote work is here to stay.
AND.
That makes lot of things harder. It now takes extra work - and sometimes extra money - to get the team together as humans. Do a team meal. Get to know each other outside of work. All of that is critical to building a good team. And it makes it all that much harder to have the “more difficult” conversations around coaching. Not to mention that telling a manager that they are micro-managing is extremly hard to do over a zoom call. But if it needs to happen, it needs to happen.
Developing Junior Engineers
There’s a whole new set of skills that managers need today: how to coach and teach new Engineers the basics. Not just WHAT do do, but WHY we do it that way. I’m astonished at the gaps of some junior Engineers I’ve known recently who could tell you all about data structures and algorithms and nothing about how to use git, how to build, how to deploy, why you would do it one way or another. Computer Science teaches the Science, not the Engineering. If they were Civil Engineers they would know the tensile strength of steel but not how to do a coffer dam to keep the water out to pour the foundation of the bridge towers. Theory verses practice.
Our educational system is focusing a lot on theory. Juniors are supposed to get the practice in their early jobs. That are now remote. The chances to go out for food or drink at lunch or right after work and get a lesson simply is not there. That creates a vacuum. How will we pass on all this knowledge? Managers need to figure that out. And the LoL’s never dealth with this so they have no experience to share. We’ll all have to sort this together. But in the meantime even a well-oiled software org will have a gap in this area. We have to find a way to mentor junior Engineers when they work remote.
The Bigger Trap
If you have an LoL who didn’t learn the manager lessons along the way and you have junior Engineers then you run some real risks. Junior folks are likely to be intimidated by a high-level leader interacting with them regularly. Even more senior folks can be intimidated. And if you combine it with a mostly remote team the “human” parts can get lost and junior staff can feel like they are being criticized. I know that I can come across differently in writing (email, code reviews, etc.) than I do in person. I can seem harsh or overly critical, and I don’t mean to be that way. This kind of thing can make folks feel bad things. And that can lead to unhappiness. And unhappy Engineers are unproductive. Worse, they may leave you.
Conclusion
Today’s leaders need to worry about the Leadership Pipeline and the risks of remote workers. The latter can magnify the former and keep a team (or company) from really reaching what they are capable of. If you are a LoL you should be taking extra steps to spend extra time with your managers. Drop into standups more. Listen to design reviews more. Take extra steps to encourage face to face meetings if you can. Schedule in some fun time. As I write this I know I don’t do this enough.
But that’s part of why I blog: to make me reflect, and to try to get better.
