Tech stories: the wrong type of help that made me rage quit a meeting

When I shut close my laptop and apologized for leaving, it was a big achievement: I hadn't shouted at anybody 🫣. I was just shaking from frustration and anger.

Hi there, folks. This story is about the right and wrong ways of offering help, respect, experience, processing information, and how attempting to save time can sometimes lead to delays.

This story is also in my top 5 worst engineering experiences. I rarely get this angry.

Great plans for a burning issue

At work customer support issues were piling up. We reached a level that were not sustainable: hiring and training support agents were lagging behind. Responding to emails took 2-3 days on average, users were quite frustrated.

My talented teammates were getting to the bottom of it absolutely professionally: data analysts crunched customer issues, grouping them with their volume; PMs narrowed them down to ones that were feasible to implement, interviews with the frustrated users were done by UX researchers, copywriters nailed the right tone and UX designers tested out the right self-help "tiles", each with its own clear explanation and actions. I think this was one of the most professionally researched plans I have ever worked on.

However, there was no patience for its implementation.

"Hey, you need some help?"

While our team had design, research, and many helpers, we were only three full-time frontend engineers who could only partially work on the project. We had ongoing projects plus customer and infrastructural issues to handle (for example, the data analyst of my team had left, so as a frontend engineer, I was fixing the data pipeline—not optimal).

The customer support bottleneck eventually caught the attention of top management. Out of the blue we were offered the help of another team: 6 young engineers.

Brooke's Law states that adding engineers to a late project will only delay the finish of the late project.

Knowing this, I replied that we might not need all six of them. Personally, I needed a data analyst to hand over the fixing of a never-ending data pipeline task in Python, which I was learning as I was fixing a broken database migration. I also thought maybe two more people would be very useful to pair up with, cutting down the coding-pull request-review-fix chains.

But we got an entire team, and stopped working on the exciting new project to prepare a well documented intro for them. I expected we’d explain the finer details when we start. Well, that didn't happen.

"So, it's a very simple task! I think we're done by tomorrow afternoon."

Then came one of the worst meetings of my life: a young (22ish) and inexperienced team lead dominated the entire meeting. He said he’d just glanced at the design slides right before the meeting, and each self-help tile looked very similar to each other: some text and one or two buttons, easy-peasye. He comically underestimated the task at hand and literally said:

Oh, I think this is a very easy task. We're going to be ready by tomorrow afternoon!

This was not a joke. The dysfunction in my team was laid bare in that second. My team lead, who was conflict-avoidant, didn’t say anything. I was looking around in disbelief, trying to see who's gonna react to such an absolutely crazy statement. None did.

Of course, there's no way a new team can push out something that quickly. By that time I saw 600 million times already how requirements change the moment there is working UI code. You cannot rely on assumptions that "there's gonna be only some text and maybe two buttons", you would need your code to be flexible. (For a bit more info see also Kent C. Dodds’ compound component approach).

I asked if he has read the documentation we had written. "Nope," he said without showing any regret whatsoever.

I was enraged seeing that all the effort we put together was going to waste. From going through with our plan, we were running after people who kinda understood some part of it. Moreover, the impossible deadline of "tomorrow afternoon" filled me with dread.

In that moment, I reached my boiling point, shut my laptop, and stormed out of the meeting.

Inside a raging head

The experience soured my mood for months and still angers me today. I felt betrayed by my team lead for not stepping up for our careful plans, for not calling out reckless promising, for choosing his personal safety over team spirit and lastly, for wasting our work.

Luckily, apart from the other team lead, nobody took seriously that crazy estimation, and nobody held us accountable for failing it.

However, I didn’t handle the coming days well, and I’m not proud of it. I was deeply offended, and I would cynically giggle at any setbacks, because I wanted to feel vindicated.

"You can't promise the next day! It's impossible! I told you so!"

I was right, it wasn’t ready the next day or the day after. We even had to roll back a couple of releases as the code hastily thrown together. It was done exactly two weeks later than tomorrow afternoon - and a work that needed refactoring.

Without them, it would have taken us 1 month I think. With them it was 2 weeks of hell, failed releases + refactoring later. Not to mention the human fallout, that costed us working relationships: while I lost faith in my team lead, my negative attitude during those days did affect my literally closest colleague (sitting next to me).

Without me knowing it, that relationship soured to the point that months later, when it was his time to step up for me, he instead jumped on the opportunity to get rid of me. It was a really dark day for me, I couldn't speak to him since.

Now I always measure what and how I say things.

Why new people are more than just more cores in a processor

We kinda demonstrated Brooke's Law: though we finished earlier having this "help", the combined time spent on this, including lost team members was huge.

So why is this law so true?

Unlike moving houses, where more hands bring more boxes, the big picture for a software engineering project has many intricate details that must be understood first. Some of it even must be processed during sleep (have you ever woke up or came out of the shower just having come up with the right approach?)! Not to mention grasping the coding style of the team, or the gotchas of the codebase. And then the human factor: team dynamics that came to be through spoken and unspoken agreements.

When new people arrive they have to feel these out.

Help done right

Combining everything, these are my suggestions:

1. Trust the devs who are intimately familiar with the problem!
2. Let them specify what help they would benefit from!
3. Don’t add too many people at once!
4. Use the new people to handle distractions, not to create them.
5. For live coding sessions pair a new and old member: a second pair of expert eyes, even without domain knowledge can help shortening the feedback cycle, so code review turnarounds would be a lot faster.
6. For the love of everything that is holy! READ THE DOCUMENTATION before promising anything! Check out the current codebase, speak with people who worked on it.

Exploring and getting familiar with alternatives before committing to a solution is an essential part of the job. Work is not eight hours of pure coding, you should not skip the discussions, otherwise you are going to ship the wrong thing, or at least in the wrong format.

But let’s get back to what happened afterward!

Somewhat of a success story...?

hanks to solid planning and company-wide efforts, the customer support bottleneck disappeared. Response times dropped from 2–3 days to just a few hours.

There was a secondary benefit to that: people did not write a second or a third email begging for a response. So not only the cases got resolved faster, also the volume of the work went down.

It could have been done just so much easier...