Back in 2019, one of the questions I started to think about was: “what does a high-performing modern cloud team look like?”
What kind of things do they say, what principles do they hold dear and what tenets do they not let go of.
We started to use the term “high-performing, serverless-first team.” But lately I realise that there is a broader application of those principles and the serverless-first doctrine.
Let’s run through these tenets or guiding principles and see what is behind each. I often joke that this list took me ten years to write. But I can explain it in ten minutes.
A high-performing, serverless-first team will:
- chase a business outcome (KPI)
- be secure by design
- keep a high throughput of work
- reliably run a high stability system
- rent/reuse with build as the final option
- continuously optimize the total cost
- build event-driven via strong APIs
- build solutions that fit in their heads
And above all else, they epitomize engineering excellence.
How do you chase a business outcome (KPI)?
Chasing a business outcome is deliberately number one. My favorite question to ask a team is, “what is your business KPI?”
A good team will know! They can rhyme off the current value with joy or disappointment depending on how it’s trending. It will be a critical business target. Things like “defects fixed” or “epics complete” are not business outcomes. You are looking for a team to focus on sales figures, customer wait times or activations.
Being secure by design
I have borrowed this from AWS! And this one is pretty simple. It is also no mistake that it’s second on the list behind business need.
This tenet represents good Secure Development and Cloud Security practices.
I would advise you to look at the STRIDE Threat Modelling process or the AWS Secure By Design white paper to learn more about your security stance. If you don’t find any gaps, you are doing it wrong.
Cloud teams with a high throughput of work
We are massive fans of DORA (DevOps Research Assessment). So the next two tenets represent the four DORA metrics.
The first two metrics are Deployment Frequency and Lead Time. When you combine these two metrics, they represent a metric for throughput. Great cloud teams will move and deploy at speed. The project timeline may be similar, but they will be testing, learning and pivoting at speed. The team should also be able to deploy on a sixpence.
This tenet represents Continuous Delivery. I would advise you to read the book ‘Accelerate‘, as the four DORA metrics are only a starting point. I would also advise you to look up Continuous Delivery guru, Dave Farley, who has some excellent books and videos.
Reliably run a high stability system
The second part of the DORA metric is availability. There’s no point in deploying quickly if the system is up and down like a yo-yo. You need to use a combination of:
- Change Fail Rate – how often do your deployments fail; and
- MTTR (Mean Time To Recover) – when you have an outage, how quickly can you recover.
This tenet represents reliability, which covered brilliantly in the Well-Architected framework.
I would advise you to run a Well-Architected Review to improve availability.
Rent/reuse with build as the final option
We dream about rent/reuse. But real modern cloud teams will ruthlessly rent and reuse from the cloud provider because code is a liability.
Great teams will measure twice and cut once. They will go out of their way not to write code. Code incurs cost: testing, deploying, securing, running and maintaining. It is better to let the Cloud or SaaS Provider do it all. Just call the service and spend your valuable time writing business logic for your business.
This tenet represents serverless and servicefull. In other words, accessing capability via managed services (lambda, S3, eventbridge, step functions…).
I would advise you to check out the AWS Serverless page. Perhaps a service you dismissed in 2019 as being immature will have changed significantly by now.
Continuously optimize the total cost
Great teams treat cost as an architectural concern. When you ask them how much their running costs are, they can give you an accurate figure without looking at a dashboard. Other teams can’t even find the dashboard and just go large on all instances. Cost optimization as a team practice is probably the most significant indicator of a high-performing, modern cloud team.
This tenet represents responsibility towards the cost of the system as an asset. The team owns the system and keeps costs efficient and optimized. They will refactor to reduce the bill.
I would advise you to check out Duckbill Group and AWS FinOps for a wealth of information on Cloud Economics.
Build event-driven via strong APIs
Modern integration means events and patterns can handle elasticity, outages and scale. Synchronous API calls and point-to-point integrations are hard to get right when things go wrong. Good modern applications will have solid boundaries and clear contracts between components. They are likely to use managed services like SNS or SQS to buffer traffic bursts.
This tenet is a nod towards Event-Driven Architecture and Domain Driven Design. Eventually, we can build the system quickly, so we spent more time getting the Domain Design right. This means that changes in the future will be easier.
I would advise you to look at EventBridge, Event Storming and the DDD starter project to learn more.
Build solutions that fit in their heads
A cheeky one at the end encourages simplicity and clean design. Dan North famously uses this term in many of his talks. We have seen too many massive systems that have broken developers due to high cognitive load.
This tenet is a nod to good organizational design and supporting teams as a unit of delivery. Systems need to be designed to be right-sized.
I would advise you to read the excellent ‘Team Topologies‘ book for a very rich discussion on this.
Modern cloud teams that epitomize engineering excellence
Even though Code is a Liability, the team must be a good engineering unit. A diverse, inclusive team will have good balance. And they will have the strength and depth to solve any problem. As well as the maturity to know what problems not to solve.
Several years have passed by since 2019. But I believe this list stands up to show you what a high-performing, modern cloud team looks like. How does your team measure up?