I don't know(blog.42floors.com) |
I don't know(blog.42floors.com) |
There's also the case of implausible ignorance: the "I don't recall" defense popular in politics and business PR-speak. This tends to decrease credibility.
If you're not sure about a particular fact, make an educated guess if you can or relate what you can from memory, and say, "I'll have to check on that and get back to you," then actually check on it and get back to your questioner or the audience later.
It really depends on who your users are, I guess. The general public aren't particularly grateful as a whole, but niche users tend to be more understanding.
Thus, counter-intuitively, saying 'I don't know' is an indicator of the speaker's knowledge, as he is aware of areas of his ignorance.
Contrast with an arrogant attitude of "I-know-everything-or-can-find-it-out" and the fuck-ups that inevitably follow.
Aside: I would really like to know what the solution to keeping the listings updated was. Or, is that a trade secret? ;)
edit: s/Aide/Aside
"""
In 1982, however, immigrant Indian and Pakistani businessmen, looking for low interest SBA loans and affirmative action in government contracting, talked the Reagan Administration into reclassifying them from white/Caucasian to Asian/Oriental, even though grouping Indians with Chinese rather than with Afghans makes little sense from the standpoint of physical, genetic, linguistic, or cultural anthropology.
"""
What was it about India that made you think it made sense to ask about China and Japan?
Just admitting you don't know is great, but it's not good enough. You have to also be able to take the next step and find out.
If I ask two people if they know how to do something, and one of them says "I don't know" and the other says "I don't know, but I can find out," then... well, I don't really need to complete that thought. You can see the difference right there.
But other than that, Jason is spot on. This is something I've been keeping an eye out for for years. When I interview people, I ask a question, and when they're clearly bullshitting me, I'll stop them and say, "It's okay if you don't know." The best candidates will often back down, like Jason did in his example, and say "Yeah, I don't really know, but I'll figure it out."
Bullshitting me with an answer isn't a red flag. It means you're at least thinking about the problem. But admitting you don't know but are willing to figure it out is a far, far superior answer. Very few real-world problems demand an answer RIGHT NOW. Most can wait until some research is done.
There is value in people who can tell upfront what their thoughts are, since they are identifying where there are potential problems.
I'm old enough to have worked with Coldwell Banker when they rolled out their commercial real estate operations on the East Coast (they had been only a west coast company at first).
What they did was assign a college student (typically on summer break or part time) to go out to each area and literally catalog all the commercial office space for part of the time and then the rest they would spend in the office calling up the building owner (or manager) and verifying the data collected.
This was many years ago but it worked quite well. A database was compiled and updated.
Bottom line is no matter how you cut this is a manual process.
You know why the yellow pages was such a success? Relevant data that while it came out 1 time per year typically was highly accurate for that year.
They made enough money (by selling advertising to a captive audience) that they were able to employ an entire quality checking and sales organization to verify and collect the data which ended up in a product that was widely used up until the internet came along. But once again they had the profit margin and captive audience to make the whole process work and that was a key part of that success.
Now, guesses should never be presented as absolute facts, but having a guess puts you much closer to the truth than having nothing. If you really, truly have nothing, no relevant knowledge---which should rarely happen if you're well-educated and/or experienced, in which case you're a novice to the subject, where somewhat different rules apply---then say so; otherwise, go with what you know and learn the rest on the way. Will mistakes sometimes happen? Will you sometimes head down dead-ends? Absolutely, but that's part of the learning process and we shouldn't be afraid of mistakes, as long as we're in a process which is tolerant of them. (If you're pushing code to production, for example, then that's a time either to know or not to know, not to guess. But that's the end of the process, not when you're asking questions.)
So if you said to me, "I don't know", I might look at you funny because it's probably not true: you probably do know, at least partially; it just seems like you're not willing to acknowledge that.
I'd take that a step further, and say that people who assign proper levels of certainty to their beliefs tend to be credible. Most people seem to only be able to think in absolutes.
This topic is even more relevant for software over other types of knowledge, IMO, keeping in mind the Knuth quote "Beware of bugs in the above code; I have only proved it correct, not tried it".
Even when I'm pretty sure that task XYZ can be completed relatively easily using language A, framework B and API C, I still won't answer in complete absolutes unless I've worked on the compiler for A, written a fair amount of B, and previously exhausted all the functionality of C.
Also, don't look at people's plans, look at their criteria.
Lots of people do not like to hear "I don't know".
The work was extraordinarily tedious, error prone, yet business critical. We had to keep shimming in new parts of the system, while keeping the old system afloat. While the system was always on the verge of imploding, from the outside, it basically appeared to work, which kept the project chronically understaffed.
I have a lot respect for anyone who aggregates time critical production data from different sources. The nature of the work makes it extremely stressful, yet surprisingly easy for outsiders to underestimate.
Generally, I follow it up by letting whomever know that I can attempt to discover an answer to the question.
If the question is about how something works, I'll occasionally explain how I think it might work based on how I'd implement it, but again advise that it's just a guess and I really do not know.
By contrast up front evidence of defensive behavior is a red flag for me in all sorts of situations.
The point being that, at that level, it's more important to know how to deploy your soldiers toward a goal as opposed to the low-level details of every individual task.
I never give estimates, to the great fury of my boss, but I told him I don't want to lie.
Lying is unethical, and accepting a lie, or not calling out a liar, is encouraging unethical behavior.
If someone tells me: "I'll have an answer, or: be done with the work, by a certain date/time, I shake my head, then reply: "Don't make promises. Just let me know when it's done."
This isn't about asking someone else to find out how to do it, this is about solving a problem, which may no solution.
So saying, "but I can find out" it is comically ridiculous.
Consider this, how are you going to solve the traveling salesman problem, for 10,000 nodes on your iPhone in 5 seconds?
I don't know, but I can find out.
Just say "I do not know" and do not waste your and my time with monologues full of guesses and sort-of-related-but-not-relevant info. It does not help. It just wastes time.
If you say, "I do not know" we can work on it. We can file it as an open question until you know. We can ask somebody else or search for information.
And btw, the answer to "Will mistakes sometimes happen" question is: guesses cause them very often and they slow analysis a lot. You just do not see it, because I can not go to you and show you all your wrong guess mistakes. I have to smile and pretend that I trust you while triple checking everything you say which again, slow down analysis.
Working with people able to say "I do not know" is way easier and faster.
"I don't have the answer to your question, but I know if I'm elected, I'll appoint the brightest economic people I can find to solve the problem."
As opposed to other candidates who either talked along party lines and said they would tax the rich or give tax breaks to businesses and rich people.
I still feel like it was one of the most important things he said that got him elected. He never acted like he had all the answers.
When it comes to politics, a lot of people aren't looking to elect someone for their decision-making ability. They're looking to elect someone who is making the same decisions that they've made. For instance, people don't want a candidate who will "investigate whether universal healthcare is a good idea". The people have already decided whether or not it is, and they want someone who will agree with them.
In addition, not having a hardened position on something could mean that you intend to compromise with the opposition on that issue in order to appeal to more voters.
Qu'on me donne six lignes écrites de la main
du plus honnête homme, j'y trouverai de quoi
le faire pendre.
If you give me six lines written by the hand of
the most honest of men, I will find something in
them which will hang him.
-- Cardinal Richelieu (attributed)One thing I realized very quickly while doing some volunteer work - when the guy in charge (or running to be in charge) says I do not know - people react as if they have lost all confidence in him/her despite understanding that not everyone can know everything.
so caveat emptor on preaching that.
It's along the same lines as:
[Hears X is from country Y] "Oh do you know bob?"
whether he is indian or he only knows about Indian culture, it is a stretch to say "so you must know about Japan!"
Which is an entirely reasonable question, because if X from country Y is at the same party as you, then there's a good chance he might know your friend Bob. It's a small world, they say.
Estimating is hard, but it's an estimate. Problems usually arise when one gives an estimate of 'X days' and what the manager hears is 'It will take X days, and no longer.'
An estimate will increase in accuracy the more you know, so if you don't feel comfortable giving an estimate, ask the question: "What information do I need to know to give me comfort for an estimate of Y% accuracy" and ask more questions.
When they say "How long will it take to do the estimate?" I reply: "I have no idea until I get into the details of the problem."
When management asks for an estimate, with rare exceptions, they actually mean: "We are putting pressure on you to get this done by a certain date, but we don't want to tell you what that date is, and we're betting that if you give us a low estimate now, you'll pressure yourself to meet your own deadline, and we won't have to manage the project."
The problem with that type of reasoning is that in the end, the workers are stressed, and the solution is suboptimal.
That may be so, but the military environment is different. Officers need to be able to make good-enough decisions on the spot, without the benefit of careful consideration, because there might be a literal dead line, after which people die. Sometimes being in motion is more important than the actual direction.
I have been thinking about this a lot over the past months, most teams and projects fail because people get in over their head by
* Not analyzing the problem deeply enough (hrs not weeks)
* Estimating too early, they don't want to look weak
* Not revising estimates once they are in it (heroic save)
* Not asking for help or re-analysis from outside minds
As a poster above mentioned, accepting a bullshit answer is being complicit in a lie. We need to push back in a polite way when we are being bullshitted. By accepting poor estimates (in all the dimensions of poor) we enable failure.
If each iteration is producing sufficient independent business value (e.g., not dependent on subsequent iterations), then you don't have to estimate the size of the "overall project" to determine if it is worth starting. That's actually a key part of the risk mitigation provided by agile/lean methods.