The rise and fall of a high-performance development team
Once upon a time, there was a high performing development team, they enjoyed their jobs and used to make their users happy, empowering the business to innovate at fast speed, even winning 3rd party awards in their business domain. But then, a massive waterfall program of work stole their souls.
The background — The beginning
This team was part of a platform, which had three teams. We will call this team “Pele” for easy understanding. Pele was the ugly duck of that platform, with management always underselling them and praising the other two teams. Pele had its problems, they were stuck with an old product where the technical debt and lack of good practices were holding them down.
After some time Pele got a new greenfield project, and with a good technical leadership, Pele started applying many great practices as ATDD, Software Craftsmanship and DevOps. So Pele started getting good reputation inside the company, which resulted in them inheriting another project related to their previous one.
This was a burden at the beginning, the handed over project was in bad shape, poor test coverage, many bugs in production and lack of documentation. With time we brought the good practices into that project and improved it. The new project was a service that was in the same domain as our previously owned before, so this gave us almost end to end customer responsibilities, which is perfect to innovate quickly.
With all that power in mind, we collaborated close with our business users. We were delivering incredibly fast, which allowed us to easily allocate time for technical debt in the sprints.
Pele now was the example of a high performing team to the platform.
Personally, I was also improving my leadership skills, discovering things like:
Which improved me and more importantly helped others. All was working well. But then, a program of work arrived.
A big project with the incredible potential to the company arrived, an increase in revenue and higher customer satisfaction. The team believed in the potential business value.
This program of work was planned, even before it the team knew about it for almost a year. The problem started when the team didn’t agree with the proposed design, but at that point, it is too late to change, because it has already been planned.
The design was over complex, it required complex mathematical terms such as isochron and a very generic solution. The design was deterministic, which means you can prove with mathematical formulas that it will work. Problem is mathematics do not look into a few constraints: Processing time, development complexity and time to market.
The discussions on this were like a novel, they were long, intense and with plots on who you could trust to be defending the interests of the team.
After two months, tired of discussing I got the team to work in an agile solution, the result was an MVP proving the value at production under a week. The architecture team called this too short term, and they wanted something strategic. Even if they agreed the solution would cover 99% of the scenarios.
The short-term solution is what enabled the project to stay on track with deadlines asked by the business.
During that time I reflected a lot with myself, shall we just play politics and let my team do this work as the architects are asking? This conflict would easily cause problems in my own career path. What would be the downsides of implementing it?
- Team demotivation, nobody likes to work on something they don’t believe in, especially for a long period.
- 6 Months minimum work until being able to see any results.
- Business slowing down and not being able to innovate.
It took 6 months, with the team arguing with the architecture team and senior management that this wasn’t the right way forward, in the end, I moved teams because it was a lost cause, architecture had the ears of senior management.
After I left
The architecture team easily got the way they wanted, the team started working on very abstract stories, things that wouldn’t deliver any value until plugged into the major long-term solution, which would easily take months on a high performing team, the problem is this team wasn’t going to be high performing for long.
They started missing their own sprint commitments, for a team that averaged 30–40 story points that always over delivered, they started committing to 20, and even then missing it, sometimes delivering a total of 5. More pressure from management came by. The engineers got so demotivated with the situation that one by one they started leaving.
Many people left in between. But the team of 5 originally during our good time with 2 services, all left. Remaining only new joiners with this new big problem in their hand, all the knowledge on the complex design was now gone.
The company lost so much on this. The fact that business users requests were completely denied so the team could focus on the project. All the hours in useless discussions. The stress burden into individuals. The time planning something too further ahead. The lost time to market. And most importantly, it lost incredible talent that had big potential.
It had been a great journey, it made me learn a lot around leadership and even mature into corporate politics.
What I think is the big lesson here is, trust the people that will actually get the job done, in that case the software developers, they aren’t just code spitting machines, they are eager problem solvers that will try their best for the business. Not trusting and forcing them do a work they don’t believe does not result well.
I maybe could have played this better, maybe being more receptive towards architecture, or being better at selling, who knows…