📚On MBTI and Other Distractions

Reading this got me to thinking about some things:

I find myself not surprised at all about the MBTI’s dubious utility. Back in the dotcom boom, after I pointed out to upper management (with impolite candor that I’d be mortified by today) that a couple of consultants we’d hired were not much better than con artists, I was forced to attend “executive training” sessions with a corporate psychologist who, if I’d written them into a story, would have been editorially questioned as a poor caricature of afternoon TV host ambition. During those grinding weeks, I took the MBTI and a couple other scantronnesque tests, and while on the surface their results appealed to my sense of self and identity, I soon got the same feeling I’d had as a kid when I’d figured out the scam behind the funny page’s daily horoscope column.

Another employer wasted months on DISC assessments for everyone in management roles, and then wasted more time getting everyone to understand RA(S)CI grids, both of which dropped from use within weeks. All of that felt to me like RPG character generation for people who’d feel embarrassed to call themselves a chaotic-neutral half-Elf ranger but still wanted to fit into a set of little scored boxes.

I eventually realized similar lessons about Agile, Lean, Kanban and pretty much every other methodology and tool used to manage any kind of contemporary thought-driven work. They’re leaky abstractions. They devolve into dogma and ceremony because humans are lazy.

What works for me:

Pick something to keep track of the state of the team’s current and planned efforts: a shared spreadsheet, AgilePad, Basecamp, Trello, an issue/bug tracker, whatever. Make it easy for team members to contribute to and navigate within this information. Don’t get hung up on points or sizing or metrics: they’ll drive the team to wasteful games.

Don’t try to use a customer support tool for this. Those are geared towards question/answer exchanges and getting people satisfied and on their way as fast as possible, not for collaboration.

Keep track of the state of the product, whether that’s a software application or a playbook for daily business: A wiki, a shared document folder, a Git repository of Markdown files, whatever. This documentation provides team memory and helps bring new team members up to speed. Try to strike a balance here between some pure, crystalline structure and a junk drawer. Make it easy for people to contribute and bake in time for documentation in your planning.

In my experience, Slack, or any of the Slack-alikes, will fail as a tool for both tracking and documenting a team’s work. Email fails as well. There’s a world of difference between notification channels and information storage.

Keep track of your personal To Do list: your calendar, email, favorite GTD app, notebook, whatever. Don’t overthink this, but do make it a habit to write stuff down and check your list often.

Everything else should be conversations. The cards in Trello are reminders to have conversations. The pages in the wiki are records of conversations. The channels in Slack (which will proliferate like kudzu if you’re not careful) or threads in email are thin, poor substitutes for conversations.

Find your team’s natural cadence and balance somewhere between constant interruption and half-day blocks of meetings, whether that’s daily stands or weekly check-ins or quaterly lunches. There’s little more powerful than a handful of human brains networked face-to-face around a table, but too many people at once diminishes returns quickly. For planned conversations, provide an agenda ahead of time, even if it is a single question to answer. Distribute notes immediately after, or store them in one of your team’s tools.

If you manage someone, at least schedule a weekly one-on-one conversation, even if it is only fifteen minutes long and you both beg off three times out of four.

Just don’t overthink any of it. That’s all I know.