There’s a safe space when you transition from engineer to manager, and it is in the title: “Think like an engineer, act like a manager”. By that I mean it’s the way new managers often approach situations, and that’s not necessarily wrong, it’s just the safe spot for those of us new to managing. You’ve spent years thinking like an engineer, attacking problems, looking at all the data available to you and devising a solution. Now that you’re managing, you see a problem and try to think how you would solve it yourself, then you tell your team to solve it as you prescribe. That works, and it’s an effective management style for getting things done, but in my opinion it leads you into boxed thinking and stifling your team. Not to mentioned trying to solve all the problems yourself while doing all the other things you need to do is exhausting and stressful. Part of management is about growing your people, letting them lead, explore and create, and building a team that cooperates and works together to find solutions. Engineers by nature like to solve problems, and prescribing solutions that they perhaps don’t agree with can lead to them digging their heals in, thinking you’re an idiot, or looking to join other teams.

At the same time I think it’s incredibly important as an engineering manager to have credibility, that is, to not only understand how to manage people, projects and time, but to have the technical clout to be able to mentor and guide when needed. It’s hard to keep your skills sharp when you’re time is spread so thin, so carving out a little time to hone your skills becomes increasingly important.

So where does that leave you? It’s a knife edge to balance on for a while as you figure out your management style. I’ve found some things that work for me, but there’s always room for other things to learn.

Sometimes you over rotate into the management side and that can be just as challenging and frustrating. Generally we got into engineering because we loved building things, and I definitely notice my mood changes when I haven’t had a chance to code something for a while. I imagine if a writer stopped writing and just talked about writing all-day-every-day, they would probably feel the same. Coding is cathartic and most definitely a creative outlet for me.

There’s also seemingly a few milestone as you manage a team, where you find yourself hitting new “stages” of management. Team size is probably the main thing that dictates between being a full time manager and a hands on manager. But interestingly (at least to me) there’s a point when you have your first team leads and supervisors that you can leave alone to manage certain areas where you suddenly find yourself having enough time to be hands on again, if you choose to do so. I know a lot of managers with larger teams that aren’t hands-on at all, and that’s fine, it’s a choice. Sometimes as a manager you are consumed by the feeling of needing to set and constantly tweak your strategy and vision, having time to be hands-on seems incomprehensible. For me, I like to pick an area that isn’t on the critical path of any of our projects to hack away on and maintain some skills (or learn new ones).

If we ballpark the milestones, they are roughly:

  • 0-8 employees - Partly hands-on. You still have time to code and learn and solve technical problems.
  • 8-15 - Full-time Manager. Your time is consumed by meetings, planning, deadlines, prioritizing, and making adjustments.
  • 15+ - With one or more supervisors/managers, you might find you have time to be partly hands-on, if you want to be.

+/- a few on either end of the ranges depending on your personality, management style, work habits, employees, team leads, etc. There’s probably another few levels where you reach say 30+ that it’s just impossible to be hands on in any significant way, but I haven’t been in front of that size of a team so I couldn’t say.

So what are some things to do?

Well, you can start by finding a niche off the critical path. Having a personal side project, or fixing the odd bug are some other ideas. The important thing is to use the skills and tools you’re asking your team to use, or things that your team may use in the future. Give yourself the opportunity to explore and create, while also staying current with your teams technologies.

Another thing I love is the concept of peer hack time. It’s a good chance for me to discuss technical issues with my team, work through problems, and get a chance to sit with them and see how they think, attack problems, and it maybe even helps me find ways to be a better manager for them. Even if I can’t find time to be hands-on directly myself, spending an hour or two hacking-by-proxy on a problem is the next best thing.