From Local Maximum to Global Minimum

As a science graduate, I’m always impressed by the beauty of the nature.

In engineering leadership, the most dangerous cost isn’t the payroll: it’s the invisible “Development Tax.” This is how I diagnosed a reactive engineering culture and transformed it into a data-driven value delivery system.

1. The Diagnosis

By the end of Q4 2025, I identified that the team was trapped in a reactive spiral. When I looked at the data, the sum of our Product Roadmap and Customer Wishes accounted for only 52.08% of our total effort. The remaining 48% was consumed by technical debt and regulations. Essentially, we were working without a focus.

To make the cost of this clear, I introduced a metric I call The Development Tax:

Development Tax = Firefighting​ / (Product Roadmap + Customer Satisfaction)

In Q4, this tax was 24.85%. Think of it this way: you go to a store and buy a kettle for €100. You take it home, and it doesn’t work. You go back, and they tell you it will cost another €25 to fix it. This is unacceptable in retail, and it’s unacceptable in engineering. Just because the company “doesn’t see” the €25 bill directly doesn’t mean we aren’t hemorrhaging value. With nearly one new bug appearing every two days (13 to 15 bugs per month), half of our energy was imprisoned by maintenance.

2. The Strategy

The team I took over in mid-2025 had been operating in a passive project mode for over three years. Old habits were entrenched, and hope for change was low. The previous system of giving the team one day every two weeks to address debt was a failure. By the time a developer decided what to do, the day was over. Nothing was ever finished.

I realized that to win back our focus, I had to make hard choices. I decided to schedule 4 to 5 month blocks dedicated to technical debt and redundancy reduction, treating them as first-class citizens alongside the Product Roadmap.

• The Trade-off: I accepted that in the short term, some stakeholders would be unhappy. You cannot satisfy everyone when your house is on fire.
• The Action: In Q1 2026, I purposefully surged our Roadmap and technical cleanup effort to 50.41%.
• The Result: I dropped the Development Tax to 13.91%, which is a 10.94% absolute reduction in just one quarter.
• The Projection: In my opinion, 13.91% is still too high. I recall my time competing against other virtual companies in the Global Management Challenge. While 0% is not realistic because everything eventually fails, 1% to 2% is excellent. Back then, we fought to keep the defect rate below 5%. For a software product, I don’t believe a 5% tax is a bad benchmark. We must continuously work to push our tax below that 5% threshold.

3. Automation ROI

Since we are regulated by the CCQ department, the team naturally adopted a reactive way to deal with issues raised by Snyk and Wiz. There was an escalation table based on impact levels, and they all ended up directly in the sprint. In a world where we deal with a new bug every second day alongside dependency and infra security updates, focus was impossible. However, because it is regulated, we could neither give up nor dedicate ourselves fully to it.

The Evolution of the Strategy: First, I implemented a triage: we accepted only Critical and High-level issues directly into the sprint. Everything else was postponed to our Wonder Week. This gave the team breathing room to focus on the roadmap, but at the end of the day, the effort was still there.

I then evolved this into a full automation strategy for Low and Medium level dependency updates using Renovate and Claude AI. Between Q4 and Q1, we spent an average of 18% of our time on regulation. My projection for Q2 is to reduce this to 5% to 8%. If this becomes a reality, we will have saved 6% to 9% of total engineering time, which I will then reinvest into high-value product areas.

4. Predictability

I operate on a fundamental conviction: You can’t optimize before you standardize. Teams want autonomy, and leaders want speed. Neither happens without predictability first.

Historically, this team operated in a “Project Mode” where Scrum was not serious. It was a combination of Kanban born from the accepted reality of bugs and security issues. The problem with this “Scrumban” approach is Value Decay. The time between value creation and value realization is so large that the value loses its impact before it is fully realized. Things start but never end, making commitments nearly impossible to communicate.

Predictability is an underrated skill. When I stand against entropy, it is exhausting. Building a perfectly working engine is one thing: protecting it against side effects requires immense mental energy. I started with simple cycle time measurements because while individuals are often happy with their own daily performance, team performance is often invisible.

