lincolnwebs.com
vibe management
I remember the moment I realized we were doomed.
My new boss was a month into his role but I’d barely heard from him, and I was his only direct report. There was already a trail of red flags in the months that led here, but I was still trying to muddle through and be agreeable. In retrospect, a mistake.
He had a request to discuss — he wanted to change something. Now, I’m used to engineers asking to change something. It often starts with a personal preference or idea for something they heard about, and I guide them to connect their feelings to something that can anchor value in a proposal. We’re not going to do a thing because you thought it was neat or felt better. We’re going to do it because it’s going to move the needle on something we can at least indirectly measure, even if it’s purely experiential.
Vibes are just vibes, but _intuition_ is data. Differentiating requires practice.
What I find baffling is an _executive_ demanding a change based on _their_ feelings. If a significant part of my job as a lead is grounding technical teams in rational priorities and socializing the reasons for those choices, what’s happening when feelings-based priorities have already escaped containment above me in the org chart? I’ve spent most of my career “managing up” harder than anyone I know, yet it remains a huge time sink any time this happens.
The big change was GitHub. We _needed_ to move to GitHub because it was “better” than our current tool. No questions. No further notes. Just — _when_ can we do _this_?
Let’s rewind.
I was an early adopter of GitHub. My username is 4 letters, and my user ID probably has fewer digits than yours. All my roles had used GitHub since it existed, so I had the same thought years prior: “Ugh, we’re not using GitHub. This is going to annoy me forever.” And it did! But here’s what I did about it: I surveyed the team on their tooling preference, and I made a list of everything that would functionally change day-to-day by using GitHub.
The results were 1) a list we could refer and add to, and 2) a resounding “I guess GitHub would be nicer, but I don’t actually care” from the team. When I looked at the list, I realized that if I compared it to the cost of moving everything, it didn’t pass muster. And I, the _least_ code-engaged, was the biggest champion of moving. So, I left it at this: If anyone on the team wanted to champion the effort, I would support them and make time in the schedule for it. And that was the end of it.
New guy didn’t ask about any of that. He just asked me to change it for him. I vaguely agreed we could likely find time in the back half of the year for it. He was visibly pleased that his first big decision was acceptable. We never spoke of it again, because I left within weeks of that conversation. I don’t think they ever moved. He didn’t last a full year.
Changing someone’s tools feels like helping without needing any actual expertise. “If I bought the master carpenter the fanciest hammer, surely that would speed up the framing of my house.” Never do that, and no it would not. The master carpenter knows things about their tools you will never understand; they are an extension of them, not a generic part to be replaced on a whim.
Making decisions instead of guiding decisions always ends up like this. Confusing the power to make a change with the understanding required to do it well is commonplace, but all the bluster and confidence in the world cannot paper over the damage it does forever.
