DevOps Zone is brought to you in partnership with:

Cody Powell (@codypo) is the cofounder and CTO of Famigo. Famigo's main offering is a cross-platform recommendation engine for mobile content, helping families find things like the best android apps, best iPad apps, and free apps. He's a graduate of Trinity University, an ardent supporter of the Texas Rangers, and he makes a mean mojito. Cody is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

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

07.01.2013
| 6457 views |
  • submit to reddit

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.

Published at DZone with permission of Cody Powell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)