Platform teams shouldn't predict the future but observe the present.
When multiple teams build similar solutions, commoditize the pattern. Make it the default, keep escape hatches.
Good ideas spread upwards through platforms, not downwards through rules and mandates.
Teams anchored to solutions defend them even when their context changes. Teams anchored to problems evolve.
'We manage Jenkins' (rigidity)
'We enable continuous delivery' (adaptability)
When your identity is the solution, you protect it. When it's the problem, you solve it.
Internal platforms aren't infrastructure tools. They're organizational memory. Each capability encodes a problem multiple teams already solved. Platform teams aren't only service providers, but curators of collective learning.
My latest YouTube short for the Modern Software Engineering channel, "Does Your Software Development Prioritize Business?": www.youtube.com/watch?v=cRut...
Don't focus on engineering prompts, focus on engineering context instead.
"[...] as applications grow more complex, it’s becoming clear that providing complete and structured context to the AI is far more important than any magic wording.
blog.langchain.com/the-rise-of-...
I remember Adrian Colyer publishing a post about David Parnas’s work in the context of modern microservice architectures a few years ago. Unfortunately, his blog is no longer online, but thanks to the Wayback Machine, I was able to dig it up.
web.archive.org/web/20240424...
I already enjoyed his absolute masterpiece "The Creative Act," (which I highly recommend - get the hardcover, the binding is great) and am very much looking forward to his work on AI and engineering. Check it out here: www.thewayofcode.com
Seriously? How awesome is this? Rick Rubin, the legendary producer of artists like Neil Young, U2, Metallica, Adele, System of a Down (and many more), wrote a book with Anthropic on Vibe Coding!
@hollycummins.com 's discussion in the Engineering Culture podcast about developer productivity reminds me a lot of Cal Newport's notion of "seudo productivity" vs "slow productivity" in his newest book (buff.ly/VBBEZBi)
Btw, give the podcast episode a listen, it's great:
Embedding a deep understanding within organizations about the fact that architecture, organizational structure, and (human) communication are interlinked.
I like how you show services as enablers for team autonomy. I often think of "teams that own them can work independently" as a north star for improving flow, since full independence is hard to reach (there will always be _some_ things stream-aligned teams need to work together on and collaborate).
From the article: "everybody tests in production, whether they admit it or not; good teams are aware of this and build tools to do it safely"
This is actually one of the best-structured arguments for using feature flags that I've seen in a long time: buff.ly/dgOdKlV
Separate deployments (continuously delivering code to production) from releases (switching code "live" for users).
When I vibe code, I often intervene in the process with something like "hey, you might try X instead of Y."
For me, the process of coding with AI is a very active one. Like Pardis said in her post, reviewing code is essential. Use the tools to reason about the code and utilize the gain in iteration speed to actively contrast different approaches to solve the problem.
I myself have experienced accelerated learning, but on a different level. Instead of reasoning about code details, I am able to focus much more on architectural concepts and ideas as well as iterate on them much faster and compare different approaches.
What I found to be particularly interesting is the question about learning: "When I vibe code, especially in a domain I’m not familiar with, am I actually learning anything? This is where I’d recommend reviewing every change before every commit."
Great advice and best practices for AI-assisted coding by @djpardis.com djpardis.com/blog/2025/06...
I myself have experienced accelerated learning, but on a different level. Instead of reasoning about code details, I am able to focus much more on architectural concepts and ideas as well as iterate on them much faster and compare different approaches.
What I found to be particularly interesting is the question about learning: "When I vibe code, especially in a domain I’m not familiar with, am I actually learning anything? This is where I’d recommend reviewing every change before every commit."
Check out the full interview here: www.youtube.com/watch?v=2oq_...
He also mentioned some independent services that have different scaling needs from the platform itself, such as the Copilot API and Actions. This is pragmatic. Use deployment boundaries where they really matter: supporting varying load patterns or improving team independence.
I listened to @gergely.pragmaticengineer.com interview with GitHub's CEO @ashtom.bsky.social today. What amazes me is that GitHub is mostly still a monolithic Ruby on Rails application and that it works so reliably at that scale.
I'm also wondering: what about generated code? Does it have the same effect on teams and their perceived ownership of their (generated) artifacts? Might be an interesting area for research.
While I'm bullish about LLMs and use them widely myself, this issue is something I've been worried about for a long time. Now, some empirical evidence seems to be emerging about this.
arxiv.org/pdf/2506.08872
Synchronous communication in distributed systems is a leaky abstraction. My new article shows how asynchronous design helps in building resilient, decoupled systems. Discover more: www.shapingshifts.com/p/network-co... #SoftwareArchitecture #DistributedSystems
I just published a new article on the dynamics between platform and application teams. Discover how to build platform teams which enable teams instead of becoming a bottleneck. Read the full article here: www.shapingshifts.com/p/designing-...
UnConference "Software-Entwicklung und Menschen - Team-Topologies, sozio-technische Systeme, Conway's Law und mehr"
Montag 2024-02-26 17:30
Kostenlos!
Registrierung: zoom.us/meeting/regi...
Danke an alle, die beim Vortrag von Stefan Toth und mir auf der @OOP Konferenz dabei waren. Wir haben über Herausforderungen im Microservices-Umfeld gesprochen und diskutiert, wie evolutionäre Architektur dabei hilft. 👉 Folien-Download: www.embarc.de/microservice... #oop2024 #OOPMuc