Violinists playing in an orchestra

When someone asks if I know a developer

Laurie Young
strategy
July 25, 2023

When a company first reaches out to me, frequently, it’s with one of two questions: “Do I know any good developers?” or “Am I available as a developer?”. They think adding another developer will give them faster, better results. But that’s only sometimes the case.

These companies are never technology-first companies, and they rarely have a development team with a long track record of success. Those companies have a process in place for finding new developers. Instead, they are companies successful in one industry that are building bespoke software in-house and are experiencing various frustrations: the speed of the development, the quality, and multiple similar issues.

Adding another developer, even a good one, is rarely the move that solves these issues. That requires a more holistic approach to the technology strategy.

Adding more developers

Imagine an orchestra where a few things aren’t quite right. Some of the musicians are interpreting the music strictly, while others are taking an interpretive approach. The room they are playing in has poor acoustics, and some players are reading an outdated copy of the sheet music, all in front of an audience that thought they were attending a rock concert. No one is likely to enjoy the result.

Adding a new violinist, even the best in the world, won’t help.

Similarly, adding a new developer to a software project where a few things aren’t quite right often doesn’t help. Much has been written about why adding new developers to a project can be counterproductive, and I’ll leave my complete explanation of why to another post. But I’ll briefly mention a few of the main reasons:

  • Adding a new developer does little to smooth out any communication issues causing problems. It makes those issues more costly by increasing the communication needed.
  • It focuses on fixing parts of the code that are hard for someone new to the project to understand. While that is very important, it’s rarely the root cause of whatever problems triggered the budget approval for a new developer.
  • It takes the focus off checking if the overall strategy needs to be modified to set the project up for success, which is often the best way to improve the project.

What makes a project succeed?

It comes as no surprise that many different things go into making a project successful. In my experience, it comes from digging deep into four main areas:

  1. How the project aligns with the business. This requires many decisions, including how important the project is for the company, how it contributes to the business’s goals and how keen the business is to build an in-house development team.
  2. Who will use the software? This requires understanding who the users are, what they need to use the software for, and what user design makes that straightforward.
  3. What the development practices are. This requires a development team with the right combination of skills and the right processes for that team, as well as a vision for the project’s technical design and how that contrasts with its current design. Sometimes, it does include looking for additional developers.
  4. Planning for upkeep & stewardship. This consists of a plan for how the system will be maintained and developed in the future, for example, in response to changing user needs, new legislation, or competition from competitors.

You can read more about each of these in my post on technology strategy.)

Do you need to look at the big picture, or do you need to hire another developer?

Of course, there are times when the root cause of frustrations is not enough people writing code, and then there are times when the bigger strategic picture needs to be looked at. Generally, companies get a smooth process for finding new developers in place before they have finished getting the big picture as well defined as it needs to be. So if they reach out to me asking for developers, the chances are high that they haven’t yet got the big picture sorted as well as it can be

Besides that heuristic, it’s typically easy to tell which of the two situations applies. You’re going to benefit from looking at the bigger picture if any of the following are true:

  • Misalignment between the tech team and business goals. This is a big one and one of the problems I most often help companies with. There is usually a world of difference between what the business and tech teams think is essential, and getting these two aligned can be the start of fixing many other problems. Though in practice, it’s hard for either side of the debate to accept the other side’s importance on their goals.
  • Constantly missed deadlines. Missing deadlines can be a symptom of misaligned expectations, not understanding how many other tasks will fall on developers, or needing a process for handling the inherently hard-to-estimate nature of software development.
  • Increasing numbers of bugs. When the number of bugs seems to continue to go up rather than down, it can be a sign that there isn’t clarity on which parts of the system need to be most pain-free, or a lack of a process for catching bugs during development
  • Frustrated or burnt-out developers. When a project isn’t optimally set up, developers often get overloaded, burnt out, and just quit. Much like the musicians in our earlier example, when working in a team is a painful experience, good developers (or musicians) will look for a better place to be.

How I approach this

When I work with a company, I usually have to introduce these bigger-picture concepts and/or work with the team(s) to fill in the details, which vary significantly from project to project. Often when we look through the details, there are differences in expectations that we need to identify, address, and resolve - direct conflicts between points seen as “good” from different perspectives. For example, I’ve seen tensions between the need to develop something quickly vs the need to be innovative to secure a market position, tension between increasing the profit for the business vs improving the experience for the user, and many more.

It’s common to find that there are processes and technical details about how the code is developed, tested and written. I’ve seen cases where different developers on the same team have different opinions on how they are building the code.

It’s important to always “see with your eyes” and make sure you have a realistic picture of the pain points and their root causes, and that’s where I always try and start. Then I work with the company’s business and technology side, helping them learn the techniques and processes that bring everyone onto the same page, with a consistent communication system that works for everyone.

Summary

In software projects, often adding more developers isn’t the solution when facing a challenge. Just as a world-class violinist won’t fix an orchestra’s misalignment, a new developer won’t fix a project’s more profound issues. Success in software project development hinges on an approach encompassing business alignment, user needs, effective development practices, and a commitment to system stewardship. Before rushing to expand the team, I recommend businesses look at their technological strategy and check that it’s pulling everything in the same direction.