Simplification Through Incrementalization

Leading a Change With Slowification, Simplification and Amplification, part 2

As engineering managers or directors, our job is to improve things continually. Pushing the limits and moving boundaries isn't just a motivational cliché—it's our reality.

Leading change isn't a one-time event but an ongoing initiative for us. We must consistently enhance our work and compound its outcomes (I discussed this in detail in How to Be a Better Software Engineering Leader).

To help readers of PEM navigate this never-ending transformation, I’ve started a series covering three critical aspects of the process:

• Slowification: Making the problem-solving process easier.

• Simplification: Making the problems themselves easier.

• Amplification: Highlighting issues loudly and clearly.

These concepts are introduced in the book, "Wiring Winning Organizations," which I recommend for a comprehensive understanding. Here, I’ll share a condensed version with examples from my experiences.

This article focuses on the process of Simplification through Incrementalization and the underlying principles.

Here, you can find a PDF cheat sheet summarizing this article.

Links to the other articles in the series

• Slowification

• Simplification through Incrementalization (this article)

• Simplification through Modularization

• Simplification through Linearization

• Amplification (coming soon)

---

The Power of Hidden Teams

Before diving into the concept of Simplification, let’s revisit the three layers of focus in engineering transformation:

• Layer 1: Technical Objects: The actual artifacts being worked on, such as code, libraries, algorithms, APIs, interfaces, data structures, UI components, etc.

• Layer 2: Tools and Instrumentation: The tools and systems used to manage, develop, and monitor the technical objects from Layer 1 (IDEs, CI/CD, observability & monitoring platforms, etc.)

• Layer 3: Social Circuitry: The processes, standards, and communication patterns that guide how people work together (organizational culture, team dynamics, leadership practices, etc.).

Changes to Layer 3, rather than Layer 1 or 2, can be the primary drivers of engineers' productivity.

One great example supporting this statement is HBR's article "The Power of Hidden Teams," which a few years ago influenced my way of thinking about the importance of social circuitry.

The article proves that organizations should focus on real teams (cross-functional groups that can deliver their work end-to-end) rather than org charts (siloed groups of individuals assigned to random tasks). Successful team leadership involves creating environments that utilize each member’s unique strengths.

But why is it so important? A study by the ADP Research Institute cited by the article found that workers who do most of their work in teams are more than twice as likely to be fully engaged as those who work mostly alone.

For more data and case studies, I recommend reading the entire HBR piece linked above.

Simplification

No single person fully understands how an iPhone is built in every detail. This phenomenon isn't unique to the iPhone; it applies to many complex, modern technologies like cars, airplanes, or even the internet.

The only way to make it possible to build such complex systems is to decompose them into modules that are designed to work together but can be developed and understood in isolation. This is where the process of Simplification comes into play.

According to "Winning Wiring Organization," Simplification can be broken down into three key strategies: Incrementalization, Modularization, and Linearization. These strategies offer practical approaches to reducing complexity, enabling software engineering teams to work more effectively and efficiently.

Good simplification also allows complex problems to be broken into smaller chunks that can be developed simultaneously.

In this article, we’ll explore the concept of Incrementalization. Initially, I intended to cover all the strategies at once, but with so many nuances surrounding each, I decided to split them into three separate discussions.

Incrementalization through MVP, PoC, and Prototype

Incrementalization involves separating what is novel (untested and new) from what is known (validated and stable) and developing these novel aspects in small, controlled increments. This approach allows teams to focus on testing and refining new features in a more manageable, risk-averse manner.

The best examples of Incrementalization are PoCs, Prototypes, or MVPs.

These concepts have different goals. PoCs validate feasibility (can we, and how easily can we build something?); prototypes check usability (will users know how to use it?); and MVPs validate the product idea in the market.

But they all—PoC, Prototype, and MVP—serve one purpose in the meaning of Incrementalization. They separate what is known (validated hypotheses and risks) from what is novel—everything we need to build on top of them.

To read more, check out my article: MVP, PoC, or Prototype.

---

Incrementalization as a Strategic Approach

What is a strategy? Strategy is a designed response to the challenges ahead of us. Good strategy, as described in Richard Rumelt’s "Good Strategy / Bad Strategy," has three critical components:

• The Diagnosis: Understanding the current situation and identifying the organization’s key challenges.

• The Guiding Policy: Outlining the overall approach the organization or team will take to address these challenges.

• The Coherent Action: A series of coordinated actions designed to implement the guiding policy.

