Portfolio and the First Ninety Days

The idea in one minute#

Engineers show code. Architects have to show judgement, and judgement is only visible in writing: the problem you chose, the options you rejected, the number you committed to, and what you learned when reality disagreed.

A portfolio for this role is therefore small and unusual: one complete case taken from problem to evaluated prototype, documented with the artefacts of this course, plus one or two shorter pieces that show range. It should take a reviewer fifteen minutes to see that you can do the job.

Getting the job is the midpoint. The first ninety days decide whether you become the person teams bring problems to or the person they route around. The plan is the same in every organisation: listen for thirty days, deliver something small in the next thirty, and set the standard in the last thirty.

A picture#

flowchart LR
  subgraph PF["Portfolio — judgement made visible"]
    direction TB
    P1[":i-file-text: <b>One full case</b><br/><small>problem → design → cost → evaluated prototype</small>"]
    P2[":i-git-branch: <b>Decision records</b><br/><small>options rejected, and why</small>"]
    P3[":i-coins: <b>A cost model</b><br/><small>with sensitivity</small>"]
    P4[":i-flask-conical: <b>An evaluation</b><br/><small>cases, results, failures read</small>"]
  end
  PF --> J[":i-building-2: <b>The job</b>"]
  J --> D1[":i-search: <b>Days 1–30</b><br/><small>listen, map, inventory</small>"]
  D1 --> D2[":i-zap: <b>Days 31–60</b><br/><small>one small thing shipped</small>"]
  D2 --> D3[":i-list-checks: <b>Days 61–90</b><br/><small>standards, roadmap, review cadence</small>"]
  class P1,P2,P3,P4 compute
  class J neutral
  class D1 queue
  class D2 io
  class D3 memory

How it really works#

The one full case#

Choose a real problem — from your job, a small business you know, a public dataset, an open source project. Real beats impressive: a dull problem with real constraints shows more than a glamorous one without them. Then produce these seven pieces.

End with a half-page retrospective: what you would change, and what you still do not know. That page is the most persuasive one in the portfolio.

Shorter pieces that show range#

Pick two.

• A teardown. Take a public AI product or a published reference architecture and review it against the six pillars. What is strong, what would you ask about?
• A cost investigation. “What does it actually cost to run X at 10,000 users?” with the arithmetic shown.
• A migration note. Move a small system from one model to another, guided by an evaluation set; report what changed.
• A comparison. The same task on a small, a mid and a frontier model, with quality, cost and latency measured.
• A regulation walkthrough. Classify five use cases under the EU AI Act with reasons.
• A “we should not build this” memo. A persuasive, numerate case against an AI project.

Presenting it#

• One page that links to everything. A plain site or a repository README. No reviewer opens seven files.
• Lead with the problem and the result, not the stack.
• Show the numbers. Accuracy on N cases; cost per task; payback.
• Show what did not work. A portfolio in which everything succeeded is not believed.
• Never include employer or customer confidential material. Rebuild the idea on public or synthetic data and say that you did.
• Write it yourself. Use AI tools the way you would on the job — and be ready to defend every sentence, because you will be asked.

Being findable#

• Write short notes in public about things you worked out: a cost calculation, a failure you diagnosed, a decision record. One a month is plenty.
• Answer questions where practitioners gather. Explaining is how architects are recognised.
• Speak once at a meetup or internal session. The preparation teaches more than the talk.
• Keep the decision log from the skills lesson. After a year it is a record of judgement no certificate provides.

Days 1–30: listen and map#

You were hired to have opinions. Do not use them yet.

Resist redesigning anything. Your credibility for the next year is built by showing you understood before you prescribed.

Days 31–60: deliver one small thing#

Choose something that is visible, useful within weeks, and removes a blocker more than one team has. Good candidates:

• Unblocking one stalled project — usually by getting a security or data-access decision made, or by writing the success criterion nobody wrote.
• A reference design for the most common pattern, already reviewed by security, that the next team can copy.
• A cost view: who spends what on which models. It always finds something.
• A one-page intake path: how an idea becomes an approved project, with named contacts and target times.
• An evaluation starter kit that a team can adopt in a day.

One of these, finished, does more than a strategy document. It also tells you how decisions really get made here.

Days 61–90: set the standard#

Now you have earned the right to propose.

Present it as a proposal to the people you met in month one, incorporating what they told you. Standards that people helped shape are followed. Standards that arrive from above are worked around.

Mistakes in the first ninety days#

The long game#

The field will not hold still, and neither will the job. Three habits keep an architect current without drowning.

• Follow the primary sources. Provider release notes and documentation, the standards bodies, a handful of engineering blogs — not the commentary about them. The Best of the Internet lists them.
• Re-run your own evaluations on each major model release. Nothing teaches you what changed faster than a test set you understand.
• Keep building small things. An architect who has not built anything for a year is recommending from memory.

The patterns in this course — find the real problem, choose the simplest thing that passes, put a number on it, make it safe to approve — were true before language models and will outlast the current ones. The names in the diagrams will change. That part of the job is looked up. This part is learned.

Remember this#

• A portfolio shows judgement: one full case with design, decisions, cost, evaluation and a working prototype.
• Include what failed and what you would change. That is what is believed.
• Days 1–30: listen, map stakeholders, build the inventory, find why projects stalled.
• Days 31–60: ship one small, visible thing that unblocks more than one team.
• Days 61–90: propose standards, a review cadence and a roadmap — with the people who must follow them.

Try it#

1. Choose the problem for your full case today. Write its problem statement this week.
2. Pick two of the shorter pieces and schedule them over the next two months.
3. Write your own thirty-sixty-ninety plan for a role you want, naming the first six people you would ask to meet and the question you would ask each.

Check yourself#

1. Why does an architect’s portfolio centre on documents rather than code?
2. What is the single most persuasive page in a portfolio, and why?
3. What should you produce in the first thirty days, and what should you avoid?
4. Why deliver something small before proposing standards?