On Thursday 30 October 2025, after a day at ElasticON Amsterdam, I went to the evening meetup of Site Reliability Engineering NL (SRE NL). It was hosted at the Datadog office in Amsterdam: the Datadog neon sign was on the wall behind the coffee bar, and the âSpecial thanks toâ slide credited Datadog and the Datadog User Group.
There were three talks, and they fitted together well. The first was about how people learn from incidents, the second about changing an organisationâs culture towards SRE, and the third about why engineers avoid the postmortem, the one meeting where that learning is supposed to happen.
This is a throwback built from my photos, so Iâve stuck to what was on the slides.
Before the start: SRE NL at the Datadog office, with the âthis is fineâ opening slide on both screens.
Community news: 2K members
Robin opened the evening, according to the agenda slide. The community slides came first:
- â2K!â: SRE NL had passed 2,000 members. The next slide was the Meetup âTotal and active membersâ chart, rising from November 2022 to just over 2,000 in September 2025, with a hand-drawn âMeetup community drivenâ label at the start.
- The organisers: âThe current organizers driving the communityâ showed eight people, with logos from Booking, bol., ING, Xebia and mollie under their photos.
- Contribute? Reach out on meetup.com, find past slides at sre-nl.github.io/slides, talk to the organisers, and send in topics to present.
â2K!â: SRE NL passes 2,000 members.
The plan for the evening: three talks, a break and drinks, ending around 21:00 to 21:15.
Busra Koken: your systems donât learn from incidents, you do
The first talk was âYour Systems Donât Learn from Incidents â You doâ by Busra Koken of Humans in Systems. Her intro slide described her as the founder of Humans in Systems, a coach and mentor, and a âFriendly Consultant who helps organizations navigate incidents with confidenceâ. It also said: âI also paint. A lot.â
The title says it all: learning is something people do, not something a system does.
She defined the job as âEngineering in complex systems for our business to continuously meet usersâ needs.â The next slide explained why those systems are sociotechnically complex:
- users that can do all kinds of expected and unexpected things
- developers that push code and config every few minutes
- software that runs on other peopleâs servers
The conclusion was in bold: âSo really, failures often emerge in the interactions of many parts, not inside a single component.â
Busraâs intro and the slide behind the talkâs argument.
My take: this is the right starting point for any incident review. If a failure comes from how parts interact, then the review canât stop at âcomponent X brokeâ. It has to cover what people knew, what they saw on their dashboards, and why the action they took made sense at the time. The system doesnât learn from any of that. The people who run it do.
Andrea: SRE culture and why buy-in is hard
After the break, Andrea spoke on âSRE culture and why itâs so hard to get buy-in in larger organisationsâ. She started with change management: âWhat do change models say about changing culture?â and âWhat is suggested to do when changing a culture?â
The slide showed several well-known models side by side. I recognised Lewinâs change model (unfreeze, change, refreeze), the McKinsey 7-S model, ADKAR, Kotterâs 8-step model and the KĂŒbler-Ross change curve. The slideâs point was that most models come down to a similar set of steps.
Change models first, SRE second.
Then came âSo, What about SRE Culture?â. On the left were the 7 principles: simplicity, embracing risk, eliminating toil, monitoring, automation, release engineering, and measure (SLI/O/A). On the right was a hand-drawn SRE culture patterns sketch:
- work to improve the future state (from reactive to proactive work)
- embrace risk
- have an experimenterâs mindset (test your hypothesis)
- empower developers: from passive safety to active policing, âaka guardrailsâ
- deploy fast and often for reliable software
- eliminate toil: get feedback and automate where possible
- understand the wider system
The 7 principles and a hand-drawn map of SRE culture patterns.
My take: in a large organisation, âempower developersâ and âguardrailsâ belong in the same sentence. Platform teams win buy-in when the safe path is also the easy path. Writing an SLO policy and asking teams to follow it doesnât do that on its own.
Line: why engineers donât like postmortems
The last talk, by Line, was âWhy doing a postmortem should be one of your favorite activities as an engineer!â. The slide I photographed gave two reasons engineers avoid them: postmortems are seen as an administrative task, and there are priority issues.
Next to those were two example write-ups that show the problem:
âWe faced bad performance on our instances. Looking at the dashboard we saw that the memory usage was high. A rolling restart of the system solved the problems.â
âThird party software delivered an update and after deploying to production it failed. Root cause is at third party.â
Two postmortems that close the ticket but teach nobody anything.
Both examples describe what happened, and neither explains why. Nobody asks why memory grew, why the update went straight to production, or what would catch it next time. That links straight back to Busraâs talk: if the write-up stops at âa restart fixed itâ or âthe vendorâs faultâ, the people involved havenât learned anything either.
What I took home
Put together, the three talks made one argument: reliability is a people problem with technical symptoms.
- Review the interactions, not just the component. Busraâs sociotechnical slide is a good checklist for any review: users, deploys, and dependencies you donât control.
- Treat culture change as change management. Andreaâs mix of change models and SRE principles is a reminder that rolling out SLOs is an organisational project, not a tooling one.
- Make postmortems useful, so people want to write them. If theyâre paperwork, you get Lineâs two examples. If they produce a real follow-up that a team cares about, people will show up.
