June 2013 Archives

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.

Tragedy of the Common Library

| No TrackBacks

Good intentions can go awry quickly in the world of software development. Imagine this common scenario: there are multiple teams building related projects at the same company. At some point, someone realizes that these teams tend to generate a lot of duplicate code; why not just create a common library that all the teams can reuse? Everyone agrees it's a brilliant plan, and so code begins to shift from each team's codebase into the common library.

Fast forward to two years later. Now everybody is using the common library to solve a lot of hard problems. That's good! At the same time, people would rather have a tickle fight with a komodo dragon than actually wade into the common code and make a significant change to the existing logic (author's note: tickle fight with a komodo dragon is not a euphemism). Why is everyone so afraid of the common code? Since a bunch of different teams have touched the common code, it's a giant mishmash of conflicting coding standards and duplicate abstractions. Even worse, all products now depend on it. The common library has become a Jenga tower, growing taller and more wobbly with each change. Everyone is now afraid to make sweeping changes in there, lest they send the tower tumbling down.

How did the common code get into this state? Well, it's because we're humans and that's we do: make a mess of our common places.

This problem is well known in certain circles as the tragedy of the commons. Wikipedia describes the problem as "the depletion of a shared resource by individuals, acting independently and rationally according to each one's self-interest, despite their understanding that depleting the common resource is contrary to the group's long-term best interests." This theory has been applied to problems like population growth, pollution, traffic jams, and now, janked-up codebases.

So, if this is a common problem because we humans are a bunch of dumb dumbs, what's the solution here? Well, this guy Ronald Coase proposed a solution that won him the Nobel Prize in Economics, and it's actually relevant to our problem. Coase theorized that, if property rights are well defined and negotiation costs are low, then just by assigning property rights, the interested parties will negotiate their way to a solution to the negative side effects.

How would you apply that fancy book learnin' to the common library? Well, you'd start by splitting the common library up into smaller packages, with an established owner for each package. Then, you make it easy for the teams to communicate and negotiate changes to these newly split-up packages.

Let's say that Team A owns the common Logging package and Team B suddenly wants a new feature in that library. In the olden days, Team B would've just hacked this up. Since it's not their codebase, they'd move fast to get this in, leaving few comments and no tests. After all, that's what everybody does in the common library and they know there's no one to call them out on it.

That won't happen here, though, since Team A is now married to this codebase. Team A could propose something like, "You guys do the work, then we do the code review and we'll own this long term." Team B could then make a counter-offer, like "How about you make the change, and in exchange, we'll implement your Feature Request X in the service client library that we own?"

You've now gone from a massive codebase with zero owners to a bunch of small codebases, each with a motivated owner driven to ensure quality throughout the lifetime of that code.

As it turns out, ownership and fast, easy communication solve lots of software problems. Let's do more of these things!

A few other people have written on this topic before me. Good thinking, folks!

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