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.
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."
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.
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.
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.
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.