Kenny (Baas) Schwegler

How do you keep a culture of team autonomy while scaling, without losing coherence? That's what we've been working on at DHL eCommerce Benelux for the past years. This Wednesday Marc Rooding and I tell the story at Digital Architecture Design Day >>>

So we looked for ways to have both: • Architecture Advice Process: decisions stay with teams, made in the open • Collaborative modelling: shared understanding across boundaries • A board that changed its role along the way

How do you keep a culture of team autonomy while scaling, without losing coherence? That's what we've been working on at DHL eCommerce Benelux for the past years. This Wednesday Marc Rooding and I tell the story at Digital Architecture Design Day >>>

We grew from a handful of engineers to 150+ people in 35 teams. Our culture was built on teams deciding close to where the knowledge is. That's what made us fast. Scale changes that. More teams, more boundaries, more ways for the whole to drift apart.

A year ago today, @roundcrisis.com, @andrewhl.bsky.social and I published the first episode of Stories on Facilitating Software Architecture & Design. Yesterday episode 27 went out. We've kept it going every two weeks since.

Four architects drawing four different diagrams of the same system. A sponsor's goal contradicting the team's 48 hours before kickoff. That's all architecture and design work.

A year ago today, @roundcrisis.com, @andrewhl.bsky.social and I published the first episode of Stories on Facilitating Software Architecture & Design. Yesterday episode 27 went out. We've kept it going every two weeks since.

And acting on that guess has never been cheaper. Generating code costs almost nothing now, so you can build on an assumption nobody checked and have it running before anyone notices. What hasn't gotten cheaper is the conversation that would have caught it.

A year ago today, @roundcrisis.com, @andrewhl.bsky.social and I published the first episode of Stories on Facilitating Software Architecture & Design. Yesterday episode 27 went out. We've kept it going every two weeks since.

We spend less time alone with the code and more time in conversation with the people who know what the system is actually for. That gets treated as a soft skill we pick up along the way, which it isn't.

A year ago today, @roundcrisis.com, @andrewhl.bsky.social and I published the first episode of Stories on Facilitating Software Architecture & Design. Yesterday episode 27 went out. We've kept it going every two weeks since.

We spent two days training architects and tech leads and never gave them a definition of architecture. That was deliberate. There is no settled definition, and that is a large part of why architecture frameworks travel so badly from one organisation to the next.

AI came up once across both days, and only to say that none of this gets easier to skip. The hard part has always been building a shared understanding of the user, their needs and the market they are in.

We spent two days training architects and tech leads and never gave them a definition of architecture. That was deliberate. There is no settled definition, and that is a large part of why architecture frameworks travel so badly from one organisation to the next.

We finished with a stressor analysis from Barry O'Reilly's Residuality Theory, which opened up complexity and why understanding the strategy, the landscape and the market is what lets an architecture survive significant changes it was never designed for.

We spent two days training architects and tech leads and never gave them a definition of architecture. That was deliberate. There is no settled definition, and that is a large part of why architecture frameworks travel so badly from one organisation to the next.

The second group had already done that work. What they were missing was the landscape those decisions get made in, so we started with @swardley.bsky.social Wardley Mapping and where users, their needs and the market sit within it.

We spent two days training architects and tech leads and never gave them a definition of architecture. That was deliberate. There is no settled definition, and that is a large part of why architecture frameworks travel so badly from one organisation to the next.

The first group had not worked through what architecture means in their own context yet. So we started from the significant decisions that shape a system, put that system in its sociotechnical context, and looked at why behaviour matters when you design systems.

We spent two days training architects and tech leads and never gave them a definition of architecture. That was deliberate. There is no settled definition, and that is a large part of why architecture frameworks travel so badly from one organisation to the next.

There's a tension in every design session I facilitate that I don't think can be resolved, only held. >(A thread)<

The other half is reading when the not knowing has done its work, when something new is starting to form, and closing there. That balance is a skill and it gets better with practice. Anyone can pick it up. What doesn't work is assuming someone will.

There's a tension in every design session I facilitate that I don't think can be resolved, only held. >(A thread)<

This isn't only a software thing. There's decent psychology on why people reach for an early answer under uncertainty, and on how the first example you see constrains everything after. Different fields, same pull.

There's a tension in every design session I facilitate that I don't think can be resolved, only held. >(A thread)<

A group starts modelling. Twenty minutes in, someone asks whether this is a domain or a bounded context. Reasonable question, and also the moment the room stops looking at the problem. They're reaching for something solid because not knowing is unpleasant.