You're Not a Software Development Manager, You're a Software Helper

| No TrackBacks
I was having coffee with a new technical manager recently, and he asked an interesting question.  He said, "I just got assigned to lead this great team, but I don't know how to build trust with them.  How do you do that?"

I believe it's actually easy to earn trust as a manager, provided you understand a few very important things.  It's the team who contributes the key, valuable actions behind great software like writing, reviewing, and designing code, not you.  The people on your team are way better at this than you are, and they have far more context.  As a result, your team's contributions are much more important than your personal contribution.

What's your job then?  Simply put, your job is to facilitate those key, valuable actions.  You're not doing the work; you're empowering your team to do the work.  Your fancy job title could be translated into Software Helper.  (It's a humbling realization, but we'll get through this together.)  Understanding your role and communicating it to the team is the first step to building trust.

Okay, so if you're really a Software Helper, how do you do that?  You ensure the team has the data it needs to make great software decisions: think priorities and deadlines, performance requirements, external dependencies, feature roadmap, etc.  You find people who are blocked and connect them with people who can unblock them.  You find teeny, trivial workplace improvements (eg, Person A wants a track pad instead of a mouse) and pursue them aggressively.  You find where the bodies are buried in your team's codebase, get input from the team on how to address this technical debt, and you ensure the team gets time in the schedule to make these changes.  You find every possible opportunity to let your boss, boss's boss, and boss's boss's boss know about all the great work your team (again, not you) is doing.  You constantly ask, "How can I help?"

If you think of yourself as a capital-m Manager, then you'll obsess over the management part and begin to focus on the wrong things, like how do I get to manage a bigger team, how do I manage higher-profile projects, and how do I get fancier words into my job title.   Your goals are no longer aligned with the team; why would the team trust someone like that? Contrast that with thinking like a Software Helper where your goal is to build something great, just like all of the other engineers.

Being a Software Helper is hard work, and it requires a lot of vigilance and organization.  It's not as hard (or as valuable) as building the actual software, though.  Once you realize that, you start to build trust.

No TrackBacks

TrackBack URL:

About the Author

The Art of Delightful Software is written by Cody Powell. I'm currently Director of Engineering at TUNE here in Seattle. Before that, I worked on Amazon Video. Before that, I was CTO at Famigo, a venture-funded startup that helped families find and manage mobile content.

Twitter: @codypo
Github: codypo
LinkedIn: codypo's profile
Email: firstname + firstname lastname dot com