The team was considered to be slow, no AI adoption, unfit to create the new platform. Always “being difficult”.
They had five failed attempts at building a new platform. One thing to mention: one of the founders and also a developer, not part of this team, let’s call him Kirk, was in charge. He didn’t want to use Git, he stored code in the database and he used a method about which the creator of PHP, Rasmus Lerdorf, said: “If eval() is the answer, you’re almost certainly asking the wrong question.”
What I saw was a team of frustrated yet loyal developers. I started talking to them, wondered why they weren’t using AI more to find out they weren’t given accounts (money, access, how do you best explain that). And there was so much more.
Kirk not liking a solution, swearing at a developer, rolling back the changes. Outside developers being hired to work on new projects, without the team being asked or told, leaving them working on the terribly designed outdated platform.
A move to AWS, completely done by Kirk and an outside developer, without informing or consulting the team. AWS costs increased and the team was left to solve that.
When I arrived, the platform was overloaded and unreachable on busy evenings. Bad enough, but the big shocker was that this wasn’t the main thing everyone was working on. Only Kirk was involved in fixing this, not asking or allowing any help.
First thing: move all code to Git. Second: disallow Kirk access. Better a hole in your team than an asshole in your team.
I told the team that making mistakes was allowed, that I’d rather see them make mistakes than do nothing.
Slowly but surely I earned their trust, they started to take responsibility, we improved performance, and they started to take initiative. We changed the way of working. Instead of fixing bugs, they were asked to solve problems. This may seem to be the same thing, but the difference is subtle yet huge.
Previously, problems would come in via the helpdesk. Customers would ask a question, file a complaint, report a bug. Then sometimes and/or after some time, a bug would be handed over to a different department, which would investigate the problem or bug and would turn it into an issue. That issue was then passed on to the developers: please fix this.
What we changed this into: we are actively looking into log files, database errors as well as directly reading helpdesk tickets. When we (yes, an AI powered, automated process) detect problems or bugs, we examine the code, try to reproduce the error, then start researching ways of fixing the bug. Then a new round of testing, comparing before and after behavior of the application, making sure the problem doesn’t occur anymore, also checking if it doesn’t cause new problems. Then and only then comes the first and only human interference: a developer checks the code and pushes the solution.
As for numbers: we are fixing bugs and errors before customers or helpdesk knows there is a problem.
The question to the CEO would be if they (the team) understand what they are doing, whether they understand the problem they are solving, if they understand how they should be helping their customers.
It might feel easier to chop up problems in smaller parts, but if it’s unclear where the smaller parts are coming from, how they are part of the bigger picture, it might stop your developers from contributing real breakthrough improvements.
Do you know how your team can perform better? Let’s talk.