The Perfect Team – A Thought Experiment

Warning: Illegal string offset 'filter' in /var/sites/t/ on line 1409

Working at office

One of my favourite blogs at the moment is Wait But Why. A feature they have introduced recently is the dinner table, where a question is posed for reflection, usually in order to explore values. Inspired by this concept, this week I thought I would do something similar. The question – what does the ideal software team look like?

Imagine you have been hired to lead a team of developers on a project to develop a new web-based product. Your rather secretive and dictatorial boss has provided you with only the following information, upon which to base your recruitment:

  • The product will consist of a web layer, a middleware layer, and a database layer.
  • You must use .NET and SQL Server.
  • This will be a complex and ground-breaking product, with significant complexity in each of the three layers.
  • Initial estimates are that this will take 1000 man-days.
  • Your team can be as small or large as you wish, but you must not exceed the 1000 man-day estimate.
  • You have at your disposal a superhuman recruitment team. You specify the skills and traits you want from your team members, and they will find people who fit the bill. Assume they will all be intelligent with many years of experience.
  • For each team member, you can only specify the following:
    • One Primary skill (technology-specific)
    • One Secondary skill (technology-specific)
    • One Primary type of experience (technology-agnostic)
    • 3 Primary Personality traits

My Answer

After some deliberation I have decided upon a team of 3, which looks like this:

Team Member 1

Primary skill: ASP.NET MVC
Secondary skill: JavaScript
Primary type of experience: Single Page Applications
3 Personality Traits: Communication Skills, Drive, Self-Management

Team Member 2

Primary skill: C#
Secondary skill: SQL Server
Primary type of experience: Design & Architecture
3 Personality Traits: Communication Skills, Drive, Self-Management

Team Member 3

Primary technology: SQL Server
Secondary technology: C#
Primary type of experience: Big Data
3 Personality Traits: Communication Skills, Drive, Self-Management

Why a Team of 3?

Fortunately (and unusually) in this scenario, there is no deadline for delivery. The only requirement is that we don’t spend more than the estimated number of man-days. So for example, we could hire one person to work for 1000 days, or 20 people to work for 50 days.

Generally speaking, I am not a fan of big teams. Bigger teams require more communication, and greater overhead in terms of processes. There is also a reduced sense of individual ownership and accountability. Fred Brooks famously discussed some of the problems of adding manpower to speed up delivery in The Mythical Man-Month.

Following on from this, you might conclude that the optimum size for a team is one. I have worked in environments where the average team size for a given client project was one, and one of the reasons for this was indeed the feeling of personal ownership and responsibility for a project. However, a problem with this approach arises with more complex projects, such as our fictional one, which we know is significantly complex in the database, middleware, and web layers. No single person could be an expert in all three of these areas, and this reality is represented by our single primary technology restriction in any case. Even if such a super-developer did exist, they would potentially be overwhelmed by the responsibility of delivering such a large project alone, and having someone to discuss issues with is always a good thing.

In this case, as there is significant complexity in the database, middleware and web layers, I have decided to recruit a team of three, with each team member being an expert in one of those layers.

Team Member 1 – Web Guy

My web guy is an expert in ASP.NET MVC, with some experience in JavaScript, and specific experience with Single Page Applications.

As we have been instructed to use the .NET stack, I have chosen MVC as the framework for the web layer. It is open source, well supported and largely preferred within the Microsoft stack. I was torn between specifying MVC or JavaScript as the primary skill, as we are living in an age where ever more logic is creeping into our JavaScript. However, there are a number of JavaScript frameworks with large, active communities so our web guy will probably be more than capable of writing the required JavaScript. These days there is less need for boiler-plate JavaScript than ever, with the move towards data binding and HTML directives in frameworks such as Angular. Furthermore, by requiring my web guy to have significant experience with Single Page Applications, I have essentially specified that they need to know enough JavaScript to create a non-trivial SPA. We may decide that a SPA is inappropriate when we receive more information about the project, however as it is a web-based product it is likely that there will be at least some SPA-type functionality in there, and experience with SPAs is a good indicator of contemporary web skills.

