Your platform team has the talent.
But does it have the results?
Almost every large engineering organization has a platform team now. DORA measured what happened next, and found that while individual productivity rose, delivery throughput and change stability both fell.
The approach
Talent is rarely the variable. Attention is.
A platform team can be full of capable engineers and still ship something nobody adopts. Not because anyone did poor work, but because experience trains people to notice certain problems and to walk past others. Over enough decisions, what a team habitually notices becomes what the platform records.
Attention has to begin somewhere. In platform work it begins in a small number of recognizable places. There are priorities people tend to lean towards.
Systems quality & scale
"Will this hold under pressure?"
Instinct toward architecture, maintainability, and technical correctness. Builds for the version of the system that does not exist yet.
Measures success by: elegance, scalability, technical debt reduction
Stability & reliability
"Protect what's running."
Instinct toward risk reduction, incident response, and process consistency. The first question is usually about what could go wrong.
Measures success by: uptime, incident reduction, process adherence
User value & adoption
"Who uses this, and is it working?"
Instinct toward the developer experience. Treats the engineers on the other side of the platform as customers rather than tenants.
Measures success by: usage, adoption, developer feedback
Capability & knowledge transfer
"Can the team function without me?"
Instinct toward documentation, training, and team autonomy. Measures its own success by how rarely it is needed.
Measures success by: team autonomy, documentation quality, knowledge retention
Most platform teams lean hard toward Engineering and Operations. Those two are the easiest to hire for and the easiest to measure. Product and Enablement get deferred, and that is usually where the throughput went.
The lean is not a flaw, it only becomes one when there is a misalignment
How we help
Two ways to work together.
Most technology initiatives do not fail on technology. They fail because the team was never designed to deliver what was being asked of it. Whether you want an experienced practitioner working alongside you or a structured method you can run yourself, that is where the work starts.
Fractional engagement
Fractional Technology Leadership
Senior leadership capacity, without the headcount.
An experienced technology leader working alongside your team to assess where you actually are, name what is blocking you, and help you make the decisions that are hard to reverse. Some engagements are a short diagnostic. Some run alongside a transformation for a year. The shape is set by the problem, not by a package.
Where this tends to help
- Standing up or restructuring a platform engineering function
- Moving AI past pilots and into something the organization runs on
- Scaling an engineering organization past its current ceiling
- Deciding whether the team you have matches the strategy you have been given
- Board and executive conversations that need a technical translator
Self guided
The Field Guide
Run the method yourself, with your own team.
People First, Platform Second. A method for reading how a team actually makes decisions, and for seeing the gap between the team you have and the one your strategy assumes. Written for the leader who suspects something is off but cannot yet name it.
Free during early access
What it gives you
- A way to read a team the way you already read a system
- The four priorities, and what each one protects
- Why strong teams drift, and what the drift costs
- Field exercises you work through rather than read
- New chapters as they are written, before the final cut
Not sure which fits? Start with the field guide. If what it surfaces is bigger than your team can work through on its own, a conversation is the next step.
Background
The work came first.
The framework came later.
Platform strategy and team design for engineering leaders.
About Skylight
Skylight grew out of a pattern that kept appearing across two decades in engineering and technology leadership, inside large enterprises and mission-driven nonprofits. Similar technologies, producing remarkably different platforms.
The difference is usually in the teams behind them. What a team notices, and what it has learned to protect, shapes what gets built long before anyone chooses a tool.
That perspective is the foundation of the field guide, an ongoing effort to give platform leaders language for patterns many of us have experienced but never had a way to describe.
Platform & infrastructure engineering across enterprise and nonprofit
Environments where headcount is hard to win and harder to reverse
Led platform engineering transformations
Containers-as-a-service, cloud-native operating models, DevTools
Work across engineering, product, data, and security boundaries
Technical decisions with organizational consequences
Doctor of Management in Business Administration
Organizational strategy and leadership
Selected speaking & community
Get in touch
Ready to build a better platform team?
Whether you're diagnosing a stall, planning a redesign, or just starting to think about team composition, pick a time that works or send us a message.
Request Submitted.
We'll be in touch soon...
Oops! Something went wrong while submitting the form :(