LeadTime#20 - Building a Platform Team
How to transition from feature development to platform engineering? What questions discover developer needs and business goals, while forming a high performing team from multiple sources?
Hi, this newsletter is a weekly challenge for engineers thinking about management. I'm Péter Szász, writing about Engineering Leadership and training aspiring and first-time managers on this path.
In this newsletter, I pose a weekly EM challenge and leave it as a puzzle for you to think about before the next issue, where I share my thoughts on it.
Last Week’s Challenge
Last week, I described a situation where you, as the Engineering Manager of a product development team, are tasked with forming an internal platform team from your current developers, plus people from other teams, with a three-month deadline to take ownership of shared services and tooling. Read all the details here if you missed it.
I'll approach this situation with my usual goals-risks-questions structure:
Goals to Achieve
Execution: Get clarity on the platform team's mandate and scope. This is where assumptions can cause misalignment, which usually takes a long time to discover. I need to understand exactly why we're creating this team, what parts of the tech stack we're taking over, what autonomy we have in build-versus-buy decisions, and what ongoing projects need immediate attention.
As the Domain Lead for Platform Engineering at Dashlane, one of the most impactful changes we introduced was treating platform engineering as product work. Our customers are the developers around us, and we use lean product development to iterate quickly toward the best solutions for them. This means discovery, experimentation, and evangelization throughout the organization.
Team: Form a team with a distinct identity, purpose, and principles. Social Contracting can be a good tool to achieve that. Without focusing on this, there's a risk that the original team will operate as a subgroup, excluding newcomers.
Personal: Support everyone through this transition. People staying on my team have to be okay with leaving feature work behind. People joining from other teams need proper handover from their previous managers: I need visibility into their career goals, performance history, and motivations to manage them effectively.
Risks to Avoid
Making assumptions about scope and expectations: Everyone has different ideas about what platform engineering means. Miscalculating what we're taking over, or basing decisions on wrong assumptions, can lead to misaligned development and frustrated stakeholders, even risking the whole Platform Engineering initiative.
Not operating like a product team: The biggest risk is working on the wrong problems, even building solutions nobody asked for. Experienced engineers often think they know not just the answers, but the questions too. For example, we could spend months building a unified local dev environment because the centralized support aspect might sound great for a senior engineer, while developers are enjoying and relying on their current freedom and don't see this as a problem that holds them back in their work.
Working in silos: Platform engineering success depends on problem discovery and constant communication about our direction. We need early feedback on ideas before we build them, and ongoing evangelization so adoption isn't starting from scratch.
Scope creep: When there's delivery pressure, platform teams might receive random feature work because "you're capable developers." This hurts our roadmap, demoralizes the team, and signals that our work isn't important enough to protect. The product-focused approach I described above can also help push back against these attempts.
5 Questions
Why did the organization create a Platform Team? What exactly is our mandate, and how does our work tie to business goals? I need concrete answers about the problem we’re trying to solve, the technical scope, process expectations, and decision-making authority. Platform engineering is a cost center - companies can survive without us longer than without feature teams. We must clearly show how we contribute through quality improvements, faster feedback cycles, better onboarding, organizational efficiency, or developer experience.
What success metrics will define our impact? By the end of three months, we need agreed-upon engineering metrics that we'll work on positively impacting. Maybe DORA metrics, maybe developer experience metrics, maybe both, maybe something else. (See the inspirational quote at the end of the article to get some ideas.) This alignment with leadership is crucial — it's how our work gets fairly judged and how we push back against random feature development requests. Without clear metrics, we're just a team that "enables developers" with no way to prove value.
Who's in my team now, and how do I make sure everyone collaborates effectively and efficiently? I need the previous managers' assessments, career aspirations, and performance history of incoming members. I need to reassess the remaining members’ goals and their place in the new team. Finally, what activities can ensure we function as one team instead of the original members plus newcomers? This is important both for psychological safety and collaboration.
What's the current developer experience, and where are the real pain points? This is product discovery work. What are developers struggling with? What works well? How do we compare to similar organizations? I'd start with developer experience surveys and benchmarks rather than assuming I know what needs fixing. Then we can have facilitated group exercises like Value Stream Mapping to discover all aspects of the software development lifecycle and its current pain points.
What quick wins can we tackle immediately? Low-hanging fruits serve multiple purposes: show progress to leadership and the organization, motivate the team by showing purpose, and give us practice with our new technical scope. It could be speeding up builds, automating a tedious task, or addressing some CI/CD issues. Even if it doesn't follow perfect product discovery, early wins can give a great boost of momentum and credibility to our work.
The core challenge isn't choosing the right tools or processes — it's transforming from individuals with improvement ideas to a team that discovers what developers need and solves the most impactful problems.
Did I miss any important considerations for this transition? Have you handled forming platform teams from mixed groups before? Let me know how it went in the comments!
This Week’s Challenge
You're managing a team of 7 developers when Sarah, a Staff Engineer with 12 years of experience, joins from another part of the company. Her previous team was disbanded during recent layoffs, but she was kept and reassigned to your team. She's technically brilliant, works fast, and has deep expertise that your current work doesn't really require.
Three weeks in, Sarah is clearly bored. She's onboarded to the new scope fast, and now finishing tasks in half the expected time and has started proposing solutions to problems that are not burning yet. Her frustration is becoming visible during standups, and you suspect she's already answering LinkedIn messages from recruiters.
Your roadmap for the next six months has no major technical challenges, and the business is happy with current performance. You need to keep Sarah engaged, but you're worried about losing her to a more stimulating role elsewhere.
What do you do?
Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers as soon as they are published:
Until then, here's a small piece of inspiration related to this week’s challenge:
See you next week,
Péter