The First Steps When Taking on a New Team
You’ve got the promotion to a Software Engineering Manager – Congratulations!
But what next?
There is plenty of generic leadership advice out there, some of it excellent and some of it less so. Finding good software engineering specific leadership advice can be challenging. Many companies don’t have great leadership training. So where should you go for help?
I’ve helped several new Software Engineering Managers with some of the strategies and tactics that I’ve learned over my 22 years of experience. I have decided to start publishing some of these for folks to try out on their own, with the hope that I can help more new Software Engineering Managers bypass some of the painful lessons I’ve learned in the past.
I will break these out as a series. You can follow me on LinkedIn or Twitter to keep up to date as I write and post about leadership.
First up - my thoughts on new teams reporting to me and the discovery process I take.
Getting Started
I am not perfect and I don’t like command-and-control structure in organizations. Rather than jump in and start dictating what “the perfect process” is or “best software stack” is, I want to get to know the context.
Here is a list of initial activities that I’ll do:
- I want to get to know the team topology: where they sit in the business, what value they bring to the business, what services they support, their technology stack, what the workflow is, and where the pain points are.
- I want to get to know the people on the team. I typically do this in a couple of ways.
- With my direct reports, I’ll schedule an introductory 1:1, where we’ll establish a cadence (typically weekly, but no more than every other week) for ongoing 1:1s.
- With the rest of the organization, I’ll schedule an introductory 1:1 and quarterly skip-levels.
- The introductory 1:1s that I schedule are an opportunity to introduce myself, a little bit of my background, and to start building a relationship with my colleagues.I want to understand what drives them, what they find interesting, and what their general skill level is.
- I want to get to know the software. Typically I can do this by either getting demo’s or access to codebases that I can review myself. Another data point is typically reviewing the last few code commits and code reviews - that can tell a lot about the general practices of a team.
- I want to understand the monitoring, logging, and alerting strategies that are in place for each of the systems.
- I want to meet peer/partner organizations and get familiar with their process, what their opinions on the engineering organization is, what their roadmaps look like, and what pain points they might have.
Wrapping Up
This isn’t an exhaustive list - instead, I’ve tried to highlight some of the key processes I take when I start working with a new team. If you’re a new manager, find these tactics useful, want to follow along on the series, or have questions feel free to reach out to me.
