In a confluence of events this weekend, I was reminded of the difference in focus between folks who are highly reactive and folks who have systematized a long term approach and align actions against that. Each of these approaches has strengths and weaknesses, and I’m finding myself living in situations where I see the drawbacks and advantages of each.
First a bit of definition: What the heck am I talking about? Well, consider a situation where you’ve got a bunch of short term issues where you’re guiding other people, and where there’s an issue. Maybe a new product and “what color is the print on the packaging?” You’ve got a product team reporting to you that’s owns the product, and that team has a structure, and they’re working on on the package. Meanwhile someone on the team other than the lead comes to you informally and asks that question “because we need to order that today.” Without thinking, and because you want to move on, you give them a response. And the person goes back to the team and says, “Decision made. Pat says it’s blue #23.”
Most people see the immediate problem here. You just bypassed and undercut the team structure you built and subverted the team. Even if it’s just 2-3 people there’s a structure here and you’ve changed it. And that means a bit of jitter on the team until the structure is redone. If that was your intent anyway, fine. But if not, the next decision that the team makes is going to be harder and for no good reason.
Most people don’t fall into these traps for big decisions. It’s the smaller decisions where these sorts of things come up, nibbled to death by ducks.
Sometimes these decisions should just be made and move on – the ROI on discussing every decision in the team context is painful. Besides, some decisions really are time critical. And sometimes the lead or boss has to overrule for what appears to be capricious reasons. And efficiency, especially in a startup, is a good thing.
But overruling too frequently, and “just because I was asked” creates a bigger problem, because doing it too often means that the team doesn’t make decisions easily (for fear of being overruled), and when they do, they have little sense of ownership “because Alex is probably going to overrule it anyway.” The opposite of empowering.
The lead has to take the long view, but balanced against the number one rule of startups: There is no long view if the short view doesn’t pan out.
Still… eyes on the prize.
If the goal is longer than right here, right now, and the team isn’t stuck and needing guidance, then it owns the decision. The lead owns the structure, but the outcome? That’s owned by everyone. Because really, if you already knew what outcome you wanted, then why take the team’s time to rehash and potentially come up with a different result? Like getting 5 people to agree on a pay-for-yourself dinner destination and then the organizer announces, “I have reservations and a coupon for a-totally-undiscussed-place so that’s where we’re going. See you all in 15 minutes.” Ummmmm, why did we just spend 30 minutes discussing something else?
So when someone comes and asks “What color do you want for the printing on the package?”, the answer is “How are you deciding? Have you looked at ink costs? Tested it? ” and other process guiding questions.
Last weekend, it was about an event and people wanting a decision from one of the people running it, without consulting the folks in the area that were responsible for that decision. I was there and asked, What do the people in that area think? And the leader said, “Oh, yeah! We need them to decide this! I’ll get back to you!” Not because Bobby wanted to undercut the team’s ownership, but to get the decision made and get the interruption managed.
In another instance, it was about a process structure at our startup. Startups are trickier than single-events because 80% done and alive is better than perfectly dead. Still, when setting up a replicatable process, you still need to be careful to put the bumpers up where you don’t want to go off the rails. If customer facing means don’t execute commands on the customer’s system, be very firmly clear that when someone asks to “let me go in directly and run a few probes to see why the server failed.” Not “just this once” and especially not before the (make it lightweight!) process has been tuned and owned by the team. Well, because there’s a reason that we ask customers to take action on their servers, not us – liability and safety and customer policy just requires it.
If a relatively routine decision stretches the structure near to breaking or similar situations recur frequently, there’s an underlying issue instead. The real questions to ask are:
- Was the structure wrong? In this case, there is no “just this once”; it needs to be acceptable regular practice
- Is there another issue on this team that forces team decisions to external folks? Things like, someone jockeying for position, deadlocked members, inability to find a time to discuss, unclear requirements. If so, address that and give the decision back to the team.
A fully engaged empowered team owns the decision, and everyone on that team has a role in that process and understands the goals that were used to structure the process. It takes a lot of hard work to build that level of trust and interaction and ownership. It’s easy and fragile to undercut, especially early in the process or when stress is high.
So if you’re a lead or setting direction for a team that reports to you, be very careful when someone comes and asks you for a solo decision – are you undercutting what you’ve worked so hard to build? Your first response should always be a question to yourself: “Do I have to make this decision? Right now?”
And if the answer is yes, be prepared to support the team as you pull rank.