on Project Fails and Ails

October 27, 2023

Introduction

Some months ago, I begun my first ever technical leadership. I've done some mentoring and lead small teams over the last years. But this time I took over a ten people team.

First, the lack of focus of the team looked iffy to me. About 6 months later, I am officially the Unofficial Psychologist for the team and have started regular group sessions with some members to let steam out. While the team is fully remote, I do go to the company's headquarters, where senior managers and directors call me "Hope Telephone." Big red flag.

What comes next is my analysis of the situation in an attempt to untagle that mess and obtain a better understanding.

First signs

When I joined the team, close to 40% of the team was leaving, and we were going in as a fresh batch. The first thing I noticed was how unfocused the team was. Dailies lasted close to an hour and a half. And all kind of things were going on. Say someone got an email from a client. They would stop the meeting to read the email, sort whatever needed sorting, and resume the daily.

At first I thought that the guy I was replacing, Ivan, was too unorderly, unfocused, and the main source of that behavior. While technically competent, I still believe the position was to large for Ivan. It is too large for me, and he had close to half my experience and not enough tecnical competence. Furthermore, he was involved, to a very large degree, in every single task. As someone who was also leaving the team said: "He does everything." Now I know that was no exaggeration.

Six months later, the issues run deeper than I thought.

Management issues

The thing I feel the most hurt by is continuous changes in scope. We had an incident during the summer. There was some faulty data coming into our system, which was processed through some 500 lines of SQL code, and that lead to an exponential increase of data in our database. We broke the production system.

That was the big issue of the day. I figured out what was going on, stopped all processes related to that data, proposed to untangle the SQL mess into some Python, with tests, comments, some degree of organization… Then a different issue occurred and I was pulled out of fixing the previous mess. With all processes down and no data flowing into the system.

Months later someone on the client side figured out data had not been updated for quite a while. And that was a major problem, which I was thrown into solving. Untill some other task was running late and I had to figure that one out. Previous task unfinished.

It's like being continuously pushed and pulling. My friend in really into dogs, and she says that a happy dog walks with loose leash: "Imagine running all day with something choking your neck. It's a lot of effort, and the more effort you put in, the worse it gets." Which, by the way, is my dad's description of his time in the army: Hurrying a lot to accomplish nothing.

And that "accomplish nothing" is quite the key. Because there is no closure to any of the effort you put into the job. No real successes nor failures. Just a pile of unfinished tasks.

No wonder Ivan was unfocused. He was literally paying attention to all tasks. If someone was unable to finish the task on time. He would take over. And some people noticed and took advantage of him. That alone should break something inside you.

There are issues with this project. The amout of issues is making the team look bad. But in order to ameliorate the looks in front of the client, what management is doing is: keep promising more. Which means more tasks started, which means more tasks go unfished. No matter how hard anyone works, there is something they are not doing, there is always something that grants you a slap on the wrist.

Because there is something not getting done, the management team feels like they cannot say "no" when asked to start a particular task. With that, the team keeps chewing more than they can swallow. More force fed, than chewing.

Technical issues

But I happen to think that the root cause of the issue is the technology. Someone recently named the issue "demo effect."

There is this tech. It's really easy get set up, get some understanding, and achieve some fast results. Then someone thinks: it took me this short time to get here, in six months, the sky is the limit. Six months later, a whole team is struggling with the limitations of the technology.

But lets take it a step further. If you are assembling a team to operate this super easy to use tecnology, you don't need technical experts, you can get by with a bunch of recent graduates, with no technical experience. Let alone any programming knowledge.

The main issue is: you end up with a system built by a bunch of recent graduates, with no technical experience. Let alone any programming knowledge. If you are wondering whether this is a recipe for disaster, the answer is: it depends. But it was definitely a disaster in our case. Just in case you had not noticed.

What never stops to baffle me is people blindly following orders. We had a meeting with a vendor about the Spark clusters underlying our systems. The vendor said that best practice involved setting autoscaling. We had the smallest cluster available, with 3 worker nodes. Someone spent an evening setting auto scaling from 2 to 3 workers. Only then were we following the best practices recommended by the vendor!

And in this year of someone else's lord 2023, I was reviewing some SQL code. When I asked the author the reason for some strange coalesce, the answer was: "I don't know, ChatGPT told me so."

Technical issues are management issues are peoples' issues

But technical issues are management issues. The decision to implement the project with a shiny toy technology, which failed once things got slightly complex, was motivated due to allowing cheeper hires.

Most of the time I feel like I am fighting the technology rather than trying to create value for the customers. This means time lost.

But I'll say that alineation and loss of agency are the main issues. There is nothing I can do to fix 10 other people with no critical thinking, blidly following tasks. If management asks to extract data from somewhere and write it in the exact same place, with no transformation, but doing something very convoluted in the process, we have some doing it. And giving about 0 thought about why. Often, I feel that's the best I can do too, I cannot see how it matters if the end result is poor, and critical thinking may antagonize me with management.

With alineation and loss of agency, comes burnout.

Postscript

Yet another batch of people are beginning to leave the proyect. Almost everyone that entered the proyect with me, myself included, are looking for jobs. And a fesh new batch of people are coming in.