▲ 134 points
back
64 comments
Former discussion here
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.
One of my best managers had the default response of 'no' to any unexpected questions with unrealistic deadlines. Nothing flowery, just "no my team is not available to do that."
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.
I'd agree that's the right answer.
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.
> 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".
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.
The phrase I heard tossed around is "Your poor planning is not my emergency". It could probably be more nicely worded.
That stance can also backfire in the form of "OK you're too busy to help me so I'll hire outside contractors to do it instead." which leads to a bigger mess to sort out later. I try to at least offer a partial solution.
It's worth re-reading Hamming's "You and your research" to find where it appears (I just did and thought it was worth mentioning.)
I think this type of answer is great for "unexpected questions with unrealistic deadlines". I once had the misfortune of working with a manager on a team tasked with releasing our code into production. As release master, I'd email him on code complete, when the QE cycle finished, and when it was good for release. His response was always: "Our team is really busy right now, let's get together in two weeks and discuss".
That says more about your boss's (or her boss's) level of punch within the organization and horse sense about the seriousness of the issue.
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.
As someone who travels internationally for work, sometimes on short notice: yes, I generally carry my passport in my briefcase. Passports are important documents to be sure, but if you have one lost/stolen it's just an inconvenience. My company provides travel immigration assistance, so if I lost my passport on a business trip I could just call them and have a courier meet me at the airport with another the next day.
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.
> ... Tim said, “This is bad. Someone ought to get over there.” Thirty minutes went by and the conversation moved to other topics. Suddenly Tim looked back at Sabih and asked, ‘Why are you still here?’
Good manager could be more specific, WHO ought to get over there?
It's journalism, don't take the words for their literal meaning. He probably did go home, get some things, then head out to the airport the same day (assuming he already had a China visa). But that would sound boring in a news article now wouldn't it?
As a former management consultant - yes, I did this.
also, china doesnt do visa on arrival...
If you travel to China for work, you already have a multiple-entry visa.
Sounds like a nice stress free, paid 12 hour break lounging in first class to me.
What makes you think it would be stress free? That time is likely filled with frantic emails, phone calls, presentation building, spreadsheet analysis, etc. to make sure once you are there, things happen quickly and the way you need them to.
Not to mention his Visa. U.S. citizens must get visas before visiting. They can't just buy one after landing.
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!"
Maybe you can get a visa that covers a time period instead of a trip? If he's the guy that regularly goes out there once every week or two, and that's a possibe to get a visa like that, I imagine they would. Otherwise, maybe his assistant was frantically greasing the wheels for his arrival while he was on the plan.
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.
I don't disagree but you can now get a 10-year 'multiple entry' visa for China if you're a US business person, so as long as you have a passport, you're free to visit whenever you're needed.
This is the vibe I got as well.
"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.
Different google than the one i worked in, it took managers many quarters or even years to make big decisions. they needed tons of data and trends - by nature they are reactive to a fault. yet they run around talking about quick decisions making and being agile.. strange world it was.
There are many different Googles.
YMMV. One google manager cannot represent all of the thousands of managers at google.
Frankly, I think the tactical HOW part of this article is very light. There's much content on WHY it's a good idea and apocryphal anecdotes. Here's some actual advice I gleaned from the article:
- 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.)
This is how you make decisions quickly: "Fuckit, youtube is the biggest video site, gmail is the biggest mail server, and people have accounts on there! What's Facebook got that we don't! From now on errybody gets a Google+ account. Want to post on YouTube - bam, there's your real name. Do you have a gmail? Now you have Google+. Let's see Facebook compete with that! That's it, decision made. Go!"
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.
It does however make the person making those decisions look "dynamic" and "decisive", which means by the time the damage they have caused starts getting noticed they'll already have been promoted out of the blast zone.
In the end it didn't cost them anything though did it? They gave it a decent shot and ultimately perhaps the only other decision to take was not to try and make a social network at all.
Originally published here:
I loved this post. It makes a ton of great points, that resonate based on my experience. One of my favorite sayings is "90% of the decisions you make don't matter. For those, just pick. For the 10% use diligence."
> A good plan violently executed now is better than a perfect plan next week.
Er... what? In what world is this a universal truth?
In a world where situations are constantly changing. A good plan now can help make progress, while next week you'd still be debating what changes to make to the plan in light of new developments.
Another version of this quote often attributed to Eisenhower is "Plans are worthless, but planning is essential."
Seems like a re-phrasing of truisms cautioning against 'perfectionism' like, "perfect is the enemy of good." The idea behind these things is that perfectionists tend to overestimate how much actually needs to be done to achieve a goal. It is a form of the planning fallacy.
TLDR: Make decisions quickly.
Side note: I've never read it before, but Quartz is a supremely well-designed website.
It's funny because it doesn't have any of the usual gimmicks lay people associate with "well-designed". No parallax, GIFs or fancy effects. Just plain good design that focuses on usability.
I honestly love it.
Fixed headers and footers aside, it's tolerable on old Android mobile as well. Fairly effective design though, yes.
A lot of the general ideas here seem helpful. I just have some slight issues with the section on rallying support.
>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.
the key isn't "quickly", the key is to have knowledgeable and smart decision makers who do in 1 second the amount of mental work that would take other people orders of magnitude longer.
In most (large) firms it takes a week to have/schedule a meeting with those people. Most small firms don't have that amount of experience, or if they do its not accross a very broad base. So part of the story is about access to people, there is an extra layer of gatekeeping in there, by necessity needed to make sure those people are being used effectively.
Right. Quickly making incorrect decisions probably isn't so good.
so.. it takes experience
I quickly decided not to read this as it would just disrupt my philosophy of not painting myself into a corner.
> Google is fast. General Motors is slow. Startups are fast. Big companies are slow
All else being equal, XYZ makes a difference.
is the weirdest logical statement.
So basically the executive's job is to make snap decisions and crack the whip.
And then there's festina lente...
> Challenge the when...for items on your critical path, it’s always useful to challenge the due date. All it takes is asking the simplest question: “Why can’t this be done sooner?” Asking it methodically, reliably and habitually can have a profound impact on the speed of your organization.
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.)