How serverless can improve a startup's feature velocity

Today’s email is inspired by this great 2-part series on Feature Velocity and Serverless by Paul Johnston (from 5 years ago but still highly relevant!)

Arguably the one thing that early-stage startup engineering teams care most about is improving their feature velocity—how fast they can add/enhance product features.

Small dev teams don’t spend all their time building features. They also have to fix bugs, maintain infrastructure, manage CI/CD pipelines, pay down architectural and code tech debt, etc. The more of these tasks, the lower the feature velocity at any point in time (assuming a constant team size).

But in order for FV to be useful measure, it needs to be taken over a long period of time, not sprint to sprint. There are two reasons for this:

1. The above tasks are intermittent—you could go for 4 sprints with just building features and then spend a whole sprint re-architecting to fix perf issues
2. To minimise volume of future rework, features may be shipped slightly slower (e.g. with automated tests)

So how can serverless help improve feature velocity? Generally, it reduces the volume of many of the non-feature tasks:

• All infrastructure is managed by AWS
• Autoscaling minimises performance issues and removes need for capacity planning
• Simpler IaC makes CI/CD easier
• Cloud services == less code to write & libs to maintain, which should lead to fewer bugs
• DynamoDB’s “no bad query” design gives near-constant performance over time whereas RDBMSs tend towards slowness
• Inter-team communication is less lossy because individual devs can take on a wider set of tasks (without needing specialist infrastructure/networking knowledge, say)

Of course you must factor in the initial hit to feature velocity that comes with your team learning serverless in the first place. But once a team is over this hump, the efficiency (and lower ops peace of mind) rewards are there to be reaped over time.

— Paul