Simplification Through Linearization
Simplification Through Linearization
Leading a Change With Slowification, Simplification and Amplification, part 4
For engineering leaders, leading change isn't a one-time event but an ongoing initiative. As I've discussed in my previous articles, we must continuously strive to improve and enhance the outcomes of our work.
This is the fourth article in a series of five, where I explore three critical aspects of the transformation process:
Slowification: Making the problem-solving process easier.
Simplification: Making the problems themselves easier.
Amplification: Highlighting problems loud and clear.
These concepts were introduced in the book "Wiring Winning Organizations," which I recommend as a comprehensive resource. Here, I’ll provide a concise overview, supplemented with examples from my own experiences.
In this article, I'll focus on the process of Simplification through Linearization and its underlying principles.
Here, you can find a PDF cheat sheet summarizing this article.
Links to the other articles in the series
Simplification through Linearization (this article)
Amplification (coming soon)
Developer Experience
What is an essential activity in an engineering leader's role? If you narrow it down to the simplest statement, it would likely be: increasing engineers' productivity. This means reducing time to market and enhancing the quality of the software you build.
How can this be achieved in practice?
One of the research papers I found particularly inspiring is DevEx: What Actually Drives Productivity. In his work,
identifies three dimensions of developer experience:Flow State
Feedback Loops
Cognitive Load
These dimensions encompass various types of friction we should aim to reduce as engineering leaders.
Translating these concepts into practical terms means:
Allowing people to work undisturbed for extended periods, so they can achieve a Flow State.
Establishing constant Feedback Loops to ensure people build the right things, meet expected goals (both functional and non-functional), and have the necessary context.
Ensuring that the problems people solve are clear and simple so they can focus on as few tasks as possible to maintain a healthy Cognitive Load.
In one of my past projects, there was a need to involve one of the engineers from a siloed group. His manager made a plan, “You will get him, exclusively, from a certain date for two weeks long so he can solve your problems”.
It sounds like a perfect situation, doesn't it? Two weeks of flow state with zero distractions—except it wasn’t. The engineer could join our team no earlier and no later than a specific day, and he was informed of this just a few days prior while finishing his previous task.
There was no time to delve into the problem or explore potential solutions. Instead, we got a temporary team member who didn't understand the expected outcomes and asked for crystal-clear requirements, which we couldn't provide (you involve senior engineers to solve problems, not to follow clear orders).
Lack of clarity disrupted the flow state with constant blockers. The feedback loop was nonexistent—he didn't come to iterate over a solution; he came to complete a task and return to his previous work. Cognitive load skyrocketed—he had to learn the problem while implementing a solution, report to his manager, join our standups, attend his team's standups, fix bugs, and collaborate with QA engineers on previous tasks.
The project didn’t succeed. Ultimately, the team implemented the solution again without the key software engineer's involvement.
But did it happen? The organization was already simplified through modularization (siloed engineers were assigned to different tasks across the organization) and incrementalization (company released in a stable weekly release cycle).
The missing piece was Simplification through Linearization.
Simplification Through Linearization
In previous articles, we explored Simplification through Incrementalization, which involves separating the novel (untested and new) from the known (validated and stable), and Simplification through Modularization, which consists in breaking down large, complex systems into smaller, self-contained modules.
To complete this picture, there is one more aspect of Simplification described in the book "Wiring Winning Organizations": Simplification through Linearization.
Linearization involves creating workflows that minimize complexity by partitioning operations into independent, coherent processes. This strategy focuses on connecting those who need to collaborate directly, bypassing traditional hierarchical communication channels that slow down decision-making and reduce communication speed, frequency, and detail.
Key elements of linearization include:
Cross-Functional Workflows: Designing workflows that cut across traditional functions, assigning resources from various specialties directly into these workflows.
Defining Objectives: Clearly outlining the goals for the entire group to ensure alignment.
Partitioning: Creating clear boundaries within workflows to define how people interact across specialties, enabling independence of action behind these partitions.
Slack and Stabilization: Building in extra capacity and stabilization mechanisms to manage and contain problems as they arise, preventing them from spreading across the organization.
Why Linearization Matters
In many tech organizations, processes often become bogged down due to hierarchical communication channels, leading to delays, misunderstandings, and inefficiencies.
This was evident in my case of the engineer who was "borrowed" for two weeks. I communicated with his manager, and the manager spoke with him. My team needed a partner for the discovery process; the manager expected a clear list of tasks to be completed within ten working days. Rather than solving the real problem by those closest to it, the other manager and I were stuck in a tense scheduling process.
Linearization addresses these challenges by:
Improving Collaboration: Directly connecting team members who need to collaborate reduces the loss of frequency, speed, and detail in communications, making problem-solving more effective.
Enhancing Efficiency: Decoupling workflows and reducing dependencies allow teams to work more autonomously, leading to faster task completion.
Freeing Up Time and Energy: Simplifying workflows and reducing the need to navigate complex organizational structures allows team members to focus more on their core tasks (the problem to be solved with technology) rather than figuring out how to get things done.
Ten Types of Waste
Linearization is about reducing cognitive load, task switching, handoffs, and improving workflow efficiency. This may sound familiar if you’ve been reading this newsletter for some time. The workflows are nothing more than technology value streams—the sequence of processes needed to convert an idea into a working product.
Linearization is not only about creating these sequences but also about optimizing them to reduce waste and maximize the value we create. Waste is any activity or cost that is unnecessary and does not add value to the customer (as opposed to activities that directly create value or are necessary for value creation).
In the article, Ten Types of Software Engineering Waste, I identified the following:
Partially Done Work and Backlog Mismanagement
Extra / Wrong Features
Defects / Rework
Unnecessarily Complex Solutions
Task Switching and Cognitive Load
Handoffs and Knowledge Loss
Heroics and Rush Mode
Non-utilized Talent
Waiting
Extra, Nonstandard, or Manual Work
The objective of linearization is to optimize almost each of these points. For examples, read the full article.
Hand-offs and The Role of QA
Throughout my decade-long journey across various stages of start-ups, I've experienced multiple transformations of engineering teams. From monolithic to distributed software architectures, from siloed teams to feature teams, and from big-bang releases to continuous delivery.
If I were to identify the transformation that was both the most challenging and the most influential, it would be how the organization approaches Quality Assurance. In my experience, it always started the same way—developers built the code, and a dedicated team of testers tested it.
This approach worked reasonably well in small engineering teams (~10 people), but as the organization grew, teams consistently faced similar challenges:
Who should write unit tests, engineers or testers?
"Us vs. them" dynamics, with differing goals, schedules, QA gatekeeping, and "ticket ping-pong."
Complex testing systems still required senior engineering assistance.
An inverted testing pyramid with the majority being heavy end-to-end (E2E) tests.
I would argue that handoffs between software engineers and an independent QA team are among the most dangerous practices that can hold back an organization and harm its scaling efforts. Handoffs inherently lead to knowledge loss. But handoffs between engineers and QAs are even more problematic—they often lead to developers not taking responsibility for quality at all.
Not to mention the scheduling nightmare when engineers finish their work, but the QA team is occupied with something else and won't be available until "next week." Code is released or hot-fixed long after the developers have moved on to a different context. Feedback loops take days, sometimes weeks, and the cognitive load on everyone (engineers, their managers, the QA team, and stakeholders waiting for the feature release) becomes overwhelming.
Linearization here can be achieved through a QA Shift-Left process where quality is owned by everyone on the team, there is no separate QA organization, and the testing pyramid is well-defined and respected.
For more insights on this matter, I recommend reading Do You Need More Testers or Better Tests?.
Code Reviews vs. SDLC Performance
In the latest DORA research from 2023, there is an interesting point related to linearization that I recommend checking with your team and organization. It’s about handling Pull Requests. According to the research, "Speeding up code reviews is one of the most effective paths to improving software delivery performance. Teams with faster code reviews have 50% higher software delivery performance."
Fast code reviews significantly increase an organization's operational performance and reduce burnout.
I see it this way. CI/CD automations are very common, even in lower-performing organizations. Today, almost everyone automates their build, testing, and deployment processes. Doing these manually is simply painful for engineers, so the first thing we do is automate these processes and forget about them.
Code reviews, however, cannot be fully automated. Even with today's generative AI solutions and code scans, humans are still involved. Reviewing someone else's code is usually tricky. Engineers don't always have full context; sometimes, they are afraid to take responsibility ("What if I approve it and it’ll break the production?"); often, they don’t have time for it because code reviews weren’t included in sprint planning (🙄).
Here are a few ideas to improve code reviews for inspiration:
In one of my teams, engineers implemented a solution that pings team members to remind them about open PRs. You can read about it here: How we improved code review process in the Android engineering team.
In larger organizations with feature teams, building engineering guilds is worthwhile. In these guilds, engineers can exchange knowledge and seek support from fellow engineers from other teams (consider a feature team with a single frontend engineer—who would review their code?).
Make it part of company culture. For example, at Stripe, “It is a big part of our engineering culture to help unblock a fellow engineer when they reach out for help. This includes helping engineers from another part of Stripe. We encode this directly in code review expectations.” Read more about Stripe’s engineering culture on
’s newsletter: Inside Stripe’s Engineering Culture - Part 1.Make it an objective. In one of my teams, we set a goal that code cannot be in review for more than 48 hours. With this goal, which we reviewed weekly, the team devised solutions and processes to achieve this result.
Linearization in Engineering Culture
Much like other simplification strategies, Linearization represents a cultural shift in how we think about collaboration and problem-solving. It requires moving away from hierarchical, siloed communication towards a more integrated, cross-functional approach where everyone involved in a workflow is directly connected and empowered to collaborate.
Teams must understand that they have the autonomy to make decisions and solve problems directly rather than waiting for approvals or feedback from other departments. This shift improves speed and efficiency and enhances team engagement and satisfaction, as team members feel more empowered and involved in the process.
To foster this culture, engineering leaders must promote open communication, trust, and a focus on shared goals. It involves not just rethinking workflows but also how we build and maintain team dynamics and relationships.
A great example is the shift from Transactional Leadership to Developmental Leadership. In classic team structures, leadership focuses on scheduling.
Consider my two examples: a siloed team where I "borrowed" an engineer or the devs vs. QAs teams—in both, we constantly have to calculate timelines and dependencies. The engineer is available for only two weeks, so we prepare everything in advance and squeeze in as much as possible. Or QA needs to test things by Wednesday to release them the following Monday—every bug discovered creates immense pressure on everyone.
What if we could do things differently? Rather than focusing on scheduling, we build an environment where complete cross-functional teams can do their job without hierarchical communications. This approach not only allows engineers to work with peace of mind but also frees us—leaders—from the constant pressure of coordination, planning, and unblocking.
Here’s a closing thought from Wiring Winning Organizations:
Dr. Eliyahu Goldratt and Jeff Cox’s book The Goal depends on linearized processes to find and remove bottlenecks that inhibit process flow to increase productivity and reduce the information process requirements.
A key insight was that managing how work was performed at the bottleneck was much simpler and more effective than scheduling the entire factory.
— Kim, Gene; Spear, Steven J. Wiring the Winning Organization
End Words
Linearization is a powerful strategy for reducing complexity in software engineering organizations. By creating workflows that minimize dependencies and foster direct collaboration, leaders can streamline processes, enhance communication, and improve overall efficiency. This approach not only helps in speeding up decision-making but also empowers teams to work more effectively and focus on their core tasks.
In this article, I explored Linearization and its impact on simplifying organizational workflows and boosting team productivity. By reducing cognitive load, improving collaboration, and minimizing handoffs, Linearization helps build a more agile and responsive engineering culture.
In the next article, I'll explore the final main theme of transformation—Amplification—and discuss how to effectively highlight problems and drive continuous improvement.
Thank you for reading, and I welcome your thoughts and feedback on today's topic.