Nick McHardy header image

Tags

On being an Engineering Manager

I’ve been acting in the role of Engineering Manager for 6 months now, so it’s a good time to review how things are going. Some of the points below could be obvious to some and not everything will work in all situations, but I hope I can accurately describe my perspective.

A little bit of background for you, first, to set the scene. The organisation I work for had endured several restructures over the past few years, but the most recent one was probably the most impactful for me. For the first time, I had the option of acting in a people management role as an Engineering Manager.

Previously, most of my roles for the past few years at this organisation and prior have revolved around solution designer or architect. I was used to communicating with many different stakeholder groups and providing technical leadership, even if I didn’t realise it. The area where I’ve worked the past 4 years has been tasked with developing and supporting all kinds of online and digital platforms and products, so the core function of our division hasn’t really changed significantly. We’ve weathered a few name changes along the way, of course.

One of the key elements of the most recent restructure was to remove the need to fund and run initiatives as projects, and instead, run as long-lived products. This strategy is still in the process of coming to fruition (I think I heard some people say we’re still in the ‘storming’ phase, which I think is accurate). Read more about running teams as products in a previous blog.

To keep things simple, a new set of 6 Engineering Managers was appointed, of which half were acting. I was one of the 3 people to gain an acting position, which is definitely a promotion from my previous roles. I thought I’d give the role a go, especially when combined with decent support from senior management as I would be learning new skills.

In my organisaton, an Engineering Manager is someone who manages an engineering team, comprised of developers, quality assurance (testers), build & operations and solution designers.

Some of the reasons I agreed to take up the role was:

  • I’d never experienced people management and would like to pick up a new set of skills
  • I knew pretty much everyone in the division, so I was in a reasonable position to ‘get things done’ with the support and respect of my peers
  • It’s an acting position, so I wouldn’t be stuck in it if I didn’t like it (I worked to define my substantive position, in case I wasn’t successful in becoming an officially appointed Engineering Manager)
  • I’d be managing staff who look after 4 key platform areas: Analytics, Search, Identity Management and Content Recommendations
  • The 4 platforms I was already intimately across since I’d either built it, designed it or procured it

The Engineering Manager positions were interesting because we have a reasonable number of engineers, but few managers. So, I would pick up 13 direct reports (which is a lot for a newbie!) and others would have up to 35 direct reports. Looking at the numbers alone, managing 13 people was a bit daunting, but in reality not everyone is a full-time employee. I have a mix of full-time, fixed-term contract and day-rate contract. Each style of employment has a differing requirement, from performance management and development plans, to contract renewal processes, and finally approving timesheeting.

Some of the new processes which I had never been in before included:

  • Approving leave, travel and expense claims (to a limit)
  • Performance management, job plans, individual development plans and appraisals
  • 1-on-1 meetings
  • Timesheeting
  • Budgeting
  • Hiring
  • … and sometimes receiving bad news when people decide to move on (not to give anyone ideas, of course!)

First blood: my poor calendar

My role has always been dominated by an incredible calendar, which I have written about before also. I say incredible, but really it’s often 7 hours of meetings a day. I do say “at least you get paid to be in meetings” but sometimes it can be too much. There’s simply no time between meetings to achieve something to talk about in the next meeting. I have a habit of being double and triple booked, even with an open calendar.

Despite my calendar already being so packed, I decided that one thing I wanted to do was proper 1-on-1’s with each member of my team. This means running them every fortnight, for up to an hour, where I would try to listen to my team more than me doing the talking. To make this time more valuable, I have been taking notes in a diary, with an entry for each 1-on-1 session, with clear actions in a page that’s shared with the individual. One reason is that I can’t possibly remember everything, but also as I’ve only been ‘acting’, I could use it as a source to handover my team to someone else, should I need it. Also, with my team member’s approval of this! Nothing super confidential is written in the page, because others may have admin access privileges and thus can read it, so I do exercise caution for this approach.

I’d be booking 13 x 1 hour sessions a fortnight, plus several daily standups, plus 2 x weekly 1 hour management meetings. This basically halves the amount of time you have to spend on anything else. Yowch!

Sometimes you can be a bit smarter about 1-on-1s:

  • You don’t need to use the full hour if your team member doesn’t need it
  • If things come up or if the recurring meeting falls on a public holiday, you should always reschedule and at least give the option to be available
  • You can go for a walk. Yes! Outside! Be creative, it doesn’t always have to be a talk-fest in a meeting room (I remember going to pick up a package from the post office, chatting to one of my team members)

What I learnt

What I quickly discovered was that I really enjoy the technical aspects of my previous roles. I still enjoy dabbling in a bit of code here and there, just to stay sharp. It’s one of my strategies to make sure I still know what I’m talking about (or at least I try!). That’s also one of the reasons why, outside of my real job, I have other projects on the go.

