July 5, 2017
This is not a subtweet; if I thought this should be about you, I’d have said so to your face months ago. If you get all the way through it and still kind of suspect it’s about you, though, you should spend some time looking inward and gear yourself up to deal with whatever you find in there, rattling the chains.
I’ve started and stopped writing this a couple of times now. Some drafts have been didactic, other self-congratulatory. “Blogging isn’t real if it’s not the first draft”, I’ve read somewhere, but I’ve never been able to do that; writing has always been a slog from what I’ve got written to what I can just barely sense I could. If I wanted to flatter myself I’d wheel out the old Mozart/Beethoven analogy, but that feels too much like fishing for compliments and besides, that garbage was in an early draft too.
So let’s lead with the punchline. Here’s the checklist: does everyone on your team…
- have a shared understanding of success?
- know what everyone else’s role is, and what they need to do their job well?
- know how their work contributes to the team’s success?
- know how their team’s success contributes to their own?
If you’re surveying the field from the executive suite and need big-picture, master-class management advice, well. This is not that. Talk to my friends Shappy and Johnath at Raw Signal. If you understand what they’re offering you know better than to look for it here. What I’ve got here is penny-ante table stakes, the difference between a team and a handful of people sharing the same corner of an orgchart. It is not complicated; it should, in theory, be trite. But to borrow a line, the fact is that in the day-to-day trenches of adult existence banal platitudes can have life-or-death importance.
In theory, you’d think hitting 4 out of 4 would be not just easy, but expected. In practice, in my experience, you’ll be lucky to make it to 2.
A few months ago I was asked to help a team out of the weeds. Getting into the details would be a disservice, so I won’t; in the broad strokes, I’m talking about a cross-discipline team of smart, invested people doing an important job. But for whatever reason, something – several somethings, it turned out – had gone really, really wrong. Execution, morale and retention were all going south. Everyone knew it, but nobody was really sure what had happened or what to do about it.
So I talked to a lot of people, I read a lot of mailing lists and bugs, and offered some advice.
If you’ve been around the team-dysfunction block before, you know there are plenty of probable causes. Shakeout from a reorg, a company pivoting hard, a team managing some sudden turnover, maybe the organization has grown from everyone being in the same room to nobody even being in the same city. Maybe you’ve hit that critical mass where communicating has suddenly gone from something nobody needed to worry about to something nobody remembers how to do. Maybe the one person who made it work left, maybe it’s just been that way so long nobody remembers the possibility that it could be different.
The advice I had for them was straightforward, a word I love for the veneer of upright nobility it adds to a phrase I could just as easily close out with “simple” or “obvious”. Get everyone into the same room for a few days, preferably away from everyone’s home base. Start the first day by having everyone give a talk about their jobs, not some name-and-title intro but a deep dive into what their job involves and the information, context and resources they need to do it well. Have some conversations – some public, some privately – between team leads and members about personal or professional goals and growth paths.
And then take the roadmap and the entire work backlog for the team and – ideally in the last meeting of that first day – print it out, stand up in front of everyone and drop it on the floor. Then tell everyone to come back the next day ready to start fresh.
The goal of this exercise was to make all the hidden costs – all the hidden work, all the hidden friction, everything people couldn’t see through the lens of their own disciplines – visible. And then, with that information, to take a hard reset. To narrow the team scope down to one or two tightly focused, high-impact features that could ship soon, and – critically – explicitly stop working on everything else. That sounded a bit dramatic, maybe impossible – I’ve been called worse – but nothing else seemed like it would work at all.
Because when I was asking my questions, the answers I got were mostly about the questions those teammates were asking each other. And it wasn’t hard to spot a common theme.
“If only it weren’t for the people, the goddamned people,” said Finnerty, “always getting tangled up in the machinery. If it weren’t for them, earth would be an engineer’s paradise.” – Kurt Vonnegut, “Player Piano”, 1952
Does everyone on the team understand that when you ask a designer to make a new button, that you’re asking them for a few dozen hours of product and market research, and a few more of design and testing, and not half an hour in Illustrator drawing pretty pictures? Does everyone really get that accommodating that schema change means refactoring a pile of business logic or backup processes? Did you all notice that you were asking for a contractual change with a major partner when you said “just change this string”?
I made those questions up for this post; the real ones were different in the specifics but definitely not in substance. You realize that you’re asking for the entire process, not just the output at the end, right? Why don’t you just?
You’ve seen this. You’ve probably even asked questions like them; I sure have. And unchallenged, even the mildest case of engineer’s disease left untreated will fester; eventually cultural rot sets in. We don’t really have a word for the long decline that happens next, the eventual checking out that happens the moment you clock in. The septic shock, the team’s paralysis and organ failures of core people ragequitting near the end. But you’ve seen that, too.
“You should focus on a small number of things” and “it helps to understand how your colleagues do their best work” is not exactly going to spur a revolution in technical leadership. I get that. But: don’t mistake the roadmap for the terrain. If you’ve made that plan without a clear, shared idea of where you’re going, how everyone can help you get there, and why you’re going at all? Then it’s hard to see how that will succeed, much less give rise to the kind of work or working environment you can be proud of. So toss it. Do the work of understanding where and who you are, and draw the map from there to somewhere that matters.
I told you this was table stakes, and I was not kidding about that at all. I wanted to help them get to a point where everyone on the team could confidently go 4 for 4 on the list, to get them to necessary so they could launch themselves at sufficient. And now, a couple of months later, I think it worked. They’re not all the way there yet – culture’s got a lot of inertia, and if I ever find a way to hard-pivot a whole org I’ll let you know – but they’re on the way, with a lot of clarity about what they’re doing, how they’re going to get it done together, and why it matters.
So: what about your team? Does everyone on your team have a shared understanding of success? Do you know what everyone else’s role is, and what they need to do their job well? Do you know how your work, and theirs, contributes to the team’s success and to your own?
Or does your team – maybe, possibly, kind of, just – suck at being a team?
You should do something about that. What are you going to do about that?