I am enthusiastic about resolving incidents well. It is a time when people can come together and show their passion for their product. They get online after hours because a colleague needs help.
If you are interested in improving your organization, I give workshops on the topic. So reach out to me
Finally, if you finish a big incident, do a post-mortem with everyone involved and see how to improve. As a manager or architect, it is important to attend to show that operational excellence is just as important as feature work!
The fourth step is to not dive on the first hunch. Take a moment to hypothesize multiple theories about what is going wrong and then decide how to react.
The third step is assigning roles; key is the Incident Commander, who is responsible to keep incident resolution moving. They keep oversight, make decisions, and delegate. The most important quality: Gravitas. They can make decisions and kick the CEO out of the room if it is a disruption.
The second step is to assign a severity level. How much impact is there for how many customers? Incidents need to receive the proper priority. Making clear how big the incident is ensures that.
The first step in incident management is to get everyone in a voice call. Your incident resolution is as fast as your communication medium. E-mail, Days. Slack, Hours. Voice Call, Minutes.
Yesterday, I gave a presentation about Incident Management at Scale at the Navara and Essent meetup. Of course, the lights went out during the meetup!
Incident management at scale is all about organizing people to quickly work together to resolve an incident.
I always bring a long HDMI cable and have my laptop. But it is crazy how this is not yet solved.
@cdk.dev
There is a baseline of adoption and ecosphere richness that technology should pass, and afterward, it becomes less important. AWS CDK and Terraform both pass that bar.
The correct question is: What technology better fits your company?
AWS CDK is adopted well enough and has a rich ecosphere. Many libraries can help you solve challenges. You can trust and depend on your company.
AWS CDK is similar to Golang. AWS CDK is built internally by AWS and is heavily used.
Of course, there are more stars on GitHub for Terraform. A lot of companies are using Terraform. But all the Azure engineers also star Terraform, which does little to enrich your AWS Terraform ecosphere.
Golang was built to solve a problem: a programming language that helps to quickly onboard new engineers. Golang was also very good at building CLI tooling and compiling many platforms. That is why we picked it. It delivered on that promise.
- Golang was used intensively by scaleups in the US. Many companies were using it, but it was far from mainstream. Google pushed and carried Golang heavily.
- The Golang ecosphere was vast and strong. We could use so many libraries to solve the challenges we face.
I was working at a startup in the Netherlands and we picked Golang. Hardly any company in the NL was using it. Java, for example, would have a massive market share. So, was Golang a lousy choice for us?
No, Golang was great for us!
Is the total share of adoption an argument in picking between competing technologies?
Similar arguments are made in the Terraform vs AWS CDK discussion. But it doesn't matter.
With Rocketleap, I have helped many customers get certified or pass their next audit with automated tooling. I started noticing that there are common phases companies go through and need to complete to prepare for the next audit.
So, I have written down these phases in order.
I have written a blog post on how to start with compliance on AWS.
https://rocketleap.dev/blog/start-compliance-on-aws/
Often, the focus is just on fixing the issues you know will be problematic for your next audit. So, the approach feels improvising.
Software Development is a small step in the whole chain of a business.
- Customer Support: A new feature is worth nothing without customer adoption, so support customers using the new feature
Operations: perform business processes efficiently that support the business, like filling in WBSO hours
- Marketing: making marketing aware that we launched a new killer feature they want to talk about
- Sales: understanding that some features are suddenly a priority to help people choose your company
As a software engineer, you can get by with only focusing on the development part. Because other employees will focus on the other 4 parts.
You will be a better engineer by keeping marketing, sales, customer support, and operations in your mental model as well.
An example of delivering a feature:
Every week, I start to plan my week
- Marketing: How can I let more people know abot us?
- Sales: How can I help people decide?
- Development: What new features should I add?
- Customer Support: What do I need to do to support my customers?
- Operations: What operations are required for my business?
Software Development is only a small part of a business.
Starting and running a business has taught me so much in the last two years. I am a better engineer for it.
It seems GitHub actions just became self-aware and sentient. This repo has no actions defined, yet it reacted:
These are incredible results that I look very happily back on. I plan to help transform more companies in 2025.
Not so much because doing fantastic at AWS is the end goal, but because of the amazing missions these companies are on.
- The view of AWS shifted from being a technical necessity to a business enabler driving growth.
- Developers always needed support from developers in other teams and are now deploying on their own like DevOps pros.
- A company got ready for a business-enabling audit by delivering a multi-account infrastructure and IAM least privileged access in a single day.
Rocketleap provides you with the AWS platform that simplifies AWS so that you can focus on features. I have seen tremendous transformations in collaborating with clients of Rocketleap in 2024.
