.webp)
I am starting to hear this question in some way, shape, or form over and over again from clients
“Now that we have ChatGPT, can we reduce our team size or do things faster?”
This is a classic case of solving the wrong problem. Traditionally, when a software project is moving slowly there are four common reactions:
- Throw more developers at it.
- Blame the existing developers and look for ‘super stars’ who can come in and replace them.
- Replace the tools.
- Change the process/methodology.
Too Many Cooks In The Kitchen
We have been called upon many times to help recover a project. What we found was very different. There was no problem with the developers. No problem with the architecture. No problem with the tech stack. Everything pointed to the number of non-developer roles in the team that significantly slowed down decisions that the stakeholders were uncomfortable with. This was mostly due to the fact that it has resulted in revenue loss or increased costs.
Too Much Talking, Not Enough Action
It all comes down to one root cause. The more people on the team, the longer the decisions take. The decisions delay progress. Then, the front of the SDLC pushes the burden and creates a backloaded plan. When development/coding is the most important part of the SDLC, the time they get is compressed. Then unrealistic expectations arise, and the snowball starts rolling.
Visionaries and innovators take time to decide who their ‘product person’ will be. The product person takes their time to create the roadmap and then hires designers. The designers claim that their process is creative, and they take their time making decisions about the designs. The product owners create the epics and then take time to decide on the features. The technical team starts to decide on the tech stack, the cloud, and the architecture. There’s a lot of philosophical and ideological discussion. When a decision is finally made by the technical team, the CPO, designers, and the others in the team have an opinion that causes the tech team to second guess their decisions. In many cases, they reverse their decision. As in every software project, the stakeholders start getting antsy and ask for timelines. Where there is time, there is pressure. Everyone who is stuck in analysis paralysis starts punting the decisions or makes poor choices. These choices are evident when developers have stopped thinking and start executing the decisions handed to them.
Because there is no time left for engineers to do their jobs, the bug rates and functionality end up being compromised. Eventually, this creates a sub-par experience for the users. Further delaying the making of the whole project.
.webp)
.png)