Developer motivation versus team growth
April 4, 2008
It seems hard to keep the motivation and engagement of a team of programmers at its top when their software's growth requires the team to expand. There is a fine line to walk there, along which striving to preserve individual creativity might be a key to maintaining balance.
Most software products grow out of the joint effort of a small number of developers, usually something like 3 to 5 persons. A small group like that can be a fantastic catalyst for individual energy. Everyone gets space to exert his or her own creativity. The product being only at its birth stage, team members are there for fun rather than for profit. There is a positive competition between team members since individual energy can focus on the challenge itself rather than on the hierarchical and managerial issues around it. This list could go on for a while. What I am trying to tell is that in my experience, the most creative and exciting development teams to work in are small ones.
That's an idea emphasized in agile methods and scrum who heavily believe in strongly focused, self organized and SMALL teams of developers.
In 'Peopleware', such teams are called 'jelled teams'.
When the number of developers in a team reaches a critical limit, somewhere around 5, the dynamic of the team changes. Roles are introduced, such as architect, lead-developer, CTO, boss. Decision making gathers within some roles and escapes others. An unhealthy competition grows when people strive to get those roles. People get bossed around. Developers feel they have no space left for their creativity. The fun factor tumbles.
Of course, team scale is related to product growth. It's because the software is growing that you need more developers. But if you insist on keeping them in the same team, you will get over the critical mass for jelled teams and loose the positive creativity in the team. I guess a way to avoid that would be to break overgrown software into smaller components and grow a jelled team around each of them. But it's easier said than done and can be hard to justify for management.
Team growth is not always directly related to code growth though. At places where management has taken over the engineers to decide over the product's future (which means at more or less every mature software company), management can cause teams to grow in completly artificial ways that are not respectful of the current balance of the jelled teams.
Let's take an example. A company has a jelled team of 5 that has been develloping a product over the last 5 years. The company also hosts a number of parallel teams working on related products. Management decides that the future of their product line requires a complete redesign of the product map, so they hire a number of software architects to decide on what to do. They hire those architects from outside the company because they worry that in-house developers promoted to the architect role would remain too loyal to their team and product and hence have a biased view on what to achieve. Those decisions make sense from their perspective, but out of mistrust for their most productive developers, this management has just given a death blow to its jelled teams.
Developers in jelled teams have given their souls to make their product a successful one. The very act of them doing so is usually what made the product successful, but that's something that non-technical management tends to be blind to. To maintain this level of engagement, you have to leave enough space for each developer to make design decisions and use his creativity. When you hire external architects, they will want to make design decisions. That's their job and that's what they enjoy doing. A conflict will occur between architects and developers on who gets to decide. Most likely, the architects will get the last word, because design is their role and the developers' role is implementation, at least in the management's simplified understanding of the craft of software development. Members of the jelled team will fill robbed of their freedom of creativity, and leave.
Management probably won't notice this chain of events. A few developers will leave. New ones will be hired. The new ones will do what the architects will tell them to do and everything will look good. But a process of natural selection has occured that will keep a certain kind of highly efficient and engaged developers away from this project. A few years later, the product will need a complete rewrite because no developer took on him to refactor the code, and no architect noticed the need.
All this boils down to the belief that successful software development is about getting the right developers. Some developers are just way more efficient than others. It has been proven in many ways and has grown into a widespread belief in the software community but it still remains somewhat of a taboo in many circles because it strongly implies that there is a kind of elit of software developers. It's unfortunate, because elitism has very little to do with what makes those developers be so productive. They usually do what they do for fun, seek no power and are little interested in career competition. To get those people, you don't even have to pay them much or to lure them with bright career plans. But you do have to offer them an environment in which they can create freely and together with people like them. Break this balance and they will leave.
Most software products grow out of the joint effort of a small number of developers, usually something like 3 to 5 persons. A small group like that can be a fantastic catalyst for individual energy. Everyone gets space to exert his or her own creativity. The product being only at its birth stage, team members are there for fun rather than for profit. There is a positive competition between team members since individual energy can focus on the challenge itself rather than on the hierarchical and managerial issues around it. This list could go on for a while. What I am trying to tell is that in my experience, the most creative and exciting development teams to work in are small ones.
That's an idea emphasized in agile methods and scrum who heavily believe in strongly focused, self organized and SMALL teams of developers.
In 'Peopleware', such teams are called 'jelled teams'.
When the number of developers in a team reaches a critical limit, somewhere around 5, the dynamic of the team changes. Roles are introduced, such as architect, lead-developer, CTO, boss. Decision making gathers within some roles and escapes others. An unhealthy competition grows when people strive to get those roles. People get bossed around. Developers feel they have no space left for their creativity. The fun factor tumbles.
Of course, team scale is related to product growth. It's because the software is growing that you need more developers. But if you insist on keeping them in the same team, you will get over the critical mass for jelled teams and loose the positive creativity in the team. I guess a way to avoid that would be to break overgrown software into smaller components and grow a jelled team around each of them. But it's easier said than done and can be hard to justify for management.
Team growth is not always directly related to code growth though. At places where management has taken over the engineers to decide over the product's future (which means at more or less every mature software company), management can cause teams to grow in completly artificial ways that are not respectful of the current balance of the jelled teams.
Let's take an example. A company has a jelled team of 5 that has been develloping a product over the last 5 years. The company also hosts a number of parallel teams working on related products. Management decides that the future of their product line requires a complete redesign of the product map, so they hire a number of software architects to decide on what to do. They hire those architects from outside the company because they worry that in-house developers promoted to the architect role would remain too loyal to their team and product and hence have a biased view on what to achieve. Those decisions make sense from their perspective, but out of mistrust for their most productive developers, this management has just given a death blow to its jelled teams.
Developers in jelled teams have given their souls to make their product a successful one. The very act of them doing so is usually what made the product successful, but that's something that non-technical management tends to be blind to. To maintain this level of engagement, you have to leave enough space for each developer to make design decisions and use his creativity. When you hire external architects, they will want to make design decisions. That's their job and that's what they enjoy doing. A conflict will occur between architects and developers on who gets to decide. Most likely, the architects will get the last word, because design is their role and the developers' role is implementation, at least in the management's simplified understanding of the craft of software development. Members of the jelled team will fill robbed of their freedom of creativity, and leave.
Management probably won't notice this chain of events. A few developers will leave. New ones will be hired. The new ones will do what the architects will tell them to do and everything will look good. But a process of natural selection has occured that will keep a certain kind of highly efficient and engaged developers away from this project. A few years later, the product will need a complete rewrite because no developer took on him to refactor the code, and no architect noticed the need.
All this boils down to the belief that successful software development is about getting the right developers. Some developers are just way more efficient than others. It has been proven in many ways and has grown into a widespread belief in the software community but it still remains somewhat of a taboo in many circles because it strongly implies that there is a kind of elit of software developers. It's unfortunate, because elitism has very little to do with what makes those developers be so productive. They usually do what they do for fun, seek no power and are little interested in career competition. To get those people, you don't even have to pay them much or to lure them with bright career plans. But you do have to offer them an environment in which they can create freely and together with people like them. Break this balance and they will leave.
