Driving Development Team Improvements

Whom writes better software: a software company that sells a collection of individual products or integrated products & services such as Microsoft,  Apple or Ford?

Companies that offer integrated products learn from each teams: what works, next best ideas, failures, etc. There simply is so much interaction, it’s so natural, its like breathing. Conversely, individual product managers often have narrow, silo’d incentives. It’s all about the here and now. How can their executive management affect shared knowledge, growth, risk reduction in light of such resistance?

One thought is to rotate individuals between teams for as long as a year at a time. A developer, say “Joe”, drops what he’s doing and reports to a new team. His position is back-filled by another developer from another team. The time duration must be material: 6 or more months – enough to become a part of the new team and really learn from the experience. Upon Joe’s return, another team member may rotate to yet another team – or it may make sense to wait a couple of months to allow the original team to absorb change. This is to learn from Joe and/or the visiting developer.

Many mangers will argue they are “special”. Since almost all are special, none are special. The only exception would be if the domain knowledge requirements are so deep, new talent just won’t fit in. This in itself, is a concern. For now, let’s switch to normal, pedestrian products.

Assume Joe is an “outstanding” performer and moves to product B. He will quickly see how well his skills and talents can be mapped to this new product. He surely will learn new processes and tools. The feedback opportunities for him are significant. Joe also can develop a new network of technical resources.

Both product teams get “new” people: developers with strong company experience and likely not timid about speaking up. They know the company culture, history & expectations; quite different from a new hire. These teams can get a critical review of their processes, tools and team culture. In fact, they may find out they cannot easily tolerate change! Question: how long does it take Joe to get productive – hours, days? Hint: it better be hours.

Joe’s manager gets to see the impact of the absence, albeit planned and controlled. Is the team well prepared for new talent? Are processes and techniques so specialized as to require years of experience in order to become proficient? Does the replacement find the code and architecture straightforward? Why isn’t the way we do business obvious to someone such as Joe?

HR can learn a great deal from this as well. Employee evaluations are supposed to consistent across teams; cultures somewhat similar; management execution consistent as well. Did I mention it there’s no reason not to run an experiment by rotating management team members as well? Now we’re really going to have fun!

The company gets stronger networks between its developers, quite possibly encouraging less turn-over. Product teams inherently grow stronger as weak links are exposed and eliminated. Special, irreplaceable personal are identified and their risk is reduced. Legal exposure can be reduced by determining inconsistent personal actions. Manager evaluations can be augmented by observing how well rotated talent experiments work out.

What’s not to like?

Driving Development Team Improvements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s