On the formation of a software team

Software companies are tremendously interesting places to work, and to study the many aspects of how people structure, organise and interact during the execution of complex projects. As a comparatively 'young' industry, it would appear that we are still learning how to build organisations that thrive, and engender within our people the desire to perform at their peak for prolonged periods of time.


Command structures and styles vary massively between industries and organisations - and quite rightly so. The chain of command in the military is perhaps the most obvious example - and in the words of Jack Nicholson in 'A Few Good Men' - "We follow orders, son. We follow orders or people die. It's that simple."

Fortunately most software organisations don't have quite the same extreme consequences. And they don't have the same requirements as a clothing manufacturer or an estate agency or a fast food restaurant, or a hospital.

The command structures of these organisations need to be appropriate for their business model, for the characteristics of the staff required to fulfill their tasks, for the quality and safety of their product and for a hundred other reasons.

Creating a good software product has become a complex venture. It requires a broad range of skills, a huge dose of creativity, exploration, attention to detail, analytical thinking, business acumen, determination, rigour, direction and there is no single way to ensure success. Software projects are much more about people than they are all the technical nerdy stuff. For the average project, the choice of people will be the most important factor in achieving as successful outcome.

Technologies come and go and there are often a dozen ways to overcome the technological aspects of the project, but putting together and looking after the right team is the real challenge.

This leads me nicely to one of the many differences between small companies and SMEs / larger corporates - especially when it comes to recruitment.  I've been on both sides of the interview table throughout my career, and as a recruiter, we start with something like a 'role profile'  or 'job specification' - but we're really recruiting a person.  The role profile is often taken as a starting point for attracting people with appropriate skill or behaviours.  However, the profile is often quite 'loose' in the smaller organisation and much more rigid in a larger organisation.

High performing teams are built with a bunch of people who work well individually, and more importantly, together.  To achieve these teams, we recruit the right people, not simply some good people to fill a set of roles that we believe our team requires.  The delicate balance of the team dynamic changes with each person that we add, and that also affects the desirable characteristics of the next person that should be added to the team to keeping things working well.

Small organisations create a great team by fully understanding the capabilities of the people that they have, and utilising them in 'roles' that are a perfect fit. Any capability gaps can then be plugged by recruiting a person who demonstrates copious amounts of the missing capability.  We still have to ensure that collectively, the team has a good mix of traits such as those defined in Belbin team roles.  If you have no "completer-finisher", you will struggle to deliver, and if you lack an implementer, then you will struggle to get stuff done.

In the smaller organisation, your people will wear these roles more like hats, and will typically take ownership of two or three Belbin roles, as well as two or three job roles - often from areas where they have significant prior experience. One finds that the make up of the team in a successful start-up has (almost by accident) somehow brought together a small number of people who fill the required work roles and team traits.  This might be achieved with 3 people, though it is likely to be more complete with 4 or 5.

Let's take the extreme an yet common example of a minimal software start-up of 2 people.

• One is often a charming gregarious extrovert, while the other is often an analytical introvert
• One is often a serial risk taker and the other is more risk averse
• One sees the big picture and the other the detail
• One really wants to build it and the other really wants to sell it
• One is often the crazy ideas person, and the other is much more of a realist.

It's not to say that a single person can't have all the qualities required to build a version 1, but the common pattern is 2 people with complimentary skills and personality traits, that work well together and between them, have the characteristics to get the job done. Typically, one is a silver tongued 'business' type with sales & marketing skills, who is great at connecting with other people. The other is a technical guru of some kind who has most of the skills required to build the product.  As to where the idea came from, or who is the risk taker - it could be either.

At some point, as the team grows, a level of specialisation takes place, especially once the team has enough people to have some duplication across either skills, capabilities or traits. I was once working in a team that was part of a growing company. The shape and culture of the company had changed and now required a more tightly 'managed' relationship or 'interface' to the rest of the business. We did not have anyone playing such a role in the team as our previous working methodology had not warranted it.  We did however, have a natural organiser, with great communication skills and tenacity. Someone who always took excellent notes, and could draw on them at the drop of a hat in tough discussions to argue with facts and conviction. This person was a specialist database developer in our team - and a very capable one at that. However, we had a couple of database developers and our 'backend' work was dwindling slightly as we were moving much of our previous logic away from stored procedures and into middle ware.

Our DB developer accepted a role change and became a project manager come product owner for the team. The role fit her skills very well, and she did a great job for our team and became very successful in her subsequent roles.  Most of the problems of bringing someone new into the team (especially in a senior role) were avoided. Her personality was already part of the team and she was highly regarded by the other team members - it was probably the best result we could have achieved and our team continued to perform well - almost without skipping a beat.

Again, very small organisations have the agility and ability to make these changes very easily. Larger organisations might end up with 10 internal candidates applying for such a role because they have many more people with the required skill set already in the business.  They might have 10 people that on paper, have the skills and previous achievements to suggest that they would be great fit for the 'role'.  But, we're talking about a well established and performing team where the 'role' is not our primary concern.  The real question is "would the person be a great fit for the team?"

Small successful software companies have taken time to grow organically, providing the time and space to really focus on the right people to bring in at the right time to address a very specific set of skills or traits that have become a requirement and will therefore have a significant benefit to the team as a whole.  Conversely, finding 15 new java developers for a large greenfield project within a large organisation, is seldom going to result in that delicate balance of skills, traits and personalities that you might find in an established and high performing team.

It's hard to overstate just how delicate this balance can be, and in a future post, I'll talk about the devastatingly simple accidental destruction of a team.