A former Google exec on how to make tough decisions quickly
qz.com
qz.com
https://news.ycombinator.com/item?id=9953526
and
https://news.ycombinator.com/item?id=9923239
The general HN feeling on those occasions, broadly speaking, was that this is ridiculous.
Usually worked well ( except when C-levels were invoked to over-ride ) and saved us from a lot of half-arsed unplanned work at silly hours. And all the post facto refactoring that would involve.
Her mindset was that positive answers could only be made when there had been sufficient internal discussion with all the facts present.
Then put that on the roadmap.
I've found in my career that there are very few people who want things done on extremely short notice with short deadlines for shits and giggles. Most of the time they are responding to some external (or higher level internal) pressure. Even if it is due to less than ideal planning, they are typically aware that they are asking a lot.
Of course, that is in reasonable work environments.
The problem is that once other actors realize that this is how you operate, the question immediately becomes "how do we override this person's decision".
Aside from just accumulating enough influence to make your positions stick, I'm not sure what the best approach - maybe it's necessary to give the impression you'll agree to some of those unrealistic questions merely to stay in the decision making loop.
Eaxctly so!
But the fact that they had to go up through officer levels to achieve that usually acted as a restraint, as quite often the senior exec would ask "tell me how you screwed-up this project so badly that you need another team to save your bacon"
It also bought us some time to work-out what exactly was the question and how to solve it!
Ah the greatest luxury of corporate life; time for thinking.
Sadly, she moved on and up and we received a new manager who jumped at the word 'firedrill'. "Yessir I'll deploy my men!" type of response, every time.
Can a developer on Kansas City team not ask a seemingly straight-forward question about the current implementation of a service that the Memphis team runs? What would you say if you sent an instant message or an email to someone in another team and instead of getting a reply from them, you hear back nothing at all and one week later your boss says he is forwarding an email sent by another manager which includes the answer to your question (nothing secret, just details that we needed to know in the first place). Now apparently, the person I asked the question just forwarded the question to their manager with the answer. Their manager, being on vacation, couldn't forward the email for a week.
What would you do next time you had a question? Would you contact your manager and have them contact the other team's manager and have them contact the project lead to answer a question? Or would you try to design your system so you had to interact with the Memphis team as little as possible?
I've been on both sides of that question. It doesn't always end well.
Suddenly Tim looked back at Sabih and asked,
‘Why are you still here?’ Sabih left the
meeting immediately, drove directly to San
Francisco Airport, got on the next flight
to China without even a change of clothes.
But you can bet that problem was resolved
fast.
So much of this sounds like managerial bullshit, to be honest. "He got on the plane straight to China and made it work like the Ayn Rand superman he truly is! You skill workers can learn a lot from this!"
Beyond that, the story read to me less like "a funny story about my old pal Sabih Khan" and more like "here's how much of a dick Tim Cook is". If you think saying “This is bad. Someone ought to get over there.” in the middle of a meeting and then later in that same meeting, feel compelled to single out a specific person and ask "Why are you still here?", then you are a dick. Being purposefully vague on the who and the when to then thirty minutes later single someone out for not doing something is a dick move.
On the other hand, there's this alternate quote: 'Thirty-minutes in the meeting he chided Sabih Khan, the then operations executive, saying "Why are you still here?"' [1] But, the actual source is "an anecdote reported by CNN", which might be this quote: 'Thirty minutes into that meeting Cook looked at Sabih Khan, a key operations executive, and abruptly asked, without a trace of emotion, "Why are you still here?"' [2] So, was it emotionless or chiding? Merely abrupt or rebuking? I'm interested in this because it's a case study of problems with (modern?) journalism, where one journo gets an actual quote, boils it down to a paragraph, then everyone else has to mince that up into something interesting and not plagiarised, which continues ad nauseum (in this case becoming a legendary story about an exec, inviting embellishments) until hardly anything of the true meaning is left. I kinda wish the people who have no more actual information than an intelligent search-engine-user would get out of the way so the rest of us could just read the primary source.
[1] http://s4.ibtimes.com/tim-cook-man-apple-ceo-steve-jobs-trus... [2] https://web.archive.org/web/20081206032107/http://money.cnn....
"Let's all celebrate the the worker bee who dropped their life's obligations and went to China one afternoon!"
No. Rash decisions are typically stupid decisions, and forcing one of your employees to go to China is a stupid decision. Frankly, it's also stupid to abide by that kind of stupidity-- abiding by stupidity is dangerous.
Good manager could be more specific, WHO ought to get over there?
Money solves an amazing number of logistical problems like that, and if you're an executive who flies around the world checking up on billion dollar supply contracts, money likely isn't an issue.
- Say, "We’re going to make this decision before we leave the room." (And do it.)
- Begin every decision-making process by considering how much time and effort that decision is worth, who needs to have input, and when you’ll have an answer.
- Internalize how irreversible, fatal, or non-fatal a decision may be. (And get comfortable with it.)
- Give important decisions 24 hours, even if you think you know the answer.
- Know when to end debate and make a decision. Use your "CEO prerogative" sparingly but decisively.
- Gauge comfort to get to the right speed: low-level discomfort (stretching) is good.
Then execute on those decisions. (This is the second half of the article.)
I think on the surface this kind of a decision is a fantastic quick, touch decision, and one that fast-moving, risk-taking, companies can quickly try and implement. Unfortunately for Google, sometimes making tough decisions quickly is the wrong kind of quick.
Of course, all of my friends are on YouTube or Gmail. But I'm not social networking with them on Google+. Something was missing.
Having Snowden's disclosures hit in the midst of that didn't help either.
Er... what? In what world is this a universal truth?
Another version of this quote often attributed to Eisenhower is "Plans are worthless, but planning is essential."
I honestly love it.
Site redesigns occasionally make the front page, I don't remember Quartz's ever doing so.
>Maybe you tell them that you used to work with a competitor who was quite speedy
>I highly recommend this over a brute force method of escalating things to the person’s manager or throwing competition in their face.
Seems contradictory.
I'd also point out that questions and comments like:
>Can you help me understand why something would take so long?
>Hey we’re really betting heavily on this, and we really need you guys to deliver.
>Are we working as smartly as we can?
when directed at someone, can be vague and off-putting without some valid specificity behind them.
is the weirdest logical statement.
Sounds like a great organization - the person implementing something, who has the most knowledge of how long it will take to implement, needs to be "challenged" by someone who has no clue about how to implement what they are asking for or how long it will take. What they are describing is a broken organization, or the beginnings of behavior that will break an organization.
I mean, it's fine to say we need to prioritize implementing certain elements of business logic, so we'll shrink the project scope so that those elements will be implemented faster. But to advise people to "habitually" "challenge" every schedule given by implementers is pathological behavior. It can work for a few months, but then the people doing the work get burned out and leave.
I have seen shops with confident IT managers who are not afraid to say "no" to unreasonable requests and deadlines, with a solid team of programmers and admins who have worked together for a while and get along, who have stayed at the company for a while and who have executed well on many projects together, with clean code bases and solid infrastructure, and who generally work forty hour work weeks, with the occasional marathon before a big release, or if things are breaking.
I have also seen shops with browbeaten IT managers, often new to the job, who are overrun by their bosses and business unit managers, with an IT team with a lot of turnover (except maybe 1 or 2 embittered people who have been there longer than the others), where people and departments are engaged in office politics, where projects have vague and ever-changing requirements, unrealistic deadlines, death march coding marathons by overworked coders, which are interrupted by putting out fires due to the code base with massive technical debt and broken infrastructure. These are the kinds of companies where the executive "habitually challenges" deadlines the weak IT manager gives him, who gives in and dumps the new unrealistic deadline on his team. This is the kind of company where a programmer is thrown into an existing project at the last minute, because the programmer who was working on it quit, and at your first meeting a Microsoft Project slide is shown and you're told that you're already three weeks behind schedule on your contribution.
Which of these two companies wind up succeeding, and which end up floundering or even failing?
(The only caveat I give to my own scenario, is that in companies where IT is not central to the business, they can often survive a broken IT department, when their core non-IT business is doing very well. Their company would work even better if they followed the rational scenario, but their broken IT department is not always fatal to the company when they're doing well in their core non-IT business.)