Team Structure and Disruptive Innovation

For many years I have been fascinated with the relationship between team structure and innovation, assuming that such a relationship exists. In my career spanning over 18 years, I have worked with companies large and small. I have worked on products that could be considered innovative, and others that were not really innovative or disruptive. What follows is a brief discussion on the learning that I gleaned out of these experiences.

The history of structured teams dates back to the industrial age from when the assembly line evolved. Companies like Ford figured out that by breaking down the manufacturing process into discrete steps, and by having an employee specialize in performing that step, they could make the manufacturing process more efficient. This works great for manufacturing. Why? It works great because the cost of failure is very high. It would be be the most imprudent decision for Ford Motor Company to attempt to build the next Thunderbird and realize at the very end that the engine block could not be mounted on the chassis because the bolt holes on the chassis and the engine were not aligned. A lot of heads would roll for that kind of blunder.

So, what does this mean? It means that structured processes and methodologies work best in situations where the cost of failure is high. In the technology industry, especially in software, the situation is (perhaps) diametrically opposite. The use of automation (continuous build systems, automated test tools, etc.) has helped reduce the cost of failure to a small number. This permits rapid and frequent iteration, prototyping, and experimentation.

Did the above paragraph sound like a plug for the Agile movement? If your answer is “yes” you’re correct! My intention is not to confound the discussion around team structure and innovation with a plug for the agile movement, but it is important that you, the reader, recognize that there is a relationship between “agile” principles and the ability to rapidly innovate.

In almost every software company I’ve worked for, there is a very crystalline (as opposed to amorphous) structure that is established for the development team. A typical software team is composed of a team of engineers (development, QA, “release”) who are directed by one of more functional managers (engineering managers, directors, qa managers, etc.) and this “orchestra” is conducted by a project manager. The role of a project manager is typically to “ensure the work gets done.” That means that the project manager is vested with the responsibility (not always the authority) to develop a project plan, ensure that the team faithfully executes to that plan, and that the deliverables are created on the dates that the team committed to at the beginning of the project. Little wonder, therefore, that the project manager is often the most “frazzled” person on the project. You often hear the term “herding cats” used to describe the work that project managers do.

At Meteor Games, I recently had the opportunity to work on the prototype for a new game. We were given a high-level direction by the Product Owner and asked to come up with a prototype for the game. The team consisted of 2 engineers (one each for PHP and Flash), half an artist and half a UI designer, a game designer and me, in the role of Scrum Master, engineering manager, and anything else you could think of. We were trying to prototype a game that would be disruptive in the industry – something that would shake things up.

Right at the outset, the team expressed a need to be given substantial independence in determining what they were going to achieve. Given that most of the company was preoccupied with its survival, I was able to give the team the independence that they wanted. The reality is that the amount of “independence” wasn’t much. We ensured that the team signed up for what they were going to deliver each sprint and that the tasks that they signed up to do were not dictated to them. In addition, the engineers wanted some freedom in coming up with an architecture that would supersede our existing game architectures, thereby making the game more performant and lightweight. We still met every day for the standup. We managed tasks on a Scrum board. The team still accounted for the work that they did each day.

The result… In 6 weeks, we delivered a prototype that could be demonstrated to prospective investors! This was a 75% increase in efficiency compared to similar projects that Meteor Games had undertaken before. In addition, the software was bug free, highly performant, and introduced some features that would have made this game amazing.

Did this qualify as “disruptive innovation”? I believe it did, albeit in a small way.

So, what is the point that I’m making? It is this… It is my firm belief that a significant reduction in formal team structure, and the trappings of old-world project management, helped the team innovate rapidly.

So, am I advocating a complete elimination of team structure, project management, or even any kind of management? Absolutely not!

All I’m trying to say is that self-organization is a powerful motivator and that it needs to be encouraged in order to give software teams the freedom to innovate.

I’m back…

Apologies to anyone who has been expecting new content on this site. We were having a lot of issues at work which, ultimately, resulted in Meteor Games laying off almost the entire team on November 30, 2011. I, therefore, have a little more time on my hands right now and will be posting more often.