The way the Engineering Manager position is described is a pure people management role. It’s all about developing a great engineering team, without having to do any of the technical work yourself. This poses the question for many senior technical people:

When’s the right time to give up the tools and become a people manager?

A lot of organisations have a well-defined technical track separate from a dedicated people track, which is usually split once you get to a high enough level. On the technical side, this is less defined in my organisation, however we’re still working through how this can work with roles like Lead Engineer and Principal Engineer. I think for a lot of us, making this decision is quite a tough one because often once you hit a certain level of technical mastery, outside of learning a new language or technology, it’s difficult to progress further.

Being labelled a ‘manager’ for the first time was also an interesting experience, which took people a while to get used to. Actually, it even took me some time to get used to as well! I can’t remember any time when anyone wasn’t supportive of the new role, so that definitely made the transition easier for me.

It came time to apply for the role about half-way through my time as an Engineering Manager, so with 3 months experience, I had to make a decision. Would I apply for the role? Would I have a chance in being successful?

So what did I decide?

I went the technical route and chose not to apply for the Engineering Manager role. But why?

I had a bit of time to think about it and I can promise I didn’t just take the lazy option because I didn’t want to update my resume and apply for the job!

Here’s a few reasons that had me convinced:

  • I had so little time for doing things like drawing diagrams (something that I actually really enjoy) or coding bits here and there
  • I enjoyed working across multiple solutions and products and wanted to ensure this continued
  • I have a strong depth of technical understanding, having been here for over 4 years, that it’s easy to make decisions with confidence
  • And this is the biggest one: I actually think with my skills, the organisation is better off with me as a Solution Designer/Architect. We actually really need someone to fill this role, to tie a lot of the systems together, to bring that knowledge to make sure we are technically aligned and things aren’t missed or repeated in a way which wastes resources. So I could actually ensure the Solution Architect role continued by not applying for the Engineering Manager role.

Sometimes, the organisation you work for might need you to do a certain role for a strategic reason, but remember: it is your life and your career, so it has to work for you as much as it has to work for the organisation. I believe I can achieve this balance with my substantive position.

Helping to develop people is tough! But that doesn’t mean you shouldn’t try. Fixing problems with a system or a computer is a lot easier (at least for me) than solving people’s problems. Understanding all of the nuances and complexities of a person can be a challenge, but it’s quite rewarding when you have a motivated and performing team.

If you’re given the opportunity to have a hand in managing people, by all means give it a go! You don’t really begin to comprehend what’s involved until you’ve tried. There are times when I actually find the management role to be very satisfying: when you can resolve people’s issues and you can make a real impact to someone’s career. It’s a noble role and does take great skill to be a supportive and effective leader. I’m not there yet, but maybe one day I will be.

What I realised about being ‘technical’

Being a technical person who’s been around involves more leadership than you realise. Unknowingly, I actually really enjoy aspects of leadership when it comes to achieving an outcome with a solid approach. This may include influencing people to bring them on board, as much as also learning from others all the time. Just because I’d like to focus on seemingly more technical outcomes doesn’t mean I don’t need to continue to develop soft skills on how to empathise, analyse, communicate and influence others. There’s a huge gap if you can invent the best solution given all kinds of constraints (time, people, skills, budget, performance, accessibility, legislation, policy, you name it) and you can’t get anyone else on board with your vision.

I also found I enjoy working closely with engineers - to the point of me standing up for the voice of the engineer - to make sure the team members who are doing the hard work are actually valued. It’s difficult to move things forward without the engineering community. This has many dynamics to it and it’s not always about sitting down in a work scenario to review code or walk through a solution design. It could be as simple as going to lunch with the team or making time to play boardgames. Mutual respect is an important power which is often overlooked when organisational “progress” takes the focus.

Some approaches which I find work for me:

  • I like to share the solution and talk about it being “ours” or “we came up with it” rather than saying it’s mine. This is a reflection of truth not a façade because I would involve teams along the way as the solution is defined and developed
  • A focus on building sustainable solutions goes a long way if you’re planning on staying in an organisation for a long time: you don’t want to be leaving a scorched earth of technical debt as you jump from project to project and keeping operational teams engaged is paramount
  • Being across many things at once comes with it’s challenges, but it means you can be more effective in decision making because you understand more context
  • Straddling both senior management and engineering teams equally can be challenging but is rewarding because you’ll need most people on your side
  • Being open and sharing in thought with lots of documentation (even if it’s a work in progress) helps to build integrity

This brings me to today

Right now, I’m still acting as an Engineering Manager, holding the fort until the recruitment process is completed. I’m still happy to continue in this role in an acting capacity, because I have a great team who work on some pretty cool products and platforms. I’m still looking forward to getting some more time to draw the next diagram of course!

Plot, Diagram, Plan, Text

(I couldn’t help myself)

Inspiration for this post came from: https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html