Knowing ASP.NET MVC also requires knowledge of a server-side language, which would probably be C#, therefore my web guy should be able to support my c# guy to some extent.

Team Member 2 – C# Guy

As there is a requirement for a complex middleware layer, I decided to hire an expert in C#. I’m excited about this guy. Not only will they have significant experience in design and architecture, but also SQL.

I was keen to include at least one team member who knows their stuff when it comes to design and architecture. In order to become an expert in these areas, you really need to know your stuff, all the way from the SOLID design principles, to design patterns, to available technologies and frameworks, along with their advantages and disadvantages. I’m a firm believer in the value of technology-agnostic principles as a guide for software development. As Steve McConnell put it, we should be able to program ‘into’ a language, rather than program ‘in’ a language. As an expert in design and architecture, my C# guy will be able to advise my web and database guys on various topics.

My C# guy’s secondary skill is SQL, so they should have no problem understanding and interacting with the database, through an ORM or otherwise, and will be able to help out with database work as required.

Team Member 3 – Database Guy

Again, I thought that the complexity in the database would probably warrant a SQL Server specialist on the team. As a secondary skill, my database guy knows some C# so will be able to support C# guy if needed.

In terms of an area of experience for database guy, I have specified Big Data. Big Data is perhaps an overused term in the software industry right now, however, if someone can claim to have genuine experience with Big Data, they ought to know how to design and manage big databases. This means that they probably have an excellent understanding of indexing, disaster recovery, database design and of course scalability. These represent perhaps the most likely challenges for our project, therefore I concluded that if they are good with Big Data, they will probably be good enough for our project.

What about Testing?

I struggled with this, but ultimately decided not to hire a tester. I figured that if these three guys really are experts in their chosen areas, they will have some experience with testing, and will hopefully be able to share the load in terms of designing, organizing and executing tests. I could have specified unit testing, integration testing or functional testing as a secondary skill for one of the team members, but I felt that the chosen skills were more important. This is not to say that I think testing is unimportant, rather that it is less important as a primary skill than those I have specified. In reality I might hire a tester towards the end of the project.

Personality Traits

After toying with various combinations of personality traits, and considering giving team members different personalities which might complement each other, ultimately I decided upon the same three key personality traits for each of my team members:

Communication skills, drive and self-management.

We all know how important it is to be able to communicate in software teams, however this is a skill which is often overlooked in the recruitment of software professionals. What I am hoping for here is developers who are not only able to clearly articulate ideas, but to also know when to ask for help, and how to ask for help. I am hoping they are respectful to each other’s needs, supportive to one another, easy to get along with, and with a sense of humour. Perhaps I am stretching the definition of ‘communication skills’ here, but I could think of no better phrase to encompass these qualities.

Drive is one of my favourite characteristics when it comes to describing good developers, and good employees in general. There has to be a desire to do a good job, probably out of pride and satisfaction in doing something well. It is not much good being a good communicator if you have no inclination to work hard and deliver something great.

Finally, I chose self-management as a key skill for my team members. I want them to be able to take a requirement, break it down into its tasks and prioritize those tasks. They need to be able to establish goals for themselves, and plan well enough to deliver on time. They also need to know when it is time to go the extra mile, and when it is time to go home.

Final Thoughts

There were a number of skills and personality traits which I considered for my team which didn’t make the cut. These included CSS, web design, deployment, performance, openness, honesty, troubleshooting, enthusiasm and others. Ultimately I sacrificed these, which tells me what I truly value in a developer and a development team, and this will certainly influence me the next time I need to recruit.

How about you? What are the key skills, experience and personality traits you would look for in a developer, or if you are not a developer, in your own industry?

Share Button