The SAFe misery and what to learn from it

When Larry the CPO doesn't know how to solve problems, he uses the enterprise process stick.

---

This article is brought to you by Paragon -

29% of B2B SaaS companies use an embedded iPaaS to scale their products’ integration strategies - are you? If not, read this Build vs. Buy Guide before you build your next integration.

---

Larry has a problem. He’s a super important CPO at this 200-person scale-up, and his teams don’t do what he wants them to.

His product teams are completely overwhelmed, the codebase is an absolute clusterf*** of old code that should have been refactored yesterday, and the CEO is breathing down his neck. “Larry, what is WRONG? Why is everything so slow and bad?”

Larry, the Super CPO, implementing SAFe in his 200-person startup to speed up development. 2021, Picture taken in a broom closet

“It can’t be that hard.”
- CEO Strategy

Why does this happen? What can we learn from it as product leaders?

Let’s map it out

As we scale, we fail

This is the reality of almost all scale and start-ups. It’s a mess everywhere, and the challenge is difficult to keep stuff under control the moment more people work on the same product.

A good CPO can keep the mess under control better than a bad CPO on the same scale.

A good CPO can run a product and growth organization with processes intended for smaller companies, whereas a bad one often resorts to bigger company frameworks too soon.

I’m not against QA engineers, data teams for complex business inquiries, product ops, and scaled Agile frameworks. I’m just against them too early.

Let’s look at dedicated data teams and product ops, for example:

• If you have a 50-person organization, which usually translates to 3-5 product teams, and you’re telling me how proud you are of your data team/ops that handles all business inquiries, I’m starting to raise my eyebrows.

What this, in reality, means is that your product managers don’t know how to query data at all, and your “solution” was to hire a team to take care of that. The problem with that? You’re introducing friction into the daily work of a product team that is not necessary.

The quality of distributed inquiries is dramatically dropping. As a small startup, we have the distinct advantage of moving fast and being flexible. To do things differently. The moment you introduce unnecessary processes and teams, you’re deteriorating this advantage:

1. PMs who don’t know how to query and process data (or don’t have the right to) don’t know what it can hold or measure. They lack context and inquire about it less often because it’s more cumbersome to open a ticket instead of querying themselves quickly.

2. Data Teams that don’t work in the respective product teams lack important business context for what the data is purposed for and have a tendency to not own the outcomes the data is intended for. They just work down tickets and provide “something” more likely.

---

More on that topic:

Leah's Product & Growth team Guide

---

My favorite example in this regard is SAFe. I’ve seen hands-on how the conversation started and what the outcome was when it was finally implemented in mid to large companies.

It was always a terrible waste of money and loss of autonomy and joy, but I didn’t understand why exactly.

I do recognize the problem that scaled agile processes are trying to address. However, they are just plain wrong at the scale they are implemented and make everyone miserable.

That’s not an exaggeration. People are absolutely miserable in SAFe and other convoluted processes, especially product managers and their product owner slaves. Miserable people tend not to perform that well.

SAFe et al.

Let's have a look at the screenshot they host on their own website.

Ah yes, my executive chromosomes are getting nervous from all the revenue I see in this chart. This looks… very competent and convoluted, it must be smart.

In this graph, SAFe is trying to portray itself as a scaled way to ship fast and efficiently, get stuff out the door fast, and align your teams with a lot of overhead. But it often doesn’t work.

SAFe is a perfect metaphor for every process you ever encountered that was convoluted and overly complicated. But what can we learn from it other than just complain about it?

I would summarize the experience I have from implementing company-wide processes to get product teams aligned in a couple of principles:

1. Any process that is complicated (<- complicated, not complex) and involves more than one team's alignment is not manageable efficiently at scale → People are incredibly fast misaligned. Taking away their autonomy to make sure they cannot misunderstand is never working. It also robs them of their ability to care quickly.

2. Dependencies should not be managed, you have to eliminate them → cross-functional teams, insourcing competencies, budget autonomy to some degree. This works best if pains are visible.

3. Introducing roles and process names that don't reflect what people do or are not simple is detrimental. → Product Owners do not own anything. They "own" their backlogs and are stuck in their career to execute top-down requirements. Epic owners, Team coaches, RTEs… who could have predicted that this wouldn’t work out?

4. If an idea can't be explained simply, it will be misunderstood. → Did you "ever" see an impactful strategy that was convoluted and hard to explain for any product? I saw many of them, but they never achieved what they should. Learning how to summarize efficiently and simply is a skill we don’t teach enough.

5. Convoluted processes create spots to hide for low performers. → Low morale and an annoying way to work day to day will sooner or later create spaces where people just do busy work to hide away.

6. Teams are comprised of people and individuals who become more efficient if we allow them to stay together for some time instead of treating them like pawns that get shifted around. → Local knowledge of a product/code base is a real thing.

What can we learn as product operators from that, regardless of whether we are managing a small team or an entire organization?

A process to get rid of processes