Technically Correct

As an Engineering Manager you have to have at least some technical skills.

After all, you're responsible for a group of engineers and engineers are very technical. If you don't understand what they're talking about, you're probably not going to be very effective.

But there is more to it than just understanding.

You need to be technical enough that you can help your engineers to grow. To give them the feedback that they need to be better engineers.

Or you need to find someone else to do that for you.

How Long Is This Going To Take

I like to think that as far as Engineering Managers go, I'm pretty technical.

I'm not exactly cutting code anymore, except for special occasions that is, but I have enough knowledge to meaningfully engage in technical conversations and offer guidance and feedback from my perspective.

But when it comes to providing meaningful feedback on technical competency, I don't think I'm doing a good enough job. Whenever do quarterly check-ins or annual reviews, I feel like there is a gap.

I don't really understand how technically competent my engineers are.

It's not like I don't know anything. I have a general idea of their skills and experience, but I'm missing the details.

I don't know if people write tests in order to validate their assumptions or just to tick a box. I don't know if people think about the SOLID principles before they write a line of code, or if they know they exist but don't care. I don't know if consumers are driving interfaces or the other way around.

I don't know so many different things when it comes to the actual engineering that is happening.

And because of that, I feel like I'm letting my engineers down.

Requisition Me A Beat

The first and most obvious solution to the problem is to spend more time understanding exactly how my engineers go about doing their engineering.

But my time is at a premium, and in order to get the depth of understanding that I need in order to create meaningful feedback, I'd need to spend a lot of time going through the contributions that people are making.

Not only that, but I'd also have to spend additional time on top of that skilling myself up so that I can understand all of the things they are doing. I'd have to be something of an expert, in a domain orthogonal to my primarily role.

And that's just not going to happen.

But that's okay, because as a manager, one of the things that you need to come to terms with is your inability to do all of the things yourself.

You have to learn how to rely on the people around you instead.

Bring Me My Forms!

I work with a huge number of incredibly talented engineers.

Their career is built on acquiring and maintaining technical knowledge, so I might as well use that and get them to fill my knowledge gap.

The idea is simple: delegate the responsibility for understanding peoples technical competency to the more senior engineers in the team. They keep me informed and I use that information in concert with all of the other things that I know to generate better feedback.

From my point of view it's win-win.

The engineers I'm responsible for get the technical feedback that they need in order to grow and the engineers providing the information get to grow their own skills in critical evaluation and mentoring, something that becomes more and more important as they become more and more senior.

I could approach this sort of thing informally, but if I want reliable, high quality information, I would need to set up some structure ahead of time.

My first thought was to pair engineers up at the beginning of a quarter and then set the expectation that the senior engineer provide me with a report or some sort of reference document before I go to do the quarterly check-in for the person in question.

Gap filled, job done, engineers growing.

Right?

You Can't Just Waltz Into Central Bureaucracy

Not quite.

After running the idea past a few of my engineers, they made me realise that while there was value in what I was proposing, there was also a risk that I had completely overlooked.

I was basically asking them to inform on their colleagues.

Not quite as aggressively as that, granted, but it's possible that the system I was proposing would actually reduce the ambient trust within the team. If people feel like they are being watched and reported on all the time they might be less likely to admit mistakes or gaps in their knowledge because it could be used against them.

Honestly, it's a pretty good point and one that I hadn't even considered.

I hadn't considered it because as a manager, it's literally one of my core responsibilities; observing the people I'm responsible for and identifying growth opportunities. Critically evaluating them and writing it all down to be referred to later.

But that's the thing. You expect that from your manager. You don't expect that from your peers.

And maybe that's a mindset that should be changed, but it's still something that I need to take into account. Perhaps by starting with a less formal, less structured approach and just casually asking engineers about their peers.

The second potential issue in the approach is that some engineers might not have the skills and experience necessary to critically evaluate their peers.

Not from a technical point of view. That shouldn't be a factor, being that I was only planning on involving senior engineers and they should know better. You know, because they are senior.

It's more on the critical evaluation side. Evaluating the practices and processes of a fellow engineer in an objective, non-biased fashion is neither easy nor a common thing that engineers do, even in senior roles.

That's manager territory.

In my mind that's actually a good thing, because it gives engineers the opportunity to build a new skill. Plus it aligns nicely with the natural tendency of senior engineers to trend more towards facilitation and mentoring.

You Can Quote Me On Regulations

Nature abhors a vacuum and so do I. A knowledge vacuum that is. In my head.

So, my natural instinct is to hypothesise about ways to crack said vacuum and let all of the air (knowledge?) rush back in.

Yup, that's about as far as I can stretch that metaphor.

Unfortunately, for this particular problem, it's still early days. I haven't tried any of the things that are outlined in this blog post, though I have talked about them with a number of people.

Hopefully, between now and the next set of quarterly check-ins, all of the random, jumbled thoughts above will have crystallized into something meaningful.

And my engineers will get the quality technical feedback that they deserve.