On CEO (and leader) Responsiveness

I’ve always loved “essay question” emails about the “how or why” of work. I used to turn these into blog posts and realized I should be doing that more often. I received this question about responsiveness from a CEO and what follows is my (lightly edited/expanded) reply.

From: ##### ######

Sent: Thursday, May 4, 2017 2:34 PM

Subject: Building a habit of fast response?

To: Steven Sinofsky ()

Hey!

Had a semi-personal question:

How did you build up the habit of responding to folks as quickly as you 
do?

###### brought it up as well — you seem to be a very “high velocity 
decision maker”. Curious if it was organic to your personality to be 
so on + responsive or if you built this style over time? 

Also curious how valuable the habit is to you.

No pressure to respond on this quickly (or at all if other things are 
on your plate!) — just something I’ve been thinking about.

Hope you’re well :)

That’s super nice thing to say and thank you for noticing. I love the question. Also let me try to be responsive :-)

Whole books get written on this (back at Microsoft we even partnered on an add-in for Outlook with a leading one).

Like many, I’ve read a bunch over the years but never really found “one” that seems to be the right combination of theory and practice. Mostly because in general I’m a big believer in context and so abstract thoughts on non-scientific concepts (like time management) are subject to high degrees of survivor or observer bias. So with that in mind here are some abstract thoughts on a concrete topic :-)

I might take one cut at your question by thinking about it from a leader’s perspective along two dimensions:

• Velocity of decision making
• Responsiveness to teammates

Velocity of decision making

Velocity depends a lot on your role. In a company people tend to think about the decisions that are difficult or can’t be made. Yet every day people make dozens of decisions with high velocity and essentially no friction. Every line of code, all the text in a deck or on a site, every word to a customer or potential customer, and so on. People are deciding extremely important things all the time without any slow down.

In other words keep things going, but also know you will revisit if needed. In a software project this is about setting up a series of milestones or gates where you evaluate if things are going well.

Still slowdowns can happen. Usually it happens in two ways:

1) You don't know the best thing to do or you don’t understand or like the implications of the path that looks “right”. These decisions are the ones that actually gum things up the most because different people have different tolerances for risk. Or alternatively different decisions with uncertainty have different implications if they are wrong.

A good tool I’ve found to look at “speeding up decision making” is to consider the the role of optionality. If you can make a choice but also maintain optionality to revisit it later then go that way. In other words keep things going, but also know you will revisit if needed. In a software project this is about setting up a series of milestones or gates where you evaluate if things are going well.

I know this sounds “old” to those that believe in less planning and more agility. At the same time, across the industry we’re seeing higher value in being deliberate and a little bit less value trial and error.

At massive scale a good example of this is sending a person to the moon. They didn’t just strap a person to a rocket and send it up. If you look at the details of the 10 year project they had a series of specific missions that led to the big goal. And even a big accident that caused things to reset. The important capability was a willingness to change course even with a monster deadline looming.

A solid plan for the long term permits that type of decision making. I think this type of though process applies to just about every project oriented task. You work backwards from a deadline and develop milestones that allow you to revisit interim decisions. This often runs counter to the notion of agile which is to have a less clear view of the medium term coupled with a lot of short term experimentation. Without a strong sense of the medium term, your experimental design can easily find yourself testing the wrong things or optimizing the short term.

2) Your decision/choice involves other people needing to line up and agree in order for it to work. These are choices that are highly contextual so difficult to talk about abstractly. In fact most books and articles on this topic focus on designing a process to make a decision and I have never been a fan of those. You can read about a bunch of these on Responsibility Assignment Matrix.

Big companies love these. I used to refer to these as non-decision making tools. In a team environment this challenge (eg you need dev and ops and product to agree on something) always result in people wanting to know “who decides” and of course it is natural for the default to be the CEO. The decision-making process, therefore, is gummed up by default.

