Looking back at 2024, here are my top 3 lessons and retrospectives from helping build a small Engineering organization from scratch and operating it for a year.

Keep Ops close to customer issues

When our customers face an issue, they contact our customer success manager. Usually, one or more monitoring systems flag a potential issue earlier, allowing us to fix it before the issue impacts the customer. We have built our monitoring systems to mimic how an issue would impact a customer's interaction and view this impact on a customer-by-customer basis. This view complements the traditional service-oriented status view with service-level stats like uptime, latency, etc.

Scale is a journey, not a destination

Copilots, internal tools, reusable libraries, and shared services help scale Engineering efforts to do more with less. For a small Engineering Team, putting off improving daily work is easy and tempting. To prevent us from putting off daily improvement, we piggyback them with the product roadmap where they will have the most impact. This strategy also avoids premature optimization.

Paying technical debt is a habit

In a startup, paying technical debt is a continuous, unplanned activity. You get it done instead of debating it in story points. We pay down technical debt every iteration, month, and quarter. This strategy works for startups when they have chosen modern technology stacks and no big technical migrations are required.

Retrospective

Wins

• Getting ahead of recruitment is the hardest challenge but has the most outsized impact when done well. In other words, the Team matters the most (no surprise!)
• It worked for us to keep processes chasing the Team, i.e., only implement as many processes as needed to ease a Team's pain rather than try to get ahead of imagined issues.
• Bottom-up product reporting has marginal benefits without top-down organization-level prioritization. Moving to an organization-wide OKR gave us confidence that we were all rowing in the same direction.

Misses

• Everyone in a small Team is building parts of the system landscape. We eventually converged on a set of system design principles, but we should have done it earlier in the development journey.
• We delayed creating a shared risk understanding to balance system design complexity.