Rounds specific to senior, staff, principal, and architect titles, where the subject is judgement and organisational impact rather than code.
12 published across 7 topics.
Architecture and tech leadership fundamentals56 short answers on one page, for revising rather than studying.Defending a decision under challenge, articulating what you gave up, and reasoning about reversibility.
The choice turns on team topology and independent deployability, whether domain boundaries are stable, data ownership and distributed-transaction cost, and real operational maturity. Default to a modular monolith with enforced internal boundaries and extract services only on evidence.
A synchronous call couples availability and latency but keeps the outcome knowable at the point of decision; an event decouples both but converts every failure into something the caller will never learn about. Choose by asking whether the caller needs the answer to proceed, not by which style is fashionable.
Eliciting and prioritising non-functional requirements, and turning them into testable targets.
Convert the phrase into an error budget over a stated window, derived from what an outage costs the business rather than from a round number of nines. Each additional nine roughly multiplies cost, because it forces redundancy, cross-region failover and operational maturity that the previous nine did not need.
Rewrite it as a quality-attribute scenario: a named stimulus arriving at a stated rate, hitting a stated system state, with a response measured at a percentile over a defined window. A number with a load figure, a duration and a named sacrifice is designable and testable; a list of maxima is not.
Recording decisions so they survive turnover, and communicating architecture to mixed audiences.
Stale documentation is a symptom of documenting things that change faster than anyone will maintain them. Write down decisions and their reasons, which are immutable once made, generate anything derivable from the code, and let the rest go undocumented on purpose.
An ADR captures the context that forced a choice, the options considered with the reason each was rejected, the decision, and the consequences including the costs you accept. Write one when the decision is expensive to reverse or would surprise a future reader, and supersede it rather than edit it.
Strangler-fig sequencing, dual writes, data migration, and de-risking a legacy replacement.
Put a routing facade in front of the old system, migrate one business capability at a time, and treat dual-write as a reconciliation problem rather than two inserts: name a writer of record at every moment, shadow-compare before flipping reads, and sequence slices so value lands early.
Cloud cost modelling, build-versus-buy reasoning, and defending spend to non-technical stakeholders.
Attribute the bill before touching it, then work in order: fix the architectural decisions that generate spend, right-size against measured demand, and only commit to discounts once the shape is stable. Track a unit cost so a reduction can be told apart from a traffic drop.
Setting direction, managing technical debt as a portfolio, and aligning architecture to business goals.
Build what your users pay you for and buy the rest, correcting that heuristic for switching cost and data gravity. The comparison people get wrong is licence fee versus zero, when it is really licence fee versus salaries, on-call and opportunity cost for as long as the system lives.
A strategy is a diagnosis, a small set of decisions already made, and the things you are choosing not to do — written so a team can tell whether next quarter's plan complies. Adoption comes from applying it to a live decision within weeks, wiring it into existing rituals, and making the compliant path the cheapest one.
Situations to reason through: a failing rewrite, a vendor lock-in, a security mandate, a merged codebase.
Find out why it happened before deciding what to do about it, because duplication is usually a symptom of a discovery or ownership failure that consolidation alone will not fix. Then choose deliberately between merging, keeping both, and letting one wither, on the basis of migration cost rather than tidiness.
Spend the first week building an evidence map from money, traffic, incidents and deploys rather than from code, and interviewing the people who touch it with one fixed set of questions. Spend the second producing a risk-ordered plan of stabilisation before structure, with unknowns listed explicitly.