Posts

This post is part of the Content Club, organized by Bryan Ross. The theme for February 2025 is “Team Topologies in the Real World”. Links to other posts in this group are at the end of this post. I consider myself a big fan of the book Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais. It’s up there with the classic “Gang of Four” book1 for me in that it’s a book that fundamentally transforms how you see the work that you’re already doing. I first read Team Topologies as a newish engineering manager, and came away from the book with both a new perspective on how work happens within an organization, as well as a new language and terminology that I could use to talk about it. I read Team Topologies again around the time I was leaving engineering management for a principal IC2 role focused on building a new data platform, and again found it invaluable in helping me think through how value is created within, or by, a “platform team”. ...

For the last eight years I’ve set myself a reading goal of twelve books a year. I started this practice the year after I dropped out of a humanities graduate program - I was a voracious reader as a kid, and was reading a ton in graduate school, and then I left graduate school and found that my reading just sort of … stopped. So I started tracking what I was reading, and started setting an annual reading goal, in the hopes of keeping up the habit. ...

As an undergraduate linguistics major in New Mexico, I was exposed to not only the languages of present-day America but also to lots of indigenous scholarship and writing on those languages. Some of the most eye-opening, “aha” moments of my college career came from those classes. I remember reading an essay by (I think1) Vine Deloria Jr in which he asked why his being a native speaker of his language seemed to have no value, while a white academic could spend a year in his community doing fieldwork, learn that same language (incompletely!), and turn that knowledge into tenure or a published book. ...

During KubeCon week last week I wrote and published four blog posts. If you count this one, written and published on the following Monday, I’ve published five blog posts in seven days (Tuesday through Monday). Now, while there’s nothing particularly impressive about that (none of the posts are particularly long, and none are particularly in-depth), for me, it’s a huge accomplishment. As I mentioned in my first post last week, I’ve been fighting writer’s block for months. Or rather, while I’ve been writing (some), I’ve been fighting “publisher’s block” - clicking “publish” on an email newsletter, knowing that doing so will “push” my writing into the inboxes of friends, family, professional colleagues, and interested parties, is tough. It feels signficant, and makes me want to hold off publishing until I have something more substantial to say, or until I’ve added more references, or until I have read another book on the subject, or until I’ve whatever elsed that isn’t actually publishing. ...

Yesterday I attended a KubeCon panel that ended up being one of my favorite KubeCon sessions of the week: “Platform Engineering In Financial Institutions: The Practicioner Panel”. Moderated by Paula Kennedy (Syntasso), with panelists Chris Plank (NatWest Bank), Suhail Patel (Monzo), Jinhong Brejnholt (Saxo Bank), and Rachael Wonnacott (Fidelity International), the discussion went deep into establishing and sustaining a platform engineering practice in a highly-regulated industry. I enjoyed the panel very much. I wish it had been longer, even - there was so much good discussion happening that it went over its alloted time. The whole panel was interesting, but at the end it got extra-interesting for me, because the conversation started to pivot to the impact of all those regulations and whether they could be a good thing. ...

The idea of treating engineering platforms as products has been getting a lot of traction recently. We’re thinking in terms of “platform-as-a-product”, we’re doing user research and user interviews, we’re hiring platform product managers, we’re doing A/B testing on platform capabilities. This is good, valuable work, and I support it. But more and more I feel like there’s a sort of chicken-and-egg problem here. Hiring a platform product manager isn’t the first step of building a platform. It can’t be the first thing, because it can’t happen unless there has been prior work to demonstrate the value of having a platform product manager - there is a “get buy-in” step that precedes it. ...

I’m at KubeCon/CloudNativeCon NA this week, and attended the co-located Platform Engineering Day event yesterday. One of the talks there was given by my friend Atulpriya Sharma (GitHub: @techmaharaj), on the topic “Are you really ready to adopt a platform?” (materials are here - thank you Atul for making these available). In his talk, Atul provided a questionnaire and scorecard that an organization could use to self-assess their “platform engineering readiness” prior to or during an initial investment in a platform engineering function. One of the questions in the list was about the incident response process in the organization, and the inclusion of that question (of an incident response question in a platform engineering checklist) really got me thinking. I pivot here from Atul’s talk to my own opinions (I also live-skeeted some of these thoughts). ...

I posted a “Hello World” on this blog eighteen months ago (almost exactly). I’m finally ready to post a sequel. “Write more” and “write in public” have been goals of mine for a long time. I’ve tinkered with my blog, I’ve thought about writing, I’ve done a lot of work except for the kind of work that matters, which is actually write and publish. This post is me taking a concrete step in the right direction. I am writing, and I am publishing. ...

Hello, world! More to come here shortly, stay tuned.