Mcp Challenges Atomic Habits Platform Teams Vs Central Teams And Accelerate Capabilities
Hey, Luca here, welcome to a new edition of Refactoring! Every week you get:
Here are the latest editions you may have missed:
To access all our articles, library, and community, subscribe to the paid version: MCP challenges, atomic habits, platform teams vs central teams, and Accelerate capabilities💡Monday Ideas — Edition #161
1) Does MCP address AI API challenges? 📈This idea is brought to you by today’s sponsor — Postman! Last week we published a long piece on how LLMs are changing how we design APIs. MCP is obviously trying to address this, but how much does it really help? To be fair, it tackles some of the challenges:
But it doesn’t address others:
To me, this is largely ok, because 1) it is unclear whether the scope of MCP should include all or any of these, and 2) at this stage it’s more important to converge on a standard than to design a perfect standard. We explored more ideas about AI-first APIs in the full article 👇  Also, Postman recently launched an MCP catalog, making it easier for developers to find and share MCP servers. They also debuted their own MCP generator, to easily create MCP servers. 2) Atomic Habits Video! 📙Our book reviews have always been among the most popular Refactoring articles (check out our latest one, on The Manager’s Path!), so I just tried to do something new by turning one into a Youtube video! I picked Atomic Habits, because 1) it is one of my favorite books, and 2) I believe it is useful to just about everyone, regardless of their job. Here is the video 👇  You can also find the full newsletter article below 👇 3) 🧱 Platform teams should never lose sight of their customersEarlier this year Camille Fournier published a full article on Refactoring on how to create good platform engineering teams. She wrote at length about how platform teams are fundamentally different from the classic central teams, and one of the core differences is that central teams often lose sight of their customers. Instead of thinking about the people who use their systems as their customers, they view them as those clueless application engineers who just don’t get it. They don’t read the docs, they don’t know how to use systems in the right way, they don’t want to try the new stuff and give feedback on it. Treating your customers as an inconvenience to be managed is one of the main contributors to the bad reputation of central teams. We need to view our platforms as products not just because we want them to be thoughtful abstractions that are easy to use but also because we want to make sure that we are building things that the customer actually wants and needs. Your team will have lots of good ideas for products you could be building, but in order for those products to be successful they need to be evaluated for product market fit: will the application engineers at your company actually use this thing once you build it? You can make something that seems great on paper, with easy onboarding, great docs, and widespread customer awareness, but still get no adoption because it just doesn’t meet a pressing need for the application teams.
This is more than just hiring some product managers, making a product roadmap, setting some adoption metrics, and calling it a day. Your whole platform team needs to develop customer empathy and connections with customer teams who can give you feedback on what is important to them and where their pain points lie. Your best products may even come from application teams who have built something useful for themselves that turns out to be something you could expand for the rest of the company. You can find the full article by Camille below 👇 4) 📊 Accelerate is more than DORAAsk anyone about Accelerate, and chances are they will mention the DORA metrics. These four KPIs define how teams can measure their software delivery performance, and became instantly famous:
One of the reasons why the metrics caught on is because they provided, for the first time, a research-backed way to evaluate software delivery across two dimensions:
But here’s the thing: if you think Accelerate is only about metrics, you're missing 90% of the picture. The core of Accelerate is not the metrics: it's the engine that enables them. The book meticulously identifies and validates 24 key capabilities that have been statistically shown to improve software delivery performance. The metrics are the outcome, while the capabilities are the drivers. And the research proves this connection with extreme rigor. It moves the conversation from "what good looks like" to "what specific actions demonstrably lead to good. With some degree of simplification, we can organize these capabilities into three buckets: cultural, process, and technical.
These buckets work as levels of a pyramid, each one supporting the health of the ones above:
We reviewed Accelerate in our book club two months ago, and we reviewed all the 24 capabilities in our full book review 👇 And that’s it for today! If you are finding this newsletter valuable, consider doing any of these: 1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here. 2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇 If you have any comments or feedback, just respond to this email! I wish you a great week! ☀️
|
