A big part of my human management philosophy is that the best managers are those who are deeply in tune with the work their folks are doing. If you’re managing carpenters, you should pick up a hammer. If you’re managing developers, you should fire up an IDE. If you know the potential roadblocks, speed bumps, and general annoyances your folks are facing, you’re just that much more able to help facilitate their movement past it.
But, one of the other things you learn quickly as a manager is just how much you give up in terms of the day to day work, and how easy it is to drift away from being in tune with it. Management, in many ways, is a career reset, because you’re really focusing on building a brand new set of skills.
That doesn’t mean you have to – or should – leave your old career behind; because as soon as that happens, you’re no longer as effective for your folks. When you lose understanding of the work, you lose the ability to effectively advocate for the people doing it.
So, what’s a manager to do?
You make the time to build. Take on the mantle of the Full Stack Manager. Find ways to build it into your job. It’s a responsibility to your humans.
Recently, I spent some time revisiting the roles within my team at hypergrowth, inc. I wanted to get more clarity around the work that folks within the team were responsible for (and capture the things they weren’t, but were doing anyway).
One of the roles I put some more clarity around was mine. As much as I want to define the roles within my team, I want to make sure that the team is just as clear about what my role is, and the responsibilities I have.
One of the things I wanted to make crystal clear in that work was that I was making a commitment to contribute to the work my folks were doing, albeit at a lower percentage of my overall list of responsibilities. So, I set a Support load of 5% (about 2 hours a week) and a Development load of the same. As you might notice, this isn’t a whole hell of a lot – but it’s enough that I get into the fray and see the work up close.
But there’s another part that I didn’t capture in the list of responsibilities, and that’s that I put in my own time to make sure I’m keeping my programming skills up to snuff. I don’t expect my folks to do this – I’d rather they make use of the 15-20% Development time set aside for them during their work week.
One recent result of this was the creation of an integration for work, which collects metrics on triage channels. I had a specific problem to solve, which was determining how our own triage channel was being used, and what response times looked like. I knew from anecdotal experience that this was good, but actual metrics trump anecdotal evidence any day of the week.
I could have passed this on to one of the folks on my team, and they would have done a fantastic job with it (seriously, my folks are amazing). But I knew this was a good way for me to dig deep into hypergrowth inc’s API, and would give me good insight into the experience of both our developers and my folks.
Now, I suspect there’s also a sneaky side benefit to continuing to be a builder. My folks might be able to tell you otherwise, but I think that getting involved with and knowledgeable about the work is a key way of building respect and trust within your team, especially if you inherit an existing team. By building with them, your humans not only know that you’ve got their back, but that you know why it’s important to have their back.
And that’s really the best way to build.