William Cameron | Beyond the Keyboard

Most engineering roadmaps begin with visible product outcomes and then allocate people as though every available day can be converted into feature delivery. The plan looks credible until incidents, support, maintenance, onboarding, security updates and cross-team dependencies consume the capacity that was never acknowledged. This is often described as unexpected work. Much of it is entirely predictable. The uncertainty lies in timing and volume, not in whether it will exist. Capacity is not headcount A team of six does not provide six full-time units of roadmap capacity. People attend planning, reviews, one-to-ones and organisational work. They take leave, support colleagues, respond to production and maintain existing services. Specialists may create constraints that average headcount conceals. Start with historical evidence. Review how time was actually spent across several months: planned product work, operational support, defects, platform maintenance, discovery and unpla...

As engineering organisations grow, leaders often create architecture review boards to prevent inconsistency and costly mistakes. The intention is sound. The failure mode is predictable: decisions queue behind a small group, teams prepare presentation theatre and reviewers become accountable for systems they do not operate. The alternative is not architectural anarchy. It is to replace broad permission with clear guardrails, local ownership and deliberate escalation for genuinely consequential decisions. Define the safe operating space Guardrails describe the boundaries within which teams can decide independently. They might cover identity, encryption, data classification, observability, supported runtimes, public API standards and operational ownership. A good guardrail is testable and connected to a risk. "Use approved technology" is vague. "Customer credentials must be stored in the managed secrets service and never exposed to build logs" provides an enf...

Blameless incident management is sometimes misunderstood as avoiding judgement. In a healthy engineering organisation, it means removing fear and hindsight bias so the system can be examined honestly. It does not mean that ownership, standards or follow-through disappear. An incident review that concludes "the process failed" without identifying who will change the process is not blameless. It is incomplete. Separate fault from accountability Fault asks who caused the event. Accountability asks who owns the response, learning and risk decision. Individuals can make reasonable choices within a system that produces a poor outcome. The organisation still needs named people responsible for restoring service, communicating impact and ensuring agreed improvements happen. This distinction encourages disclosure. Engineers should be able to explain exactly what they did and believed without fearing punishment for an honest mistake. Leaders, in turn, must be able to require s...

Technical debt is often managed as a collection of tickets that compete unsuccessfully with product features. The backlog grows, engineers repeat that the system is fragile and leadership struggles to distinguish urgent risk from general dissatisfaction. This model fails because technical debt is not one type of work. It is a portfolio of liabilities with different costs, probabilities and strategic effects. Managing it well requires classification and investment decisions, not a periodic appeal to "spend twenty per cent on tech debt". Name the consequence A debt item should describe the cost it creates. Does it slow every release, increase incident probability, prevent a product capability, create security exposure, depend on unsupported technology or concentrate knowledge in one person? "Refactor the checkout service" is an implementation proposal. "Checkout changes require three days of regression testing and fail twice as often as other services...

Platform engineering is frequently launched as a technical programme: standardise pipelines, create templates, consolidate cloud tooling and reduce duplication. Those aims are sensible, but they are not a product strategy. Without one, the platform becomes a collection of infrastructure chosen by its builders rather than a service shaped around its users. The result is familiar. The platform team reports successful delivery while application teams continue to maintain custom deployment paths, copy old repositories and request exceptions. Adoption stalls because the organisation built capabilities without addressing the work developers were trying to complete. Developers are customers, but not always the buyer A platform serves several groups. Developers need fast, understandable paths to production. Security needs enforceable controls. Operations needs observability and recoverability. Finance needs cost visibility. Engineering leadership needs consistency without centralising ...

A Principal Engineer is often described as the most senior individual contributor. That definition is accurate but incomplete. The role exists because some engineering problems cross team boundaries while belonging to no single delivery backlog. Solving them requires influence without direct authority. This is why promoting the strongest programmer into a Principal role can disappoint both the engineer and the organisation. Technical depth matters, but the differentiating capability is turning ambiguous, cross-cutting problems into coordinated action. Start with the system, not the solution A Principal Engineer should see more than code. They need to understand team boundaries, incentives, operational ownership, product constraints and where decisions are repeatedly delayed. A technically elegant proposal that requires five teams to accept unplanned work is not yet a viable strategy. The first deliverable is therefore often a map: who owns the affected systems, which outcomes...

Senior engineering is often presented as the ability to make difficult technical decisions. In practice, the more valuable skill is knowing which decisions need to be made now, which can be made reversibly and which should be deferred until the organisation has better information. Teams create unnecessary risk when every choice is treated as permanent. They either over-design a system to protect against distant possibilities or move quickly without recognising the few decisions that genuinely constrain the future. Staff Engineers and engineering leaders need a shared language for separating these categories. Distinguish commitment from implementation A decision becomes expensive when it changes the organisation's available options. Selecting a proprietary data platform, exposing a public API, adopting an identity model or dividing ownership across services can create long-term commitments. Choosing a component library, internal queue abstraction or initial table structure m...