• Bug Cycle Time: We reduced our bug “In Progress” time from 1.38 days to 0.68 days, a 50% improvement. Addressing technical debt reduced complexity and allowed us to resolve incoming issues faster.
• The Reality Check: My analysis of current task data shows that in the last 30 days, tasks remained “In Progress” for an average of 2.67 days. This is higher than our 6-month average of 2.20 days.
• The Cascading Effect: When cycle time is flaky, the sprint scope is not delivered. When scope is not delivered, reliability is damaged, leading to cascading issues in every high-level meeting.
• The New Standard: We must adapt a work style where we break down things into smaller chunks, plan properly, and start and finish as a team, not as individuals. I will mandate two hard constraints:
• The 2-Day In-Progress Rule: No task shall exceed two days in active development.
• The 1-Day Review Rule: Outputs must be ready for review or deployment within one day.

Regarding the era of AI: I am still figuring out what it breaks. AI speeds up code generation, but we must ensure it doesn’t break our new standards of predictability.

5. The Q2 Projection

To remain a competent value creation engine, as discussed in my articles on software economics, we must prioritize long term value through CAPEX investment. This requires a disciplined focus on the Product Roadmap.

Having cleared the heavy technical debt in Q1, I am aiming for a highly optimized capacity allocation for Q2 and beyond:

• Product Roadmap Focus: I aim for 60% to maximize our long term value creation.
• Development Tax Target: Dropping to less than 10%.
• Firefighting Ceiling: Capping at less than 7%.
• Regulations: Projecting a reduced footprint of 5% to 8% thanks to automation.
• Customer Satisfaction: Maintaining a steady 10% to 12% for high-impact quick wins.

6. The “Wonder Week” (3+1 Model)

Initially, the system provided one day every two weeks to satisfy CCQ stakeholders and another day for innovation. In total, there were four independent days a month to “do something.” The idea for the Wonder Week emerged from the failure of this fragmentation. Fragmented days make it impossible to start and finish anything meaningful.

I consolidated these days, added one more, and created a full 5-day “Wonder Week” every fourth week. This is the moment engineers know they can leave technical debt to a future where they have full focus.

• No More Begging: Engineers no longer need to beg for time to refactor. The time is there, guaranteed, every fourth week to cover debt, solve bugs, or complete a refactoring cycle.
• Direct Value Exploitation: With automated dependency updates saving us time, we use this week for personal development, training, or pairing with customers to solve their problems immediately. Instead of creating massive epics to address small needs, we exploit them in a few days.
• Vibe Coding: I welcome low-quality software or “vibe coding” during this week as long as it creates immediate value for the business. These rapid efforts are then addressed in the long-term product roadmap where they are rebuilt to production-grade quality.

7. Betting on Value

The historical problem here was measurement. We often believed things were getting better based on gut feelings and occasional user interviews. However, we rarely verified if those efforts actually contributed to success. Teams learned to estimate work using the 1–2–3–5–8 story point model, but these numbers are far away from business reality.

I want my team to be thinking partners, not just task executors. When people use story points, they naturally tend to justify their efforts based on those points. I want them to think in terms of impact.

To achieve this, I brought a proper product analytics tool (PostHog) into our ecosystem. This allows us to have measurable KPIs addressed to value propositions that directly contribute to the business vision of doubling the company value.

• The Implementation: I navigated the legal and privacy approvals, tested the features, created a standardized workflow template, and added the company credit card.
• The Goal: We are currently in the implementation phase of these KPIs. Within six months, we will reach a point where our discussions center on impact rather than story points. This will be a definitive game changer for the organization.

Conclusion

I was actually very close to realizing this vision with my previous team. However, we hit a bottleneck. With such a small team, we were responsible for ten successful services that could not tolerate downtime. Even as we improved daily operations and switched to 1-week sprints, the opportunity cost was real. We used restructuring as an opportunity to share the responsibilities and spread the team’s DNA across the organization.

In math, this is called a Local Maximum. Imagine a wavy line on a Cartesian plane representing your company. Each team is part of that line, performing with its own ups and downs. The goal is to reach a local maximum, create blueprint standards, and help the organization move forward with those blueprints to shift the base of the Global Minimum. Imagine a virtual horizontal line crossing the average of that wavy line: that is the current valuation of your company. Your goal as a leader is to shift that imaginary line upward by reaching local maximums and helping others grow.

What made me really sad after all these efforts to bring standards was seeing them go, and having to start from scratch. Accepting that reality really hit me. Now, once again, I am very close to that peak. However, I must end this chapter. As I write this article, I am approaching my last days with this team. I will switch to another team where I will explore a different set of opportunities.

I believe that everything happens for a reason. If it is meant to be, there is something waiting for me. So, let us keep our fingers crossed, embrace whatever comes our way, and shape it with our strengths, kindness, and professionalism.