About this site

My memory’s pretty unreliable, so when I’m ingesting information/ideas, I take a lot of notes I can use to refresh later. And sometimes I want to discuss these ideas with others, so it’s a plus if I can share links or even my own notes.

So that’s the main idea here: a place to put my notes.

Some disclaimers are in order:

• Maybe it turns out that the ideas are ill-conceived or the info is wrong;
• Maybe my notes seemed like a useful summary at the time but are useless to refresh from.

In short, I offer no promises about the shelf life of these notes.

And you know how it is, I figure I’ll also put my own thoughts here from time to time.

About this site’s name, pwn.ersh.io

One of my jobs as a software developer was at a company that, during my time there, grew from 200 technical staff to 2500+ technical staff. The needs of the organization were very different at these sizes. This company’s technical organization took on headcount eagerly, but was resistant to changes in its way of working. A small organization has highly coherent norms about what success looks like, so people fix stuff without having to be told, but in a large organization that coherence goes away and you can no longer assume that good samaritanism will keep the lights on.

Even when we were < 400 developers, when coherence was still decent, management was talking an awful lot about taking ownership as a required behavior, precisely to urge this sort of good samaritanism. But for years there were no steps taken to enable finding what’s broken, or to encourage fixing broken stuff, and correspondingly good samaritans went unacknowledged. By the time we were ~1500 people, major functionalities and infrastructure were brittle. We had some big outages, bad morale, and nasty process breakdowns. The whole thing was an unforced error. Call it what you will: a self-own, an own-goal? We pwn’d ourselves.

Around the time we were 2000 people large, I was trying to re-appropriate the term ‘ownership’, in the sense of a central ledger of deeds/leases attributing our applications to our people/teams, with corresponding privileges and responsibilities over those applications. The general idea is that this would give us the means to map team-dependencies as a function of application-dependencies (and so permit informed organization design). A better mapping of the “what” of work-as-done gives us more fuel to design relevant policies that incentivize useful behaviors, disincentivize harmful behaviors, and make bad outcomes conspicuous (so bad practices can eventually be fixed up).

Of course, such an approach can go bad too. If you build such a ledger but don’t actually use it to grant privileges (only responsibilities) or fulfill shared needs or align the incentives of interdependent teams to maximize harmony, then the intervention won’t slow or reverse the degradation of outcomes. Producing good outcomes will still require swimming against the current of doctrine/policy. If anything, more accountability without more autonomy puts individuals in a more precarious situation–even if “lateral” cooperation doesn’t intrinsically get any harder, the asymmetry added to the “vertical” reporting line relationships adds pressure that’ll mostly be relieved laterally–with problems escalating faster and harder. The attribution will boil down to One Neck to Choke ownership, a cudgel to ding small groups of people for failing to produce cooperation in an antagonistic environment.

My propaganda campaign was moderately successful. At some point, a series of substantial outages put a visible price tag on the deficiency. It got a team staffed to work on the topic, and although that team didn’t use any of my PoC work in what they built (boo hoo), they did listen to me, and affectionately referred to me as The Godfather of Ownership. Of course, within two years every member of the team has moved on (in fact, literally every person in the reporting line up to and including the CEO was either gone from the company or reassigned since then), so although this is but a faint glimmer in the memory of the organization, which now aims to dual-class the tool filling this need between One-Neck-To-Choke and capital-G Governance, with collaboration certainly not in scope. So it goes.

It’s probably unhealthy to hitch any part of my identity (or even ‘professional brand’, haha) on this one thing. And the longer I’m away from that place the less appeal it’ll have for me to get on that hobby-horse. But at least for now I think I feel smug.

My own personal smugness aside, it’s a humbling and generally useful lesson for myself and others that a Fortune 500’s IT department can fall victim to significant doctrinal fuck-ups that lose the company major money and cost it credibility with its employees (after years of “How can they not see how bad this is” became “well, golly, that was a heck of an outage”).

My own pride is also something to learn from. I naively believed that we could jumpstart the good samaritanism of the past back into action by introduction of a tool. But just like in our personal lives, you can’t simply relive the good parts of the past by changing one or two things of the present back to the way they used to be. Going back was never an option, you have to generatively construct the present and accept that it’ll be different. And when you’re making changes in the present, a tool will never be adequate on its own, the humans must be willing (or to borrow a quote, “A tool by itself is clutter. It’s your reaction to it that matters.").