Platform Engineering for Business Folks
Know if you're losing time to friction in the AI Era? A platform can solve that!
TLDR
- Are your product engineers are spending way too much time on infrastructure, pipelines, and tooling instead of shipping features? Platform Engineering can solve that!
- A good platform $=$ a force multiplier: unified DX, faster shipping, happier engineers, lower costs
- AI initiatives need this backbone – without it, teams may reinvent the wheel a dozen times
- Talk to engineers and use DORA & SPACE metrics as diagnostic vitals (not optimization targets) to identify pain points that you can solve for multiple teams with an Internal Developer Platform (IDP)
> kanomeister :enter
In commercial, product engineering with velocity requires building and shipping systems aligned with solving business problems. Simple problem statement, right? You would expect your engineers to focus solely on that.
Wrong!
For product engineers to do that, they often need to set up and manage:
- robust infrastructure and product environments, including managing configurations and secrets, to avoid them having to babysit it
- automated test / QA / verification pipelines, to avoid them having to hand-test everything
- observability and telemetry, to know when something is broken and learn how a product is doing
- CI/CD pipelines, to avoid them having to bundle and release products by hand
- documentation and Jira traceability, to help them convey to you what they’ve been doing for your roadmap sprint-over-sprint
… and more!
Often, these are problems that the business-side may not recognize as part of their problem too… without a smooth communicator! “Why are you working on that? How is this valuable for shipping the roadmap?”
In larger orgs, dozens of product teams used to reinvent the wheel in these areas multiple times, requiring loads more engineers to focus solely on maintaining that backbone stack.
Even with multiple unique environments and requirements: there are often common tools, patterns, and practices that engineers don’t even know another product team has already solved, which would’ve saved them a lot of hassle. Or they have complex compliance and finance requirements that make even standing up environments a surprisingly time-consuming process! And so on…
And who gets the most frustrated over poor tooling, processes, and systems that slow down building and shipping stuff? Engineers!
Platform engineering is the means by which engineers can bundle common patterns and tooling into a robust self-service developer platform that minimizes that friction. Treated like a product line of its own, this platform’s customers are internal engineering teams (including itself).
And the platform – which can be continuously improved upon – unifies and improves the developer experience (or DX) for all of engineering, ultimately enabling product teams to save costs and ship features more reliably and quickly… because happy engineers like to ship products. Who would have thought?
A good platform has proven to be a critical force multiplier for product teams in all modern startups, scaleups, and established tech companies that stay on the industry’s leading edge… at least, according to every leader I’ve spoken to!
And I haven’t even touched on the whole AI initiative yet!
The AI backbone
Every business leader I talk to is being asked “what’s our AI strategy?” – and the answer almost always involves engineers building something. The problem? AI initiatives without solid platform engineering tend to stumble hard.
Your data science team wants to deploy a recommendation model. Without the platform, they need to provision infrastructure, set up a deployment pipeline, configure monitoring, wrangle secrets and credentials… all that before they can even test whether the model is any good. That is the kind of invisible friction that kills AI momentum!
The platform is a perfect backbone inlet for AI & MLOps tools – not just for LLM-based agentic workflows that change how you do work, but for hard machine learning too. Think computer vision annotation & automated train/test pipelines, letting ML engineers iterate faster on the models that power things like AI-assisted code reviews, automated quality checks, intelligent deployment validation, and internal copilot tools.
Without the backbone, every AI initiative risks reinventing the same infra wheel. Why not ensure your teams can plug in and go?
So, where do you start?
Great question! Luckily, you’re not alone.
The leading edge of tech has been honed on it, so you don’t have to guess where to start. There are proven frameworks for taking the temperature of your engineering health – not as targets to obsess over, but as diagnostic indicators. Think of them like a doctor checking vitals: they tell you where to look deeper, not what to prescribe.
Doctors also do a (usually) great job interrogating their patients, which means you should combine that with a great job asking your engineers and team leaders what pain points they’re running into. If you yourself haven’t experienced the pains of high-velocity or enterprise-scale software development, this step is especially important! Don’t shape the questions to be directive of course, but don’t be afraid to ask questions either.
There’s no one clear “bucket” your org may fall into, so I hope you can take this context as a diagnostic toolset to spawn enough “what-if”s and “how-do-we”s to get your best engineers and product folks on solving them… especially since they’ll get to move faster and feel happier once those are solved.
Larger commercial orgs have also needed to try and capture the difficult-to-quantify impact of DX, to convince some inquisitive business folks further of the platform engineering value proposition. To that end, they’ve landed on or near two major frameworks:
- DORA: a set of metrics capturing engineering velocity and reliability, coined by Google’s DevOps Research and Assessment research team.1
- SPACE: a framework aimed at capturing developer productivity, minted by GitHub & Microsoft Research; covering Satisfaction & Well-Being, Performance, Activity, Communication & Collaboration, and Efficiency & Flow.2
(DORA’s velocity and reliability metrics map onto the Performance and Efficiency dimensions of SPACE.)
These frameworks provide an excellent collection of statistics by which you can assess a more objective temperature of how your engineers are shipping. Doing that with ear-to-ground feedback loops should quickly give you an idea of where your current faults or inefficiencies lie.
Deployment frequency or change lead time are slow? Pick apart your process from work item to release version and deployment to identify the hold-up.
Change failure rate is high (i.e. new releases often have bugs caused by work items)? Examine your code review, testing, and QA processes to see what’s missing.
You will find that solutions to these often go hand-in-hand! If you flesh out and automate parts of these, you will observe natural improvements across metrics. For example: automated tests and AI-assisted code reviews mean higher-quality changes are made and merged faster, which also means releases containing those changes can happen faster and break less.
Couple that with clean tooling integrations for tracking and completing work items, and you can get very traceable insights into what’s working well versus what’s getting stuck: a continuous improvement process for your processes!
Tying it together
Platform engineering has proven for many tech companies to be a force multiplier that your teams, initiatives, and future growth can plug into:
- Netflix: technical post that solved a core data issue for multiple teams by introducing a unified solution
- Pinterest: long read covering 10 years of platform evolution in Pinterest’s engineering org by David Liu, Senior Director of Eng @ ML Platform
- Google: a friendly introduction to the pivotal role the Developer Platform team plays in enhancing cross-org partnerships and strategy, with a “shift down” approach to embedding platform decisions and responsibilities to Internal Developer Platforms (IDPs)
The platform is to your engineers what good infrastructure is to a city: invisible when it works, catastrophic when it doesn’t, and an endless spiral of headaches and bumps and potholes when it sits somewhere in-between.
Getting into it? Start small. Find the areas that hurt the most, trace the problems, solve them once for everyone, and then build on top of that from there. The investment pays for itself the moment your engineers stop being sad about friction and start shipping the things that matter to your customers more quickly and with better reliability.
And if you’re staring down the Babylonian task of spawning fast-moving AI initiatives without robust foundations in these roots? You’ll learn very quickly why starting without them is a terrible, terrible idea.
Just ask your tech fellows where to start – or ask me! Always happy to talk through your specific context and learn more.
In the future, I will expand on this by writing about a practical example of an AI initiative in an enterprise organization I have experienced – along with the challenges that have appeared in solving that.