The Planes Aren't Coming

Trading predictable delivery for predictable learning

I was on a coffee break with a colleague. Let’s call him Mike. We were talking about cargo cults—the ones from WWII Oceania, where islanders built wooden airplanes, hoping they’d bring supplies when the real planes stopped coming.

I told him, “It reminds me of us. We’ve got all the Scrum ceremonies and expect agility to materialize. But the planes aren’t coming.”

We had daily standups, retros, planning, and refinement. Scrum Masters. Product Owners. External consultants. A resident Agile coach. We had the whole package. We’d built the wooden plane. The agile goods never materialized. Siloed teams. Zero client feedback. A three-year roadmap. Also, a full package.

Mike just stared at me. “Then everything’s a cargo cult,” he said, deadpan. He didn’t buy it. I tried to push the point, but we went in circles.

Generated with ChatGPT

I left the company soon after. It wasn’t a bad place. But I’d hit a wall. Sprint after sprint, shipping features into a vacuum. Total disconnect from the business. Meanwhile, Mike was convinced that it is how it is supposed to be. And it is what Agile is all about.

Frameworks don’t create agility. They only amplify what’s already there. If your culture, feedback loops, and decision-making are disconnected from reality, sprinting faster just gets you to the wrong destination quicker. Real process engineering starts from first principles: begin with how your team actually operates, what drives client value, and where friction lives. Culture comes first. Rituals follow.

Before we dive in: I’m Roman, CTO at a startup, and I write High-Impact Engineering — a weekly newsletter for engineering managers, directors, and CTOs.

This issue is about product development culture.

The Foundation

Most teams skip the foundation and jump straight to the rituals. They adopt a framework, copy its ceremonies, and expect agility to materialize. But borrowing a process is like buying an Olympic champion’s golden medal (or a Nobel Peace Prize laureate’s medal). Possessing the thing does not make you a champion.

The real transformation starts from a few unglamorous questions:

• How do we stay close to the people who use what we build?

• Where does work actually stall, and how do we unblock it?

• How do we create psychological safety so the team can challenge assumptions and adapt?

They’re the operating system. Everything else—planning cadence, review formats, communication rhythms—must be derived from them. If a ritual doesn’t serve one of these foundations, it’s a waste. For example, if client proximity is your north star, your planning meetings should revolve around live user signals, not 3-year-old backlog grooming. If bottleneck removal is critical, your standups should focus on flow constraints, not task status.

When the Gears Mesh

Once those foundations are locked, you can finally design the operating rhythm. Think of your team’s system as two interlocking gears. The outer loop is product and client feedback: who uses this, why, what frustrates them, and what they would pay for. And the work to make the product better and serve clients.

The inner loop is team effectiveness: how do we plan, communicate, review, and adapt? These aren’t parallel tracks. They mesh.

When they mesh, the team’s identity shifts from feature factory to outcome-driven problem solver. The outer loop becomes the compass—engineers stop asking “What’s next on the roadmap?” and start asking “What’s blocking our users today?” The team’s focus shifts from delivering tickets to delivering user value. These are two different things. Think about the fact that 80% of features in an average product are never used. They probably came from that three-year-old backlog.

Meanwhile, the inner loop acts as a force multiplier. Tight feedback cycles, clear handoffs, and rapid iteration don’t just ship faster; they compound the value of every user insight. The outer loop sets the trajectory. The inner loop determines how much of that trajectory actually reaches the customer. Unmeshed, you get motion. Meshed, you get momentum.

The Real Shift

When those gears mesh, you unlock the most critical shift for engineering leaders: trading predictable delivery for predictable learning. Business loves predictability.

But predictability in any large project is either luck or heavy padding. The delivery is optimized for predictability, not for business outcomes. We commit to a fixed scope, track it religiously, and deliver exactly what we planned—right into a market that’s already moved on. This is the core tension for engineering leaders: stakeholders want certainty, but fixed roadmaps blind you to reality.

The shift isn’t to abandon predictability. It’s to measure it differently. Predictable learning replaces predictable delivery. We scope tight learning cycles, validate quickly, and either double down or cut losses. Every step moves us forward.

We trade fixed scope for fixed feedback intervals. Measure predictability in how fast you learn, pivot, or kill dead weight, not in how neatly you track tickets. Track hypothesis turnover rate, time-to-first-user-feedback, or feature adoption curves instead of sprint velocity.

I’ve worked on many projects where we knew better than the clients what they wanted. More often than not, it ended up badly. Businesses failed, and teams were let go. People left, or mentally checked out.

On the other hand, when we start work with clients, listen to what they want, and iterate quickly, the team lights up. The energy shifts from compliance to ownership, and the business follows.

I’ve been in tech for 20 years, and half of it I spent working on something that no one wants or needs. Such a waste. Life is short.

Audit Your Loops

But this shift requires visibility. Here’s how to audit your gears:

• Inner loop: Do your retros repeat the same complaints month after month? Are you optimizing flow or just managing visibility? If the same blockers resurface without structural changes, your process is stuck in maintenance mode.

• Outer loop: Can you name three active users of your last feature? What do they love? What breaks their workflow? If you can’t answer, your process is running blind.

• Both: Do people feel safe proposing their ideas? Do they dare to argue with their manager?

When both loops are misaligned, velocity becomes theater. When they mesh, impact compounds. The team’s operating rhythm should emerge from that mesh, not from a borrowed playbook. Concretics will vary by team size, product stage, and domain. That’s the point. Process isn’t a template. It’s a living system.

I wrote an article about how to implement changes by running experiments. You can read it here. If you want to start improving your team’s process now? Subscribe, and you’ll immediately receive my free Process Experiment Template — complete with hypothesis format, success metrics, weekly tracking, and a rollback plan. Ready to use with your team this week.

Build Your Own Rhythm

I have to be honest here. Turning theory into practice is hard. Especially if you’re working in a big company.

Many years ago, I worked at a huge international company—one of South Korea’s chaebols. There were plenty of stupid things and office politics, but we managed to build direct relations with our internal clients in Asia and focused on making them successful.

We didn’t have planning or dailies. But we created real impact in the organization. Looking back, there are many things I could have done differently now—especially on the inner loop. But the core was there. What we’re doing and the value of our work matter more than the operational process. It was true almost 20 years ago, and it’s still true.

Talk to the client. Talk to the team. Grow psychological safety and build experimentation structures. One small improvement. One small step at a time.

Make both loops mesh, and you’ll be amazed at how much you can achieve as a team—and in your career.

Align Your Gears, Stop Running Theater

Before I let you go. If this resonated, but you are hesitant about where to start, you can contact me. I work with CTOs and engineering managers to help them create high-impact engineering teams and organizations.