2025 was intense. Thankfully, I never had to write code half-asleep. 😃
Looking back, it was a mixed bag—with a couple of genuine aha moments.

Focus

We focused on four areas.

Operations (Ops)

Ops covered two planes: reactionary and proactive.
The reactionary plane dealt with incidents and bugs. The proactive plane focused on internal tools and dashboards.

Incidents and bugs came from two places. Some were customer-reported issues. Others came from failures in our data pipelines.

Improvements and migrations

Alongside Ops, we worked on a steady stream of small tweaks and minor migrations.

Tweaks included library upgrades and code refactoring.
Migrations covered database changes, service isolation, service unification, and similar work.

Projects

There was a constant flow of features, epics, and stories coming from the product roadmap.

Pivots and disruptors

These were the big bets. Efforts where we changed direction or introduced major ideas into the product.

Here’s what I learned.

Cut scope, not to-dos

In hindsight, this was probably too many focus areas for a small Engineering Team.

Instead of explicitly saying no to some initiatives, we trimmed the scope of almost everything we worked on. That turned out to be the right move.

As an Engineering Team, we don’t control the mountains we are asked to climb. But we do control the route we take.

Organize teams around outcomes

In year one, the team was organized around system boundaries—content ingestion, data platform, intelligence modules, DevOps, and so on. That approach caused several problems.

• A few leaders became responsible for everything, which diluted accountability for individual engineers.
• There were too many handoffs, and each handoff lost context.
• Clear ownership was hard to establish.

In year two, we reorganized around business outcomes, aligned with our strategic domain design. That change addressed most of these issues.

Hits

What we got right.

• Investing early in CI/CD pipelines paid off. It created space for healthy debates, helped us settle into a rhythm, and—most importantly—made onboarding fast. New team members could push code to production in their first week. One developer did it on day two.
• We embraced evolutionary software development. We didn’t try to perfect the first service or component we built. Instead, the second version was better than the first, and the third better than the second. Over time, we built a catalog of patterns that worked—and those that didn’t. As I often joked with the team, nothing was ever completely broken or completely perfect, and that was a good thing.
• Being a remote Engineering Team, our biannual in-person meetups mattered a lot. They counterbalanced many of the usual challenges of remote work. To be fair, this was a company-wide strength and more a reflection of culture than of Engineering alone.

Misses

What I wish we had done better.

• Our evolutionary approach helped us learn, but it also slowed us down early on. In hindsight, engaging expert consultants at the beginning could have accelerated that learning.
• We struggled to consolidate key areas. We rarely debated where to invest for the long term and where to consciously cut corners. We instinctively focused on core and supporting domains, but a more deliberate choice might have served us better.
• We never established a reliable delivery rhythm. Iteration after iteration, we committed too many story points and consistently missed the mark by 30–35%. The team was highly motivated and wanted to get more things done, but this made it hard for Product to set realistic expectations with Sales and Customer Success.