Any process that is about anointing a winner, the decision-maker, is always subject to high failure rate due to people not being motivated to succeed because they didn’t get picked or don’t like the way it was decided. In important choices when people have already expressed a view then you anoint someone to decide, as a leader you know the outcome because opinion was expressed but all you did was dodge deciding on your own. If as the CEO you decide, but have also expressed strong opinions along the way then the team will tend to view a decision-making process as more theater than practice. So just decide and don’t wait.

Generally my answer to these choices is that “the leadership group decides and the only thing we’re not going to do is compromise until no one is happy”. If you look at Congress they specialize in making suboptimal choices because they value compromise and deals above all. I find that very frustrating.

It is also the case that when everyone is exhausted and someone says “we agree to disagree” then it is equally important to recognize “that’s not a thing”. You have to work it until people come to agree on a path even if they know it has flaws and you do that by showing that another path also has flaws. As a leader your job is to make sure the flaws are surfaced and no one thinks “I’m perfect” and you point out not doing anything is a bigger failure.

3) Well, it could be both [see what I did there]. Well it turns out most complicated things are both uncertain and involve multiple people. So you should do both 1) and 2) :-)

Responsiveness to teammates

In your question, I feel the second point is (to me) more about the specifics of a leader and how you personally manage time. I love that you asked that because you have clearly been thinking about how to save time and be efficient for a long time :-).

What many don’t like is that the key to being responsive is not scheduling your whole day. The best way to be responsive is to have time to respond.

There’s a chapter in our book One Strategy which discusses this to a good degree using posts that look at my schedule and where I spend time. I used to do an pie chart based on my Outlook calendar every year and share it with the team :-)

What many don’t like is that the key to being responsive is not scheduling your whole day. The best way to be responsive is to have time to respond.

In startups I work with I see two extremes. I see CEOs who literally run a fully scheduled day, going from meeting to meeting, call to call. I see CEOs who “hate meetings” and essentially run almost entirely interrupt driven. There’s no correlation to stage, success, category, or anything. It is a personality type.

Context, style, domain, and environmental factors all matter. I know for sure that running fully scheduled (including scheduling stuff like “email time” or “exercise”) really doesn’t work because the human brain cannot sustain work like this when the work is somewhat unbounded (eg your whole life). In addition, I’ve seen a lot of guilt associated with over-scheduling while also missing important or spontaneous things. In bursts you can run like this but really only when there’s a clear and finite mission.

Back to astronauts — moon missions had a minute by minute schedule for the 8–12 days they lasted. But the space station is run much more like a normal job because they are up there for a year.

So what to do? I think you balance by having ample time to explore and encourage ad hoc connections to the team. This lets you be interrupt/crisis driven during each day. At the same time you want a rhythm with the team so people know what to expect when.

Because most founders/startups hate meetings, I am surprised at how few have regular gatherings where people are free to talk about their work and share. While it is true most know what everyone else is doing, but at the same time my experience is that with as few as 5 people there can be a disconnect. Scrum stand ups and stuff are not a substitute because those are goal-oriented and frustration quickly surfaces with non-core contributions.

One of the most important tools is a regularly scheduled 1:1. In a startup < 10 people I think that is with everyone at least every other week or weekly for 30 min. After 10 people or when you have a management layer it is directs every week and rest of team on some interval depending.

My final thought on this is that as the CEO you are the bottleneck because you are the default decision-maker. But you can also tune the org so you can be much less of one. Two things to possibly do:

1. If someone is asking you to decide, the first decision to make is if you should be deciding or not. It is rather liberating to just say “wait, I hired you and you’re smart, so what do you think is best” and turn an ask into a dialog about getting the person to express their framework and owning the decision. You don’t have to decide everything. Most things are not existential.
2. By not being fully scheduled you can take inbound requests for opinions, input, etc and clear them in nearly real time. That’s probably the thing that surprises people the most when I talk about this. The fastest way to respond is to…respond. What I think about is that as the boss you’re blocking things from happening (by default) so the faster you can move the problem/decision/action to someone else who will just do something the better everyone is. The only thing you know for sure is that something sitting in your inbox is absolutely not being acted on by anyone.

Phew…how’s that for a long reply?

— steven (@stevesi)

PS: Maybe I’ll get some good email questions and the answers will end up here?