Problems I've worked on

Instead of planning a set number of tickets, I agreed with my team on the outcome we wanted to achieve during the sprint, the sprint goal.

The actual tickets were secondary and not part of the plan, so the team could change them as needed. During the sprint, we kept iterating on the solution, including its scope and form, while the expected outcome remained our target.

I linked company objectives to agreed investment criteria, aligned on a mid-term product strategy, and described the required technical work in business terms. When a new request came in, I used those agreements to make the trade-off clear.

There still needs to be room to change direction. What helps is having a shared basis for deciding which request matters more, what it replaces, and who needs to know. Otherwise, every interruption starts the same negotiation again.

Production problems were consuming a recurring share of engineering capacity. We were still planning as if all that capacity was available for roadmap work, hoping the next cycle would be different.

I made the cost visible and reserved capacity for remediation. A dedicated team proactively improved the system instead of waiting for the next incident.

Moving large batches of changes through the system is slow and prone to errors. I led the adoption of continuous delivery, where teams deployed changes to production throughout the day while keeping unfinished features disabled behind feature flags.

Once a feature was complete and tested, we could release it independently by enabling its feature flag. Features no longer had to wait for a larger release before they could reach customers.

I grew an engineering organization from 15 to around 50 people while avoiding this slowdown by making the process more distributed and autonomous. We streamlined interviews, made onboarding self-paced, and introduced guardrails that allowed less experienced engineers to take part without depending on senior engineers at every step.

As the organization grew, we structured teams so they could deliver independently without requiring everyone to have deep knowledge of the whole product.

I coached my direct reports in intent-based leadership and managing up, helping them and their teams act more autonomously. I asked leaders to bring me a proposed decision with their reasoning and take the first step without waiting for my approval.

Decisions started moving faster, people grew into more responsibility, and I only had to step in for real escalations.

I built a relationship with my manager based on intent-based leadership and managing up, which allowed me to stay in the driving seat without becoming a bottleneck.

I kept my manager and other stakeholders informed about the context, my intent, and the plan. This greatly reduced the chance of panic-driven decisions. When my manager needed to make a decision while I was offline, he had enough context to act in line with the plan.

I built a career growth framework that made the expectations for each level clear. I aligned individual goals with the framework and used one-to-ones to have concrete discussions about each person's growth and future in the company.

I treated career growth as something we planned together. People knew where they stood, what they needed to work on, and what they could expect next.

I introduced a process for continuously sharing this knowledge across the team instead of relying on specific individuals. We built a knowledge base, worked more closely together, made domain decisions collectively and refactored the codebase to be easier to navigate and understand.

I opened the codebase so anyone could contribute across team boundaries, with code guardians reviewing high-impact changes. I built cross-functional teams that owned features end to end, as far as reasonably possible.

I used OKRs to align priorities across the organization and introduced a delivery lead role to coordinate more complex work that still required multiple teams.

I learned to act as an adapter between the startup and the larger organization. Despite the pressure, not everything needs to be copied from the corporate world. Some processes can be adapted, others simply need to meet specific requirements, and the information and context that seem to be missing can often be found once you know where to look.

This allowed the startup to preserve its way of working while still meeting corporate expectations. The key is to accept that the two sides can work differently, as long as both make the effort to collaborate and respect each other's needs.

I defined a long-term technical direction based on where the business and product were going. We mapped the existing debt against the product roadmap to identify which parts of the codebase would matter next.

This gave us a technical debt roadmap driven by planned product work. Instead of fixing debt everywhere, we improved the areas we were about to change. Technical improvements became easier to prioritize, and feature delivery became more predictable.

I moved testing from the cloud to local environments. This reduced infrastructure costs and removed much of the waiting for shared environments. It also gave engineers faster feedback, simplified and sped up the delivery pipeline, and allowed AI agents to work more autonomously.

Product engineering is a complex, interconnected system. Making one part more productive doesn't necessarily make the whole system faster. It can simply move the bottleneck somewhere else.

I tracked that bottleneck as it moved from generating code to reviewing it, testing it, deploying it to production, and eventually back to getting the product specification ready in the first place.

I learned that the biggest benefit of agentic engineering is not the volume of work it can produce. It's how quickly you can iterate on a problem and move from an idea to an outcome.

I reduced the support team's dependency on engineering by helping them build the skills to investigate more issues themselves. We created a knowledge base, built tools to investigate and resolve common requests, and deployed an AI agent that could handle some problems without requiring engineering attention.

I aligned Support and Sales around a shared process for setting customer priorities and communicating them to engineering through a prioritized backlog. I also introduced a way to identify pain points shared across customers and connect them to revenue at risk.

This gave engineering a clearer view of which customer problems mattered most and where their time would have the greatest impact.

The trap is trying to make every capability equally native to both cloud and on-prem. That usually means either limiting the cloud product or effectively building two products while pretending there is only one.

Instead, we maintained a shared core with different deployment profiles. Cloud became the target for innovation, while on-prem had an explicit compatibility contract that defined what we would continue to support.

I also made the cost of maintaining on-prem visible, so the business could use that data when making product and investment decisions.

I built cross-functional teams that included non-engineering experts such as compliance, so we could work together toward the same business outcome rather than approaching the problem from separate functions.

Instead of asking, “Is this software allowed?”, I asked, “Which requirement or risk are we failing?” and “What is the smallest change that would make this acceptable?”

As part of our broader AI adoption, we strengthened engineering standards and automated as many quality gates and routine decisions as we could.

We introduced AI-assisted code review, automated checks against RFCs and ADRs, pull request triage, and stronger security and software supply chain controls. These included dependency analysis, secret detection, hardened container images, and cloud policy checks.

These controls applied to all engineering changes, not just AI-generated code.

Traditional organizational structures, especially in larger companies, struggle to keep up with this new pace of engineering.

To prepare my organization for it, I restructured it into smaller units, gave people more responsibility and autonomy, and connected them more closely to the problems they were solving. This allowed more decisions to be made within the teams instead of moving up and across the organization.

I created a startup-like team outside the legacy organization to accelerate the development of a new AI product capability. The team had enough independence to discover, prototype, and iterate quickly without inheriting every dependency and coordination mechanism of the existing organization.

But if you work on the wrong problem, going 10x faster just creates 10x more waste. The question that matters is whether you're getting faster and whether that speed contributes to business growth.

I've measured DORA, SPACE, squad health, and other engineering metrics. They're useful, but none of them answers that question. I also worked with product managers to define a value score for each ticket, but that often created a false sense of precision.

Eventually, I learned there is no single metric that captures engineering effectiveness. What matters is keeping the discussion alive about how much value we're delivering to customers and whether we're getting better at it. The engineering metrics are still important, but I treat them as hygiene rather than the goal.