Your First Ninety Days
Learn first. Then ship one small thing that obviously works. Then change the system.
The template
Your First Ninety Days
You arrived at a team with none of this. Every instinct says start with the design system, or the org chart, or a quality bar. Do not. Ninety days, three phases, and the sequencing matters more than the content, because the first thirty days buy you the right to do the next sixty.
The one rule for day one
Do not announce a new way of working in month one. You do not yet know what the existing rituals protect, and killing something that was load-bearing is the fastest way to spend credibility you have not earned.
Learn first. Then ship one small thing that obviously works. Then change the system.
Days 1 to 30: Find the real constraint
Goal: know what is actually broken, in the team's own words, and have shipped one visible improvement.
What to do
Grade thirty outputs yourself, in week one. Before meeting anyone about quality. Your independent read is a baseline you will never be able to get again once you have absorbed the team's opinions.
Ask every designer three questions. What decision are you least sure about? What gets argued about repeatedly? What do you do that feels like theater?
The third question produces your kill list, and people answer it honestly in week one in a way they will not in month six.
Sit in every recurring meeting once. Note which ones produce a decision and which produce a receipt.
Find out who actually decides quality. Not who is supposed to. Ask three people, and if you get three answers, that is your first finding.
Read the last quarter of shipped work against nothing. No rubric yet. Just form your own view of where the floor is.
What to ship by day 30
One wrong-path improvement on a real surface. Small, visible, obviously better. Recovery copy, a missing undo, an empty state that teaches.
Why this specifically: it is uncontested territory, it demonstrates the thing you are going to spend ninety days arguing for, and nobody has to give up anything for it to happen.
What not to do
No reorg. No design system audit. No principles workshop. No "here is how I like to work" deck.
Days 31 to 60: Write the first constraints
Goal: one surface has a written constraint set and a calibrated rubric, and the team has seen it work.
What to do
Pick one surface. The one with the most quality argument and the least political weight. Not the flagship, and not the backwater.
Run a failure inventory on it. Ninety minutes, three people, including somebody from support. This meeting converts more skeptics than any explanation will, because the list is uncomfortable and everybody in the room helped write it.
Write three constraints from that inventory. With failure conditions. Put them in the ticket, not in a doc.
Extract a rubric from your day-one grading. You already did the hard part in week one. Dimensions, cost test, binary tests.
Calibrate it with one other person. Five outputs, independent scores, classify the disagreements. Expect the rubric to be vaguer than you thought. Say so publicly when it happens, because that is what makes it a shared tool rather than your tool.
Run one rubric review. Thirty minutes, the protocol, one decision at the end.
The first fight
It happens here, and it is always some version of: this slows us down.
The honest answer is that it front-loads work that was previously happening at the end, during review, as rework. Do not argue it in the abstract. Point at the last two things that shipped and got reworked, and ask where in the process the problem was actually found.
What to ship by day 60
The constraint set, the rubric, and one review that produced a decision the team agreed with. Small surface. Real artifacts.
Days 61 to 90: Make it the default
Goal: the practice runs on more than one surface and does not require you in the room.
What to do
Extend to two more surfaces, owned by other people. You facilitate the first inventory, someone else facilitates the second. If it only works when you run it, you have built a dependency, not a practice.
Put the cadence on the calendar. Weekly rubric review, Friday constraint check. Named owners, recurring slots.
Kill one ritual. Now you have earned it, and now you know what it protected. Ship the replacement first, run both for two weeks, and state the bring-back condition when you announce it.
Have the ownership conversation. With your PM and engineering counterparts. The three contested boundaries: who decides when output is good enough, who owns the prompt, who owns the failure states. Get names on all three.
Write the ninety-day note. One page to your manager: what you found, what you changed, what the numbers are, what you are doing next quarter. Include the coverage number, which is how many surfaces have a current constraint set.
The second fight
Usually about ownership, and usually with a well-meaning PM or engineering lead who has been making quality calls in the absence of anyone else doing it. They are not the problem, they filled a vacuum. Say that out loud, and the conversation goes differently.
The ninety-day scorecard
| By day 90 | Yes / No |
|---|---|
| Three surfaces have written constraint sets | |
| One calibrated rubric, used in a real review | |
| The rubric review happens without you facilitating | |
| One ritual killed, replacement running | |
| Three ownership boundaries have names on them | |
| One wrong-path improvement shipped and visible | |
| Coverage number known and reported |
Five or more is a good quarter. Seven means you moved fast and should check that the team came with you.
The one thing to do in week one
Grade thirty outputs alone, before you talk to anybody about quality. It takes an afternoon, it is the only unbiased read you will ever have of this product, and every artifact you build in the next ninety days comes out of it.
From "Your First Ninety Days", chapter 25 of The Design Operating Model. falkster.com/design/your-first-ninety-days