I swear to god, every time I read a post by Jason, I wish he was my manager. I consider myself a highly productive person, but constantly hampered, directly and indirectly, by terrible managers. Jason always comes off as the kind of person that amplifies the abilities of his team. That is all...I'm gushing and its embarrassing.
The problem is that the engineer's "I don't know" gets beaten out of you when you speak to users and investors. You get made to feel like an amateur for admitting uncertainty. Which is absurd in the startup world of all places. So it's one of those doublethink situations, where you need to keep your internal accounting separate from the marketing talk. And then you need to know who to tell what on top of that. And then actually deal with the actual uncertainty on top of that. As if startups weren't hard enough in general, we're making it even worse for ourselves.
Those are probably users and/or investors you're better off not having. Conversely, answering "we're not sure, but here are some parameters of the situation / dimensions" suggests you're at least cognizant of the area.
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.
A lot of people have the situational acumen to know when seeming to admit flat ignorance is a bad idea.
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.
When I worked as a hospital tech, I was the 'user' of a few sales reps. My favourite sales rep was the guy who would say "I don't know" or "I can't tell you", and jot down the question in his notebook to find out and return with. He didn't always return (can't have everything, I guess), but "I don't know but will find out for you" was far superior to me as a user than the usual sales misdirection or bullshit.
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.
It's interesting that you brought that up. As a westerner, I admit I don't have a great understanding of eastern cultures outside of the few movies I've seen. One stereotype, which I'd like some real clarification on, is the Chinese or Japanese societal culture of "saving face", or honor code. Could you give some insight on that cultural facet and how it pertains to knowledge/humility? I remember after the Fukushima incident, there was some talk of the officials' honor preventing them from admitting things were as bad as they were, making the entire situation worse. Is this pervasive as I'm led to believe? Would this come up in interviews and professional careers? Does it hinder our advances in technology?
Just because someone is from India, it doesn't mean they know everything about (incredibly diverse) cultures from every other country on the same continent. It's like asking an American of the culture of Brazil.
Where is it stated that nsomaru is from India? The insensitive/tragic note here is that you've assumed that because someone has knowledge of a region, then they are from that region.
> [Hears X is from country Y] "Oh do you know bob?"
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.
With smaller countries and specific industries this gets scary close to the truth: If I ever hear about another Finn from a person here in San Francisco, my first reaction is to ask the full name in case I know them - and in surprisingly many cases I do. World is a small place when you're part of a community.
You've got an interesting perspective on "The East". My favorite comment on the subject:
"""
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?
It's not just "I don't know" that is important, but also the next part of the thought: "but I can find out."
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.
I happen to be in Army Officer Candidate School at the moment, and this is how the majority of the selection and training process works. A lot of pressure for people to answer things right now, but most of us don't actually know the answer. Without fail, the most motivated and successful candidates are the ones who say "Sir, Officer Candidate ______, I don't know but I will have an answer to you by [hack time]."
Reminds me of the (probably apocryphal) story about the military officer test that asks "How do you dig up a ditch?" where most candidates answer with detailed instructions about how dig it, when the "correct" answer is something like "I say, 'Private, dig me a ditch!'"
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.
How can one know how long it will take to get an answer? That's just a lie of bravado, a pressure-driven estimate. It's horrible in a business environment. What happens is the person will give the first answer that makes sense, which, while the answer may be correct, discourages deep analysis of the problem.
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."
So how do you handle any sort of software development planning? Do you just tell the client "It'll be done eventually. I'll let you know when.", or would you accept that reply from your employees?
That's why agile is used: We'll show you what we have at an agreed upon time (1 week, 2 weeks, 6 weeks, whatever) and you can say "that's fine keep going" or "hmmm, we should change direction."
But even with agile, you have to have some kind of idea how long an overall project might take, otherwise how do you even decide if a project is worth starting?
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.
> But even with agile, you have to have some kind of idea how long an overall project might take, otherwise how do you even decide if a project is worth starting?
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.
I try to avoid giving time estimates where possible as well. In practice sometimes you have to, though, and if you have said "I'll have the answer by tomorrow" and tomorrow comes and this turns out not to be the case, you say something along the lines of: This turns out to be a trickier problem than met the eye; here's what I've found out so far; do you want me to keep looking for a solution?
I work at a large bank (trillions in deposits). When I am asked to give an estimate, I say: "I haven't done the estimate yet."
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.
If you need to make good-enough decisions on the spot, you need to have people be willing to take responsibility for being wrong, and they need to have decent information available (the decision-maker needs the information, not some other person somewhere else--in companies, information is hoarded horribly).
There is an important distinction between making an estimate on the spot based on reasonable expectations of the problem ,I am 90% confident I can have switch panel wired in 6 hrs. Verses, I have no clue and need to spend 3 hrs just analyzing the problem before estimating the difficulty.
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
On projects that went well, we put concerted effort into mitigating the above failure modes. Being wrong or not knowing is OK, being wrong or not knowing AND NOT fixing it is a huge problem. These issues don't come out of nowhere, there are precursors and warnings far in advance of emergency situations.
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.
I think this is so absurdly overrated. It's like forcing a toddler to say thank you. "Now, subordinate/rival, What do we say?? I didn't hear the magic words! We need to find out, mmkay? Can you say you can find out?"
You have a point (valid every time someone details the structured behavior he expects of other human beings), but you need people with initiative and positive thinking who can assume control of a situation outside their comfort zone. I'd go nuts working with someone who responded to issues with just "I don't know".
This reminds me of what a good PHP dev told me once - he interviewed a bunch of candidates for a company before as a favor, asking a bunch of specific tough domain questions. Almost all of the candidates tried to spew a bunch of nonsense & wiggle their way through them, but only one candidate had the confidence to tell him each time that "I don't know, I would google it". That was the candidate that got hired, and when that person asked down the line why he was picked, the person who interviewed him told him that he was the only candidate to not bullshit him and tell him the answer that reflected how software engineers think.
There is value in people who can tell upfront what their thoughts are, since they are identifying where there are potential problems.
"While there are lots of tactics, there is no one true silver bullet. "
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.
I really like this idea and try to apply it as much as possible. In my experience, for any kind of teamwork, the faster we get to the "I don't knows", the faster we solve problems, while stating half-truths/guesses-as-facts spreads confusion and kills productivity. I've also noticed that the type of person who is afraid to admit knowledge gaps is usually also the one who looks at me funny or expresses disapproval whenever I use the phrase. It's as if they are confused as to why I would ever admit such weakness.
As one of those people who rarely says "I don't know", let me offer a different view: saying "I don't know" is negative and gets you nowhere. Instead of saying "I don't know", say what you do know. Then you're a step closer to understanding than anyone who said "I don't know"; and you're likely to be several steps ahead by the time they get over that hesitation.
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 hate that. And after I worked as analyst, I started to hate that even more.
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.
You're treating knowledge as a binary, which it isn't. My way deals more gracefully with thinking you know and being wrong: since you always say what you know, but allow that it may be just a guess, you're always prepared to back off and rethink it. But if you treat knowledge as yes/no, then when you think you know and you say that "yes", you're ready to go full-steam ahead and you're less likely to turn back, since you already "decided" that "I don't know" wasn't the answer.
I hate to point this out, but when he was running for Governor, Jesse Ventura used to say it all the time. I remember in several of the debates when asked tough economic questions.
"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.
If he got elected and that worked for him, then awesome, but I could understand why many people would take issue with that way of answering questions.
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.
Politicians don't say anything useful because everything they say is fodder for the media to find something to excerpt, distort, and then replay endlessly out of context as an attack. The media has forced politicians not to say anything.
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)
A surprisingly large number of people would actually be turned off by a Politician who says I don't know.
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.
There was a comment about Hilary in those Clinton papers that just got released along the lines of "Stop just answering the question asked. It's good manners but bad politics."
> Kiran explained that he likes it when people say I don’t know because it lends credibility to everything else that they’ve said.
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.
Good point, and I agree, I also enjoy working with people who can admit when they just don't know something. It shouldn't be so hard to do, there is a nearly infinite amount of stuff each of us doesn't know -- especially when it comes to forward looking challenges we just haven't started thinking concretely about yet. My favorite response when asked about such things is "I'm not sure; we'll burn that bridge when we get to it".
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.
While the point of the article isn't the domain problem, I'll add that the hardest management job I've had was trying to retroactively fix a data aggregation process that had been built manually over many years.
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.
I like to think of this as being "confident in your ignorance." Whether you're a manager or early in your career, the way in which you admit what you don't know and ask clarifying questions can have a profound impact.
If I don't know something I've made it a point to tell them that.
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.
I'm slightly exasperated with this mythical cultural fit being used as the end all quality you seek in your potential employee. If someone can please spare some time to write a no-nonsense definition so that even an alien could understand I'll be grateful. All I ever get are hand-wavy explanations.
