Maybe you’ve been part of a team that you’ve seen slowly slide into a rut. You didn’t notice it happen, but you’re now not shipping anything, no one’s talking to each other, and the management’s Eye of Sauron has cast its gaze upon you.
Maybe the people who used to oil the wheels that kept everyone together have moved on and you’re having to face facts—you all hate each other.
You’re not alone#section2
The first thing to understand is that you’re not the only person to ever encounter problems. Things like this happen all the time at work, but there are simple steps you can take and habits you can form to ease the situation and even dig yourself (and your team) out of the hole. I’ll share some techniques that have helped me, and maybe they can work for you, too.
It always starts out great#section3
An engineer called Jen was working with me on a new feature on our product that lets people create new meal recipes themselves. I was the Project Manager. We were working in six-week cycles.
The system architecture was a legacy mishmash of different parts of local databases and API endpoints. And, no prizes for guessing what’s coming next, the API documentation was like Swiss cheese.
Two weeks into a six-week cycle, Jen hit Tom up with a list of her dream API calls that she wanted to use to build her feature. She asked him to confirm or deny they would work—or even if they existed at all—because once she started digging into the docs, it wasn’t clear to her if the API could support her plans.
However, Tom had form for sticking his head in the sand and not responding to requests he didn’t like. Tom went to ground and didn’t respond. Tom’s manager, Frankie, was stretched too thin, and hence wasn’t paying attention to this until I was persistently asking about it, in increasingly fraught tones.
In the meantime, Jen tried to do as much as she could. Every day she built a bit more based on her as-yet unapproved design, hoping it would all work out.
With two weeks left to go, Tom eventually responded with a short answer—which boiled down to “The API doesn’t support these calls and I don’t see why I should build something that does. Why don’t you get the data from the other part of the system? And by the way, if I’m forced to do this, it will take at least six weeks.”
How did we sort it?
Step 1 — Accept#section4
When things go south, what do you do?
Acknowledge whatever has happened to get you into this predicament. Take some notes about it to use in team appraisals and retrospectives. Take a long hard look at yourself, too.
Write a concise, impersonal summary of where you are. Try not to write it from your point of view. Imagine that you’re in your boss’ seat and just give them the facts as they are. Don’t dress things up to make them sound better. Don’t over-exaggerate the bad. Leave the emotions to the side.
When you can see your situation clearly, you’ll make better decisions.
Now, pointing out the importance of taking some time to cool down and gather your thoughts seems obvious, but it’s based on the study of some of the most basic circuitry in our brains. Daniel Goleman’s 1995 book,Emotional Intelligence: Why It Can Matter More Than IQ, introduces the concept ofemotional hijacking; the idea that the part of our brain that deals with emotion—the limbic system—can biologically interrupt rational thinking when it is overstimulated. For instance, experiments show thatthe angrier men get, the poorer are the decisions they makeat the casino. And another study found that people in a negative emotional state are更有可能偏离逻辑规范. To put it another way, if you’re pissed off, you can’t think straight.
- Tom and Frankie’s communication was poor. The reasons for that don’t form part of this discussion, but something wasn’t right in that team.
And that’s step one.
Step 2 — Rejoice#section5
很少有人喜欢犯错误，但每个人将让人在寡糖r life. Big ones, small ones, important ones, silly ones—we all do it. Don’t beat yourself up.
在我职业生涯的开始,我工作在一个团队谁e manager had a very high opinion of himself. He was good, but what I learned from him was that he spread that confidence around the team. If something was looking shaky, he insisted that if we could “smell smoke,” that he had to be the first to know so he could do something about it. If we made a mistake, there was no hiding from it. We learned how to face up to it and accept responsibility, but what was more important was learning from him the feeling we were the best people to fix it.
He would tell us that we were only in this team because he had handpicked us because we were the best and he only wanted the best around him. Now, that might all have been manipulative nonsense, but it worked.
The only thing you can control is what you do now, so try not to fret about what happened in the past or get anxious about what might happen in the future.
So don’t waste time pointing fingers. Don’t prepare slide decks to throw someone under the bus. Tag that advice with a more general “don’t be an asshole” rule.
If you’re getting consistent heat about the past, it’s because you’re not doing a good enough job filling the bandwidth with a solid, robust, and realistic plan for getting out of the mess.
So focus on the future.
Sometimes it’s not easy to do that, but remember that none of this is permanent. Trust in the fact that if you pull it together, you’ll be in a much more powerful position to decide what to do next.
Maybe the team will hold together with a new culture or, if it is irretrievably broken, once you’re out of the hole then you can do something about it and switch teams or even switch jobs. But be the person who sorted it out, or at the very least, be part of the gang who sorted it out. That will be obvious to outsiders and makes for a much better interview question response.
In our story with Jen, we had a short ten-minute call with everyone involved on the line. We read out the summary and asked if anyone had anything to add.
Tom spoke up and said that he never gets time to update the API documentation because he always has to work on emergencies. We added that to our summary:
After that was added, everyone agreed that the summary was accurate.
如果我们这样做,我们会丢脸。会有意图l financial consequences. It would show up on our appraisals. It wouldn’t be good. It wouldn’t be the end of the world, but it wasn’t something that we wanted. Everyone probably knew all that already, but there’s a power in saying it out loud. Suddenly, it doesn’t seem so scary.
Jen spoke up to say that she was new here and really didn’t want to start out like this. There was some murmuring in general support. I wrapped up that part of the discussion.
Step 3 — Move on#section6
Stepping back for a second, as the person who is going to lead the team out of the wilderness, you may want to start getting in everyone’s face. You’ll be tempted to rely on your unlimited reserves of personal charm or enthusiasm to vibe everyone up. Resist the urge! Don’t do it!
Your job is to give people the space to let them do their best work.
我经过惨痛的教训才学到这个。I’m lucky enough that I can bounce back quickly, but when someone is under pressure, funnily enough, a super-positive person who wants to throw the curtains open and talk about what a wonderful day it is might not be the most motivational person to be around. I’ve unwittingly walked into some short-tempered conversations that way.
Don’t micromanage. In fact, scrap all of your management tricks. Your job is to listen to what people are telling you—even if they’re telling you things by not talking.
Reframe the current problem. Break it up into manageable chunks.
The first task to add to your list of things to do is simply to “Decide what we’re going to do about [the thing].”
Once you start getting some suggestions back and can tick those tasks off the list, you start to generate positive momentum. Nurture that.
If a plan emerges, champion it. Be wary of naysayers. Challenge them respectfully with “How do you think we should…?” questions. If they have a better idea, champion that instead; if they don’t respond at all, then gently suggest “Maybe we should go with this if no one else has a better idea.”
Avoid words like “need,” “just,” “one,” or “small.” Basically, anything that imposes a view of other people’s work. It seems trivial, but try to see it from the other side.
Instead, try “We’re all looking at you here because you’re good at this and this is a nasty problem. Maybe you know a way to make this part work?”
So I asked Jen, Tom, and Frankie to submit their proposals for a way through the mess.
It wasn’t straightforward. Just because we’d all agreed how we got here didn’t just magically make all the problems disappear. Tom was still digging his heels in about not wanting to write more code, and kept pushing back on Jen.
There was a certain amount of back and forth. Although, with some constant reminders that we should maybe focus on what will move us forward, we eventually settled on a plan.
And even with the compromise, Tom wouldn’t be finished in time. He’d need another couple of weeks.
But it was a plan!
N.B. Estimating is a whole other subject that I won’t cover here. Check out theShape Up对此的一些伟大建议的过程。
Step 4 — Spread the word#section7
When communicating with people who are depending on you, take the last line of your email, which usually contains the summary or the “ask,” and put it at the top. When your recipient reads the message, the opener is the meat. Good news or bad news, that’s what they’re interested in. They’ll read on if they want more.
If it’s bad news, set someone up for it with a simple “I’m sorry to say I’ve got bad news” before you break it to them. No matter who they are, kindlyframing the conversation will help them digest it.
When discussing it with the team, put the plan somewhere everyone can see it. Transparency is key.
Don’t pull any moves—like publishing deadline dates to the team that are two weeks earlier than the date you’ve told the business. Teams aren’t stupid. They’ll know that’s what you do.
Publish the new deadlines in a place where everyone on the team can see them, and say we’re aiming for this date but we’re telling the business that we’ll definitely be done by that date.
In our case, I posted an update to the rest of the business as part of our normal weekly reporting cycle to announce we’d hit a bump that was going to affect our end date.
Here’s an extract:
We uncovered a misunderstanding between Jen and Tom this week. The outcome is that Tom has more API work to do than he anticipated. This affects the delivery date and means we’re now planning to finish 10 working days later on November 22.
**Expected completion date ** CHANGED ****
Original estimate: November 8
Current estimate: November 22
We successfully released version 1.3 of the app into the App Store .
And so on…
That post was available for everyone within the team to see. Everyone knew what was to be done and what the target was.
I had to field some questions from above, but I was ready with my summary of what went wrong and what we’d all agreed to do as a course of action. All I had to do was refer to it. Then I could focus on sharing the plan.
There was some more wailing and gnashing of teeth, but we all got through it and—even though we tried to finish early but failed—we did manage to finish by the November 22 date.