# Staff Engineer without a manual

By Valentin Galfré · Published 2026-09-09 · 4 min read · https://galfrevn.com/writing/staff-engineer-without-a-manual

> Nobody in a startup tells you what a Staff Engineer does. How I defined the role: platform, AI, vendor decisions, and the hard conversations nobody else wanted.

In September 2025 I became Staff Engineer at Coderhouse. Nobody handed me a document explaining what that meant. In a startup, even one that went through Y Combinator and now teaches half a million students, the title arrives before the job description, and you are the one who has to write it.

This is the one I wrote. It is not a definition of the role. It is what mine turned out to be, and why.

## The title is a question

At a big company, Staff comes with a ladder, a rubric and a dozen people who already hold it. You can copy them. At a startup, the title is closer to a question the company is asking you: we trust you with the technical shape of this thing, what are you going to do with that?

The wrong answer is to keep doing what got you promoted, only more of it. I was a good senior engineer because I shipped well. Shipping well is still expected. It is no longer the point.

The right answer, I think, is to find the decisions nobody owns and own them.

## What nobody owned

When I looked around, four things had no owner.

**The platform.** Infrastructure that had grown with the product and now had to hold tens of thousands of concurrent students without anyone having sat down to design for that. Somebody had to make that a deliberate system instead of an accumulated one.

**The AI work.** An edtech that produces content at scale is exactly the place where generative models either earn their keep or become an expensive toy. Someone had to decide which, project by project, with a bar higher than "it is impressive".

**Vendor decisions.** Every service the company pays for is a dependency with a cost of exit. Those decisions were being made one at a time, by whoever needed the thing that week. They needed a framework and a person who says no.

**Standards.** How we write code, how we review it, what a service needs before it goes to production. These existed as habits of individual teams, and habits do not survive a reorg.

So that became the job: platform, AI, vendors, standards. Not because a document said so. Because they were lying on the floor.

## Less code than you would think

The honest surprise was how little of the week is spent with an editor open. Most of it is conversations, and most of those are the ones nobody else wants to have.

Telling a team their architecture will not survive next year's growth. Telling a founder the AI feature they are excited about does not earn its place yet. Telling a vendor we are leaving. Telling an engineer their pull request is technically fine and still wrong for the codebase.

I used to think the technical part was the hard part. The technical part is the part I am confident in. The hard part is saying the true thing clearly, early, and in a way that lets the other person keep their footing.

> **Rule.** If a conversation is uncomfortable and nobody is having it, it is now your conversation.

## Vendors, chosen like code

I evaluate a vendor the way I evaluate a dependency in a codebase. What does it do that we could not do in a week? What does it cost, in money and in the shape it forces on our system? How do we leave, and what does leaving cost? Who else depends on it going well?

Build, buy or kill. Most of the interesting decisions were kill: things the company paid for out of inertia, that nobody would have chosen again. Saying no to a new tool is easy. Saying no to one that already has a login is the part that needs a Staff Engineer, because nobody below that level has the standing, and nobody above it has the context.

## Standards that get adopted

I did not write a standards document. I wrote very few things down at all. What I did was review a lot of code, always the same way, about the same things, until the things became normal.

Names that say what they mean. No comments explaining what better code would have made obvious. Precise types at the boundary and trust inside. Services that expose their health before they expose their features. Reviewing for those consistently, across teams, is what made them organization-wide. A document would have made them a document.

## What I would tell the next one

If you get a Staff title without a manual, do not wait for the manual. Look for the decisions on the floor and pick them up. Expect the week to be mostly conversations, and expect the uncomfortable ones to be yours. Treat every vendor like a dependency and every review like a lesson.

> The role is not a set of responsibilities. It is the habit of noticing what has no owner, and becoming the owner before someone gets hurt.