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 use the term “high-performing, serverless-first team.” Lately, however, we’ve realised that a lot of organisations broadly apply those principles and the serverless-first doctrine.
Let’s run through these tenets or guiding principles and see what is behind each. We often joke that this list took us ten years to write. But we 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 the build as the final option
continuously optimise the total cost
build event-driven via strong APIs
build solutions that fit in their heads
And above all else, they epitomise engineering excellence.
How do you chase a business outcome (KPI)?
Chasing a business outcome is deliberately number one. Our favourite question to ask a team is, “What is your business KPI?”
A good team will know! Depending on how it’s trending, they can rhyme off the current value with joy or disappointment. 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.
This tenet represents Product Thinking. If you have not heard of this KPI and need guidance, we recommend looking at the North Star Framework.
Being secure by design
We borrowed this from AWS! It’s pretty simple. It’s also no mistake that it’s second on the list behind business needs.
Security is everyone’s job. The “Secure by Design” tenet that AWS follows is excellent.
This tenet represents good Secure Development and Cloud Security practices.
We 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 following two tenets represent the four DORA metrics.
The first two metrics are Deployment Frequency and Lead Time. When combined, these two metrics represent a metric for throughput. Great cloud teams move and deploy quickly. The project timeline may be similar, but they will be testing, learning, and pivoting quickly. The team should also be able to deploy on a sixpence.
This tenet represents Continuous Delivery. You should read the book ‘Accelerate‘, as the four DORA metrics are only a starting point. You should also look up Continuous Delivery expert 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) – How quickly can you recover when you have an outage?
This tenet represents reliability, which is covered brilliantly in the Well-Architected framework.
You should run a Well-Architected Review to improve availability.
Rent/reuse with build as the final option
We dream about rent/reuse. However, 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 costs like 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 serviceful. In other words, you access capability via managed services (lambda, S3, eventbridge, step functions…).
You should check out the AWS Serverless page. A service you dismissed in 2019 as being immature may have changed significantly by now.
Continuously optimise 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 optimisation as a team practice is probably the most significant indicator of a high-performing, modern cloud team.
This tenet represents responsibility for the system’s cost as an asset. The team owns the system and keeps costs efficient and optimised. They will refactor to reduce the bill.
We recommend you 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 will likely 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 could build the system quickly, so we spent more time getting the Domain Design right. This means that changes in the future will be easier.
To learn more, you should look at EventBridge, Event Storming and the DDD starter project.
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 nods to good organizational design and supporting teams as a unit of delivery. You need to design systems to be right-sized.
For a vibrant discussion, you should read the excellent ‘Team Topologies‘ book.
Modern cloud teams that epitomise engineering excellence
Even though Code is a Liability, the team must be a good engineering unit. A diverse, inclusive team will have a good balance. And they will have the strength and depth to solve any problem. As well as the maturity to know what problems still need to be solved. How does your team measure up?
Serverless Craic from The Serverless Edge
Check out our book, The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn