More Is Better

Here’s a interesting question that was thrown at me the other day. “Does adding more developers reduce code quality?”

The answer is “No”, so long as you remember something really important. Software development is most certainly a team sport. Recognise this, and you’ll see why adding more people to a project will be beneficial.

The flip side is also true. If you add extra developers, but treat them like individuals, then you are much more likely to put together a substandard solution.

As a team, you work together for the shared outcome. You agree practices and processes that help you go faster and protect you from basic mistakes. You can share the load in busy spaces, get extra pairs of eyes on complex parts of the system and use the expertise of others to fill in gaps in the rest of the team.

Much in the same way that a football team isn’t made up of eleven forwards, you don’t just add carbon copy skillsets to your team. Bring together a diverse group across skills, preferences and experience, and you’ll get a better solution to your problems.

Teams build software, remember this and you won’t shy away from adding to your group!

Coaching Leadership

We are Rational

In any organisation, there are people doing different roles. We’ve looked at how you can understand the complexity in these roles by putting yourself in the position of others.

When you get into a large enough organisation, there will be lots of people working in similar roles to you, some of whom you might never have met!

This brings a different problem to understanding a different role. Sometimes you’ll be thrown together on a project, and you’ll have to adjust your own frame of reference to get what’s going on with people in different teams or departments.

As you are intimately familiar with your own problems, then it’s really easy to fall into the trap of thinking all your solutions are right, and they are the rational approach. This is even more common for Engineers and those that work in various analytical fields.

Working with people who have the same role, you can then quite easily transfer this thinking, and project it onto colleagues unfairly. If they take approaches that are not the ones you would have chosen, or value different things, then you risk thinking that these approaches are irrational, purely because you are sure your solution is the rational one.

Watch out for this! It’s a quick way to conflict, and the fastest way to make sure you don’t make any real progress.

Instead, deploy some empathy. Use your expertise to understand the problems of your colleagues. What’s different about their solution? Is it cultural, is there a misunderstanding, or maybe something that they know and you don’t?

Be open and ready to learn, steer away from the accusing Why? and instead build your understanding with questions that start with “What …”

Spend some time just digging in to these concerns, and you’ll reap the rewards of closer working as you get the rationality of others, where you may have missed it before.