Week One Is Not About Answers
Every time I join a new program, somebody wants a plan by Friday. A schedule, a risk list, an opinion on the architecture. I understand the instinct. Leadership wants to see that the new person is already pulling weight.
I resist it anyway. The first few weeks are for finding out what is actually true, not for producing something that looks useful. A mission architect who hands out conclusions before understanding why the current design looks the way it does is going to spend the next year walking those conclusions back.
So I spend week one reading. Requirements documents, old trade studies, meeting notes from decisions made two years before I arrived. Half of what I read will turn out to be outdated. That is fine. I need to know what the team believes is true before I can tell them what is actually true.
Find the Scar Tissue
Every program has at least one decision that looks strange from the outside and makes complete sense once you know the history. Maybe a subsystem is over-margined because of a failure on an earlier mission. Maybe a requirement reads oddly because it was negotiated line by line with a customer who is no longer even on the program.
I spend a lot of early time asking people why things are the way they are, not whether they are right. “Why” gets you the scar tissue. “Is this right” gets you a defensive answer, because it sounds like you are grading their work three weeks in.
Once I know where the scars are, I know which parts of the design are load-bearing for reasons that have nothing to do with engineering, and which parts are just habit. Those are very different problems to fix.
Build Trust With Small, Visible Work
Around week three or four, I start doing something small and finishing it completely. A clean trade study on a narrow question. A model that answers one question the team has been arguing about for months without data. Nothing dramatic. The point is not the output, it is proving that I follow through, that my numbers hold up when someone checks them, and that I give credit to the people whose work I built on.
Credibility on a new program is not won with a vision statement. It is won by being right about something small, in public, early.
Map the Actual Decision Makers
Org charts lie. By week six I usually know who the chart says has authority and who the room actually defers to when a hard call comes up. Sometimes it is the same person. Often it is a systems engineer three levels down who has been on the program since its inception and whose judgment everyone trusts without saying so out loud.
I need to know who that person is before I propose anything that touches their part of the design. Not to get permission. To make sure I am not about to contradict years of lived experience with a model that has not been stress tested yet.
The First Real Opinion
Somewhere around day sixty, I start forming an actual point of view on where the program is strong and where it is fragile. Not before that. An opinion formed in week two is usually just a reaction to whatever was loudest in the first meeting.
I try to write that opinion down even if nobody asked for it yet. Not to send around. Just to have it on paper, dated, so that when I do raise it later I can be honest with myself about whether new information changed my mind or whether I am just repeating what I believed on day four.
By Day Ninety
By the end of the first ninety days, I expect to know three things cold: where the real risk in the architecture lives, who needs to be in the room when that risk gets discussed, and which of my own early assumptions turned out to be wrong.
That last one matters more than people think. If nothing I believed on day one got corrected by day ninety, I was not paying close enough attention. The job of those first three months is not to arrive with the right answer. It is to arrive, slowly, at the right questions, and to have earned enough trust along the way that people actually want to hear them.