Platform Engineering Staffing, From First Hire to Full Team

Hire the platform lead first, before any additional engineers. That seat sets the charter, decides what the platform will not do, and gives every later hire something concrete to be hired against. We look for a staff-level IC who has built an internal platform before, because the scarce skill is knowing what to leave out in year one. Teams that start with two infrastructure engineers and bring a lead in later almost always burn the first six months undoing architecture decisions that nobody in the room had the authority to make in the first place, which is an expensive way to learn the ordering.

Most teams land between 1 and 2 seats at 20 to 40 developers, 3 to 5 seats at 40 to 100, and 6 to 10 seats past 100 developers. Those are starting bands, not a formula. Complexity moves the number harder than headcount does. At identical developer counts, the gap between a single-cloud shop with one deploy pattern and a company carrying four clouds plus the wreckage of two acquisitions runs to roughly a factor of three in platform headcount. Count your deploy patterns before you count your developers.

Engineering, in most cases, because the platform’s customers are developers and reporting lines follow customers. Under infrastructure, the roadmap tends to drift toward cost and uptime, which are real goals but not the ones that drive adoption. There’s a legitimate exception. Heavily regulated shops where the platform’s main job is enforcing controls often do better under infrastructure or a shared services org. Ask which outcome gets you promoted, then put the team where that outcome lives.

Yes. A platform pod is typically 3 to 5 engineers running 6 to 9 months under a named KORE1 platform lead, sized to stand the function up or restart one that stalled. Pods work best when you need the capability inside a quarter and can’t afford to wait out four sequential direct-hire searches while the developer experience problem you already have gets quietly worse every sprint. Most convert. We build the pod so that one or two seats can go permanent at the end, and the rest hand off with documentation and a running golden path rather than a wiki nobody updated.

Past roughly 60 developers, that seat pays for itself, and before that the lead can usually carry it part time. The job is deciding what the platform builds next based on what developers are actually routing around, then killing the features nobody uses. Skipping it is the single most common reason a portal goes stale. Infrastructure engineers are excellent at shipping capability and, in our experience, much less interested in interviewing the three teams who quietly went back to their own pipelines.

Our average time-to-hire is 17 days per seat, so a three to five person function usually lands over two to four months when the searches run in parallel. Sequential hiring takes longer and it should, since each seat informs the next. Pods move faster. When a client needs the capability inside a quarter, a platform pod puts working engineers on the problem in weeks instead of running four searches back to back and hoping the market cooperates.

Buying the tool before staffing the function. A team stands up Backstage or Port, onboards a couple of services, and then the catalog goes stale because adoption has no owner. Second most common is an interview panel made entirely of infrastructure engineers. They grade on Helm and Kubernetes trivia. The question nobody in that room thinks to ask is how a candidate would measure whether developers actually use the thing, which happens to be the exact question the strongest platform lead on the slate has already answered twice at previous companies. Both failures are fixable at the panel stage. Both are expensive after the offer.