"So you're just kinda like HR for Engineering?"

It was two minutes in to my first 1-to-1 meeting with one of my team members at my new job. As one of the first management hires outside of the existing founders I had given an explanation of what my role is when I was met with that comment-masquerading-as-a-question:So you're just kinda like HR for Engineering?

It was a good question and, to be fair, it was a decent enough simplification of part of my role there. It also triggered a good thought process which has in turn led to this...

Engineering teams need specialists in people-focussed roles. A generalist HR person is not going to be the best HR person for an engineering team.

This is not the first time I've thought about this. Previously, when undertaking a fast hiring spree, I enlisted the services of an internal recruiter to help source candidates and conduct the initial phone screen conversation. The number one skillset I required for this role was that they had to be able to talk and (at least partially) understand tech when talking to candidates.

Basically I wanted an HR person with an engineering background.

Which, at the risk of sounding a little braggy, is essentially me.

I began my career as a software developer, moved into analysis and then data/business intelligence, dabbled in software architecture, shifted into process improvements, and am now a software engineering manager. I still write code in my spare time and I love to read about new technology. I'm in a people-focused role but with an engineer's mindset.

I think this is what makes me successful. I understand engineers because I am one. I know what makes them tick and I know what they don't like. I can talk airy-fairy fluffy things (i.e. what most engineers think of 'HR things') but then I can also get right down into the nitty-gritty technical details of a problem.

But I wouldn't say that to be a good manager of software engineers you must have a background in engineering. It certainly helps, but I you can be a good HR person for engineers regardless of background.

How to be a good manager for engineers

Understand Engineers

People want to be understood.

That's a good general rule of thumb for life. People like to be understood. Even extremely smart, highly skilled, technical people like to be understood.

But understanding doesn't mean you have to be able to read code, comment on an architecture diagram, or know the ins-and-outs of your team's continuous integration pipeline.

Understanding engineers is about understanding how they think and how they view the world.

Understanding engineers is about realising that the standard HR techniques won't always work. Then again if you have 'standard' HR tools you use for all people regardless of their personal situation then I hazard a guess you are not very good at your job.

Understanding engineers is about knowing they love systematic approaches, logic, and pragmatism (but also being able to draw them out on things like emotions and communications).

Be intrigued by technology

You don't have to understand all the 'technology-speak' that your engineers use but you should at least be interested in learning more of their babbling forgeing tongue. This is linked to the point above but taking it one step further: you need to be interested in what engineers do.

Nothing separates non-engineers from engineers faster than someone not bothering to even try to understand what an engineer does.

I've been in companies where senior executives make jokes to engineers like "Are you speaking another language? Use English please. We're not all geeks like you." The result is a series of tittering laughs from the other non-engineers and a black-mark against that executive in the eyes of every single engineer in the team.

Instead of writing off the engineering team's work as magic, a foreign language, or too complex, the best thing you can do is be intrigued. Ask questions.

What's the problem? Why is that a problem? What programming languages do you know? What tools do you use? What does CI/CD mean? Asking these kind of questions will gain you a lot of credit in engineering circles, and hopefully erase any black marks you have from poorly framed jokes you made out of ignorance.

Attention engineers: this works in reverse too. If you makes jokes, or don't give a shit, about the sales or marketing teams then you are letting yourself and your team down. You should want to learn what they do in their jobs, if for no other reason than because it has a direct impact on the success of the very thing you a pouring time and effort in to building.

Having engineering specific culture is good

Some companies like to have their culture defined and printed on the wall for everyone to see. Values, team charter, purpose, goals, etc. These are all extremely useful things for a company to have clearly defined and they can provide a unifying and repetitve focus point for people.

But sometimes the engineering team will have their own customised versions of these things. That is also good.

Teams are subsets of the greater company. They are microcosms, mini-societies, existing within the greater landscape that is the entire company. Think of how many individual states make up a single country.

Those individual states still need overarching rules for guidance but they also need the freedom to shape their own lives a little more directly. Engineering teams are a classic example of this.

Engineering teams are often unique, sometimes quirky, and distinctly different to other teams within the organisation. As long as it is not completely at odds to the desired company culture then the smaller team needs freedom to embrace their differences. Don't force a square peg in to a round hole.

One example I recently implemented was playing computer games at work. It was a fun team-bonding experience that was targeted to tech-focused engineers. It still aligned to the overall 'we have fun a work' corporate culture but with a specific twist for the engineering team.

Respect an engineer's time

The quickest way to piss off engineers is to repeatedly disrespect their time.

One of the best descriptions on this is Paul Graham's 2009 blog post called Maker's Schedule, Manager's Schedule. If you currently, or ever plan to, manage an engineering team then this is required reading. Go on, I'll wait.

Late notice meetings, idle chit-chat, and 'drive-by' discussions are all seen as interruptions.

A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. - Paul Graham

Which leads me to a follow-up point...

Understand that complex engineering problems need focus

Engineers hate being interrupted because to do their job properly they need to get into the zone, find their flow, and be immersed in their work. There is good reason for this.

Engineering work is often difficult and technical complex. The more complex the problem is the deeper an engineer needs to go in to a thought process to find the right solution. Someone who constantly disrupts them and prevents them making progress will quickly annoy them.

See this comic: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

I'm not saying engineering work is harder than other work but there is a large part of it that is definitely different. A lot of other work can be segmented, divided, or organised into small linear tasks that naturally lend themselves to handling interruptions better.

As a manager I find that the majority of my work can easily withstand an interruption without me losing all my progress and having to start over. Complex engineering problems are not like this. Understanding and respecting this wins big brownie points amongst engineers.

Why bother with all this? Why can't engineers just have a manager like everyone else?

There are many benefits to finding the right HR person for your engineering team but it all boils down to a simple maxim: being a leader is about getting the best out of, and for, the individuals and the team.

To get the best OUT OF your people you need to understand them, connect with them, earn their respect, and protect their best interests.

To get the best FOR your people you need…well you need to understand them, connect with them, earn their respect, and protect their best interests.

Funny how those sound the same hey?

If you find yourself leading a team of software engineers then put all your energy toward being the best damn 'HR for engineering' that you can be.