Fail teams by design.

At some moment, I worked with a team in one of my previous companies. First of all, it was hard to get anything out of them (they were barely communicative). Second, as soon as I dived into what they were working on (one module of a big project), I realized how problematic that team was.

I recently posted this article describing how somebody inherited the worst project ever. Of course, it wasn’t like that, but there were tons of flashing red lights — no documentation, no tests, long and winded code, escalations coming left and right from the production.

After some period of my struggles, I mentally labeled people from that team as “bad software engineers”. Hey… How could they produce such problematic code, etc.?

However, as time passed, I realized that problem was not their fault. The problem is the organization.

Apparently, a lot of other teams were dependent on that small team. So it was not just understaffed. It was so understaffed that doing even the most critical items in a good way would be impossible.

My gut feeling tells me that their team should have been five times bigger to do what they needed. Also, they needed solid technical and managerial leadership (which was lacking). I think a better approach would be spreading the responsibilities across the organization to remove this heavyweight dependency. (To be fair, it was partially done). However, even with a better approach, the team should have been bigger to do support and gradually chip away from all the crap/shortcuts introduced before).

BTW. I think I omitted one step. Initially, I felt that engineers are responsible. Next, for a brief period, I was pissed at their manager. However, this feeling passed fast after multiple changes in the chain of command (without significant improvements).

And quite fast, I got to a realization that the organization failed them big time.

Switching gears a little bit. Uncle Bob talks a lot about professionalism. And how professional engineers should behave. And I would say he (or a proponent of his approach) would probably say something like: you should prepare a well-thought estimate for all projects, show that meeting all goals is unrealistic, and work with all stakeholders to choose the most critical projects which fit the budget. And while doing this, saying a firm No to the management.

The intention (of such an approach) is good. The execution is not possible. And when I see such divergence (between an intention and reality), I imagine myself to be a 300-pound wrestler ready to jump and crash the opponent :) I just can’t miss the opportunity to point out the gap.

• First of all, the engineers in that team were not senior enough, and neither was their manager. It’s easy to talk about careful plans when it’s your second nature and you have done it multiple times. It’s very hard to be not very experienced and be asked to navigate complex technical and political environments.
• The organization did not trust the team (because of all these problems) to either produce reliable estimates or reliable quality). Again, it’s easy when you are new, and you are pretty higher up to have a good serious conversation. When you are in the trenches, and your track record has a lot of blemishes, everything you say will be severely tainted.
• My guess is they were underrepresented in a lot of discussions (so they didn’t even know what hit them)
• What happened to this team is not an exception, but it was rather a pattern for the organization. So, it wasn’t a matter of just fixing it locally.

So, getting back to Uncle Bob’s approach. Pretty much, you are asking reasonably junior engineers, who barely have time to breathe, to somehow overnight become way more technical, way more politically savvy, overcome existing bias, and fix the whole organization’s approach on how software engineering works. Yeay… Great plan.

I think it will be an excellent plot for a movie about an underdog software engineer saving the company and becoming a new CEO. However, in real life, you have more chances of being hit by a meteor.

I found this is very unfortunate when the organization creates a structure where people and teams guarantee to fail.

And unfortunately, it’s hard to recognize these things when you are close to them (there are way too many details that prevent you from seeing the big picture).

I think I was writing about responsibility in one of my articles. First, all small failures should be ignored (it happens to the best of us). If an engineer fails (in a big and predictable way) once or twice — it’s an engineer’s fault. The third time is the fault of the manager. The same goes for the team. If a team fails repeatedly, it’s the fault of middle management. And the responsibility propagates up quite quickly (if failures continue).

An interesting side note about it. I don’t think the change in the management chain “resets” responsibility back to the engineer or team level. It would be too easy for C-level, VP of middle management to shuffle underlying management, completely avoiding any responsibility that way.

I think it works more like a smoke alarm. Pressing the reset button will stop it momentarily, but until smoke is coming (from the team), it will start beeping again and again. So, until the team operates normally, the responsibility stays with everybody through the chain of command.

P.S. DALL-E created all the pictures here. People in the picture end up being a bit creepy, and the pictures are still not super realistic, but still, the results are beyond amazing (and a bit scary how good they are).