I was recently helping a client plan out a new platform capability - a new core capability to replace 3+ existing implementations across their various products.

We used a thinking model I'm calling Platform Capability Mapping, and it ended up worked quite nicely

🧵... We start by identifying the Consumers - which systems would use this new capability. Pretty much any platform capability is going to have multiple consumers. These are the customers for your internal product.

If you allow every product delivery team to choose which type of bolt they want to use, you might end up with half the teams using hex heads and half using phillips.

This means that now every infrastructure engineer has to carry a set of screwdrivers AND a set of allen keys. 😟 Giving delivery teams autonomy is great and all, but there exist a set of decisions which:
a) don't really impact a single team either way, but
b) have non-trivial repercussions in the aggregate

There's leverage in replacing these decisions with one standard approach.

The most common feature-flagging pain I hear of is "feature flag debt" - stale flags clogging up your codebase with conditionals and dead code.

Uber just open-sourced Piranha, an internal tool for detecting and cleaning up stale feature flags.

Let's talk about it a bit... Piranha is a tool specifically for managing feature flag debt in Uber's mobile apps: eng.uber.com/piranha/

They also have a really interesting academic paper describing it, along with lots of interesting details on feature flagging @ Uber in general: manu.sridharan.net/files/ICSE20-S…

I’ve noticed that high-performance engineering orgs have a clear preference towards deep-stack product delivery teams. Teams oriented around areas of a product, rather than around tech lines.

But where do you draw these team boundaries? I’ll list a few patterns I’ve seen... 1/ Lifecycle Teams

Different delivery teams focus on different stages of the user's lifecycle within the product.

For example, an e-comm site might have teams focused on different phases of the shopping experience, from browsing through to purchase and delivery.

I've had a few conversations recently where people see a Service Mesh sidecar/library (e.g. Istio) as some sort of general alternative to a Service Chassis.

That seems misguided - there are a lot of cross-cutting concerns that a service mesh *won't* provide. For example: 1) configuration - How does your service discover general configuration values, as well as updates to those values

After 19 years of writing automated tests in a bunch of tech stacks I have developed an opinion or two on what makes a good test runner.

What would my ideal test runner look like? Here's a list of features.

🧵"Strap in", as the kids say. 1) Tagging: an extensible way to annotate tests with metadata. This allows external tooling to implement features like quarantining (with expiration dates), marking a subset of tests as running before commit, and so on.