Before moving to the suburbs, I had been living in NYC for 12+ years, so my skills with a set of tools aren’t extensive. There are lots of problems I could eventually fix with significant time and money invested into projects, as I do like my projects to tinker with, but I don’t have infinite resources to do all the things. That’s why I’ve got a handyman I call up, as everyone should.
My handyman is Roger, a now semi-retired civil engineer and MIT grad. His visits entwine a blessing of knowledge around an otherwise potentially disastrous event – roof tiles flying off, an oven subtly leaking gas, or what has become an annual occurrence where some form of plumbing threatens to flood my house. I take a crack at it and when my pridefulness is eclipsed by the existential threat of my living space facing certain doom, I give him a call.
“And you’d think this would all be standardized, but it’s not! It’s like cmon, why can’t you just get this all straight!?” he laughs as he rips apart my sink. He pulls out a pair of pump pliers and sets to work as another faucet piece pops off. I solemnly nod, taking in how to deconstruct/reconstruct the bathroom should the need arise again. It will, naturally. My house seems to break down every other week.
His approach to home repair tickles those same parts of my brain as does software engineering. A lack of standardization? I get that. He remarks how houses don’t come with an owner’s manual. Wouldn’t it be nice if companies did too. Shouldn’t I know everything about the place? I live here, after all. Yet here I am, the resident (if you can excuse the pun) expert, deferring to his expertise.
“Just make sure you cover the drain when taking out the screws. You know how I know to do that? Because I’ve dropped them down there enough times”. He knows how to approach problems because, as he says, he’s seen the same six or eight versions of it before. He hasn’t honed his skills on work perfectly crafted from the start, but from seeing the gaps evolve from imperfect planning. Remarking on sealing the corners of the tub, he notes the walls shifting as joints meet and separate through varying temperature changes. A seemingly static house itself is constantly in flux, much like our working environments.
Then he stands up straight and waves at me a hereto unknown part of my sink. “You know what this is?” I naturally answer in the negative. “Neither do I. Time to go see my guy at the plumbing store. He’s the guy who’s seen everything and done everything, the XK-587 or whatever here. Doesn’t matter what I bring in, he knows exactly what to do.”
My expert has his own expert when he doesn’t know something. The guy who’s “seen and done it all” still has someone he rings up, because that’s what experts do, sourcing from upstream and relaying that information back down to another node on the graph. If I’m lucky, I’ll retain enough information to use or maybe even pass along to someone else.
Which brings us back to software engineering. We’re always so surprised when the expert manages to jump to the right config, flip a switch, and set the machine back in order. We assume it’s innate talent, some magic imbued that resides only within them and goes no further. I’m deeply appreciative of expertise, but we hold too many folks up on pedestals, when in truth they have their own gurus who they rely upon. They remember their screws dropped down the drain and ask their authority in plumbing, combined into charting a best path forward.
A few thoughts and questions arise from all of this:
- How do we go about observing the near infinite number of changes around us, filtering down to what we’ll need “someday”?
- If experts have their own experts, we as professionals need to develop a system of interconnected people capable of adapting to the unknown failures we experience in both a local and global focus. Machines need people and people need people.
- That interconnected network then, in its collaboration, needs to have self awareness of what skills need to be honed and how we go about distributing that skill. The shared knowledge isn’t just how to fix but meta information about that ability.
- We talk often of avoiding as many failures as we can, but which are the failures we’re ok with and how are we seeking them out? Put another way, we need to experience a few screws dropped down the drain to learn but developing an understanding of which pain points we can reasonably withstand takes experience as well.
- Where does the balance lie in letting our non-experts take over to return the system to a stable state, potentially educating the next batch of specialists? We emphasize the importance of learning from incidents as experiences after the fact, but generally regard the chance to educate during an incident as “too costly”.
- How are we making continual efforts to prepare for these failures – to be ready to resolve them, to retain information during, and perhaps most importantly pass that information along afterwards? Relying solely upon experts with no additional knowledge sharing is itself a brittleness that exists within a system.
Eventually, Roger returns from talking with his expert and immediately passes to me a replacement part. Sure enough, the gears inside don’t show the same wear and tear. My bathroom is still in pieces, but they’re all there and I’ve seen enough to finish up. “Until next time!” he knowingly laughs. Because of course there will be another disaster. Here’s hoping I’ll be a little more prepared for it.
1 comment for “Even Experts Need Experts”