Zach looked tired, he looked weary.

“I used to code. I’d get to work a little after 10am high on caffeine, I’d sit down at my desk, glance at my email, and then start coding. Sure, there would be a meeting here and there, but we’d be talking about code or things that lead to code. I’d meet with my manager at our 1:1, but it always felt like something he was supposed to do, not something that was actually valuable. 30 minutes. No big deal. Sometimes we’d even talk code.

“The team was growing fast and we needed another manager. I never really wanted to be a manager, but I was wondering what was going on in all those meetings, so… why not?

“Rands, it’s been six months. I’m getting in at 9am, I’m in meetings until lunch and usually through lunch. After lunch, I’m in hybrid hell of more meetings and dealing with whatever people and org crap has gone down that morning. I’m on my third productivity system and I have zero ability to predict what I’m going to do tomorrow because I’m reacting to everything that is happening today.”

And then Zach asked me, “Rands, am I ever going to code again?”

It Depends

The problem with solving Zach’s situation is that the correct solution is dependent on understanding a set of situational data entirely unique to Zach’s situation. The discovery of this data involves having someone with relevant experience asking Zach a lot of questions, asking his team a lot of questions, triangulating and analyzing all of the answers, asking follow-up questions, and only then designing a credible plan.

Zach knows that he needs help. That’s why we’re sitting here, but we’ve got an hour, and while I can ask a lot of good questions and make a handful of suggestions, I am guessing.

I’m a pretty good guesser because I’ve been working in engineering leadership for years, but I don’t actually know the specifics of the Zach situation, which means my advice might be credible, but built on incomplete knowledge. Furthermore, even if my guess is good, even if Zach chooses to follow it, his various situations are going to mutate as a reaction to the actions Zach chooses (they always do), and then he’s going to have more questions.

Who failed Zach? You could blame his manager. Based on what we know, Zach didn’t really know what was expected of him. He didn’t understand what it meant to be a manager, so he’s likely making it up as he goes. But making it up as you go isn’t leadership – it’s gambling.

You could blame HR at Zach’s company. They didn’t have leadership training, they haven’t set up mentoring relationships, and when Zach went to them for help, they responded, “Did you bring this up with your manager in your 1:1?”

You could blame me. I write a weblog on the topic and wrote a couple of books, too. Zach’s read the blog and both books and we’re still sitting here trying to figure out what Zach needs to do differently, but we’re guessing.

I blame everyone.

Collectively, I believe that we, the engineering leadership community on the Planet Earth, have done a poor job supporting each other. I think for every manager who has taken the time to find and regularly meet with a mentor, there are 20 managers who like the sound of mentorship, but haven’t done anything about it because they have no time. And even if they did, they wouldn’t know where to start.

I think that there are well-intentioned HR teams who are building leadership training without partnering with their engineers. Similarly, I think there are legions of engineering managers who have been asked very politely by their HR teams to partner on building said programs and those managers have politely and repeatedly said, “I’m too busy.”

I blame everyone. We can do better.

Bookshelves are full of unread books on leadership written by authors who have never managed engineers. Authors who are clever with a turn of a phrase, but who have never written a line of code. Authors who did write code ten years ago, but still think in terms of software that was developed for 18 months and shipped in a box. Authors who inspire, but fail to deliver.

I Have a Hunch

I have a hunch that we engineering managers can collectively better help each other. I suspect that there is someone sitting relatively near you who would like to help you, but you have no idea that they exist. I believe that if there were readily available events, talks, and dinners where we could sit down and honestly talk about the craft of management, that we would instantly make time because I do not doubt we have a desire to learn and to grow.

I have a hunch that we don’t miss coding: we miss engineering. We miss the tangible sense of accomplishment of building a thing, so we should view the job of engineering leadership as an engineering problem – that means we must solve.

I wrote this survey because while I think we can collectively help ourselves, we need to determine a credible and high value starting point. If you choose to fill out the survey, you’ll be answering questions about yourself, your leadership situation, your current leadership pains, and what leadership investment activities would most appeal to you. Please share it: the more data the better.

I’m going to leave the survey up for a month and then I’ll write up the results. From there, we’ll start building.