People Are Not Your Most Important Asset

Heresy! How dare you challenge the most treasured platitude in software development. Well, I'm sorry, but it's just not the case. The most important asset that any software development organization has is...

Relationships

The relationships between the stakeholders and the development teams. The relationships they both have to the customers. Relationships to external vendors, recruiters, media, and industry groups. It is through these relationships that we learn, grow, promote, sell, transact, and generally move the machinery of business.

On a development team, for example, relationships are incredibly important. A gelled team is probably the single most valuable asset any software organization has. A collection of talented individuals, able to work together toward a common goal. Able to adapt, to learn from each other, to play off each others strengths to accomplish what needs to be done.

Most organizations, however, don't value relationships. As trite as it may sound, they actually do value people, or resources as they're more commonly known. When something needs to be done, they assemble a pseudo-random assortment of these assets, call them a "team" and then unleash them upon the organization to accomplish their stated goal without regard for the technical debt they create.

This practice, commonly known as Project Management (perhaps you've heard that term before?) is stunningly effective at destroying your two most important assets: your teams, and your code. By organizing a random assortment of developers, without any real shared culture or technical principles you ensure that they are powerless, inefficient, and ineffective. Then, by giving them a goal that nearly demands that they create mountains of technical debt in order to achieve it, you ensure that every code base they touch as part of their "project" will be worse, much worse, after they've left. Then, just to make sure those relationships among the development teams are thoroughly destroyed, you rip the team apart again and scatter them to the four winds. On to their next project, which will cost that much more and go that much slower thanks to all the debt they created on this one.

Project Management needs to die. It's harmful, it's expensive, and there's a better way. They key to finding this better way is in how you allocate the money.

First, lets start with the functional unit of software development: The Team. I've said for a long time that software companies can't build software...they're too big. Only teams can build software, and as a software development organization, your goal should be to build the best teams possible.

What should these teams look like? They should be cross-functional and value oriented. So, rather than having a UI team, and a database team, and a service layer team, organize into teams that can actually deliver value. Think about how your organization makes money. Think about how products move through the company (from concept to cash, as the cool kids like to say), and create teams that have all the skills, resources, and authority to move that product all the way to the point of sale. Start small. Then leave them to learn and deliver. If they're able to deliver sufficient value, give them more money. They can use that money to hire more people, buy more resources, or whatever else they can to deliver more value.

The most important thing, however, is to leave these teams intact. The relationships on the team form the engine that allows them to generate value for your organization. While it's OK to add a person or move a person every once in a while (twice a year, perhaps?), changing too much will destroy the relationships, the culture and the established practices...the heart and soul of the thing that makes you money. Don't mess with that.

Comments

[Dan Quinn]

Relationships and barrier removal are vital to successful projects, but the people need to be good for those two assets to be successful. Bad and/or unmotivated coders won't produce good code just because you put less processes and documentation requirements in their way. Good relationships won't get build if people naturally don't get along or like to work with others.

[Ben Rady]

Given the choice between a cohesive team of junior developers, and a team of experts who won't talk to each other, I'll go with the team of juniors. Changing interpersonal behavior is really hard. Teaching technical skills is easy by comparison.

[Andrew Kazyrevich]

Well, I doubt if you really think that a team of juniors is better than a team of experts - unless you also plan to save some money on juniors ;)

But I'm totally agree with relationships being the most important asset. It's esspecially evident on distributed teams - personal bonds get created quite slow there, while having good communication between local sub-teams is as good as gold.

Great post. In Microsoft's "Distributed agile development" paper they mention this idea several times as well: invest in relationships and don't break up good teams.