Leadership
Engineering ladders and load paths
Career ladders are load-bearing structures. What an organization promotes for is what its systems will eventually be made of.
Code, Noted2 min readLeadership
If you want to predict what an organization's systems will look like in five years, do not read the architecture strategy. Read the promotion packets. The ladder is a load path: incentive flows down it, and structures grow along the load, as surely in organizations as in bone.

The mechanism needs no conspiracy. Engineers are professionals who respond to what their institution demonstrably rewards, and the demonstration happens twice a year in calibration. If the packets that pass contain phrases like "designed and launched a new service," the org will grow services, whether or not the boundaries hide any decisions. If "led the migration" promotes and "kept the ledger correct for four years" does not, the org will start more migrations than it finishes, and the stewards of standing systems will drift toward the exits or the management track.
The bias has a name in the trade: launch culture, or more tartly, promotion-driven development. Its structural signature is everywhere once seen. Systems accrete new components at the rate of review cycles. Maintenance is rebranded ("modernization", "replatforming") to look like construction, because construction is what the rubric can see. The quietly crucial work (the upgrade that prevented the incident, the deletion that finished a deprecation) appears in packets, if at all, as a supporting bullet. Everyone involved knows. The rubric does not.
The senior end of the ladder complicates things further. Most ladders above a certain rung require "organizational impact," which in practice means work that crosses teams, which in practice means initiatives, which in practice means new things. Charity Majors's writing on the engineer/manager pendulum maps one healthy escape: senior people oscillating between tracks, carrying context both directions. But the deeper fix is to the rubric itself: "impact" has to be legible for prevented incidents, retired systems, and decade-old services that simply never page, or the pendulum swings over a hollow structure. The staff-engineer archetypes that emerged in recent years (the Solver, the Right Hand, the notably un-launchy Tech Lead of a standing system) are the industry groping toward exactly this legibility.
Some organizations have found partial instruments. Rotating maintenance duty through the whole team keeps the cost of neglect democratically distributed. Postmortem-visible work gets harvested into packets by managers who treat that harvesting as their job. One shop this writer respects requires every promotion case above senior to name what the candidate deleted, deprecated or declined to build; the question was mocked for a quarter and then began, slowly, to reshape what ambition looked like there.
The essay's claim, stated plainly: incentive structure is architecture, upstream of all diagrams. An organization gets the systems its ladder can see. Renovating the ladder is slow, political, and as unglamorous as any other foundation work, which is to say it is exactly the kind of project this journal keeps concluding matters most. The load goes where the path is. Draw the path on purpose.