Incrementalization is nothing more than a response to the strategic problem ahead of us (diagnosis). Does that sound vague? Let's explore one example many leaders (including me) face in their work.

Imagine a company that wants to transform into a Product Operating Model where new changes and features are delivered continuously and in small batches. For many organizations, this problem is too big to tackle all at once, so it must be split into smaller initiatives.

Let’s say two major problems are a monolithic system and a non-existent SDLC process. How could Incrementalization work here?

For example:

1. Start using the Strangler Pattern to separate a single functionality into something outside your monolithic system (e.g., microservice, microfrontend).

2. Define and implement good testing practices so you can confidently push changes to production without handoffs between engineers and testers. Make sure all the testing can be done in less than on hour.

3. Implement product instrumentation and monitoring to understand how your solution behaves in production (observability, tech stack monitoring) and how customers use it (product analytics).

4. Implement rollout/rollback strategies (blue-green deployments, feature flags, service rollback) so that when your solution is live but malfunctioning, you can quickly control its visibility or revert changes as needed.

5. Document these steps and ensure each new functionality separated from your monolithic system adheres to these standards.

The plan I described is general, while the problems you face in your organization may be more nuanced. But what I’m trying to illustrate is that rather than freezing everything to rewrite your monolith in the next three months, you can take an incremental approach, where each strategic step is developed separately.

To explore more, I invite you to read the Engineering Strategy Framework, that will help you build a long-term plan in which Incrementalization can play a critical role. You should also check the Example Strategic Blocks for Engineering Strategy to see how the Proximate Objective concept, among others, can serve as an excellent example of Incrementalization.

Incrementalization is a Company Culture Thing

If I think about one of the most recurring feedback I've been getting for my entire career as engineering leader, it would be "no long term plan (for the team, product, company etc.)".

Whether I worked at an early-stage startup, a well-funded startup, a scale-up, or an organization with 10, 100, or nearly 1,000 people, I constantly heard, “Okay... but what’s our long-term plan? I don’t see one.”

If you say the company’s mission or vision is the plan, it’s too vague. If the team is extremely micro-managed, they say that they don't see any plan - they are just cogs in the machine. If, rather than tasks, you give the team problems to solve, you will hear, "Aha! So the company doesn't know what to do, so it pushes these problems on us."

I’m exaggerating a bit, but here’s the point: most of us, as humans, like stability. Unsurprisingly, we would love to have a 2-year roadmap we can all focus on. But the world is too complex—we cannot predict what will happen in the long term.

And if you think it’s the CEO’s or Product team’s role to plan for the future, consider this: Only 10-30 percent of features pushed by companies bring positive results, as stated in the book "Transformed" by Marty Cagan.

You must acknowledge this—even if your organization is different and you see a 1-year roadmap with all the epics and tasks laid out, most are just hypotheses that won’t be validated until you hit the market and receive customer feedback.

This is why Incrementalization is so essential. Modern ways of working, whether DevOps Culture or the Product Operating Model, assume that you build something valuable but small enough to validate quickly with the market.

If such an MVP makes sense, it becomes the “known part” of the Incrementalization process. On top of that, you add the “novel part”—something that adds more value, solves more customer problems, or addresses their feedback.

This means the only long-term plan that makes sense is your company’s mission/vision and its strategy (the biggest problems to solve, four factors, or hypotheses to validate).

If your team asks for more, your job is to ensure they understand that the precise plan is always “in the making,” and their role is to participate in this discovery process as well. You will continuously operate on the intersection of what’s known and certain and what’s novel and uncovered.

---

To explore more about the Product Operating Model and our role in it as engineering teams, I invite you to read the series: The Role of Engineering in Product Model Transformation.

For a different perspective, check out Ten Types of Software Engineering Waste. Here, the Incrementalization process helps reduce waste like “Extra/Wrong Features” and “Unnecessarily Complex Solutions” among others.

Conclusion

Simplification is an essential strategy for managing complexity in software engineering. By leveraging Incrementalization, Modularization, and Linearization, leaders can break down large, unwieldy systems into manageable parts, enabling their teams to work more independently and efficiently.

In this article, I covered Incrementalization, which plays a critical role, especially in today’s world where cloud environments, worldwide internet access, and countless solutions for effective SDLC enable us to iterate over our products more quickly than ever before.

In future articles, I’ll cover the other aspects of Simplification—Modularization and Linearization.

Thanks for reading, and please share your thoughts on today’s post.