Customer: Is my engine done yet?
Mechanic: Yes
C: Great, then I’m gonna drive home
M: The engine is done, but it’s still not back in the car
C: But you said it was done
M: Yeah, but not “done done”
Raise your hand if you’ve had similar interaction when working in tech. (but usually with a feedback loop of days or weeks, and maybe some awkward situations with customers or investors).
What often follows is an argument of what “done” means. And sometimes it’s fruitful. But other times it isn’t.
What’s the problem?
From a manager’s perspective:
- You ask if someone is done
- They say yes
- But the expectations you had about something were not met
After reading this you’ll know:
- How to ask better questions
- Why simply defining done isn’t enough
- Why you don’t have to ever ask if something is done
If you’re asking questions
Maybe it doesn’t matter what done means if you’re asking the right questions. Let’s see:
What just happened in the mechanic example above was shifting goal posts due to bad logic. The engine is indeed done, but that doesn’t imply that the car is ready to drive.
The person asking the question, due to not knowing enough about the matter at hand, made the assumption that “if the engine is ready then I can drive the car”, which is incorrect.
The engine is a part in a complex system and it being done doesn’t necessarily mean it’s working together with the rest. Much like software.
If you don’t understand something, like managers often don’t understand software. Don’t ask questions that don’t directly answer what you actually want to know.
The customer shouldn’t have asked whether the engine was done if he wanted to know whether he could drive the car home. The question to avoid all that miscommunication would have been “can I drive the car home yet?”.
If you’re the one asking questions. Ask what you want to know instead of asking questions that give you information you don’t really know what to do with. \ \ It’s one of those cases of “a little knowledge is a dangerous thing”.
Don’t be afraid to sound “dumb” by asking overly simple questions if they are exactly what you want to know.
If you want to know whether something is ready to demo to a customer. Which question is best?
- Is it done?
- Is this ready to demo to a customer?
If you chose 2), great!
Is this ready to demo to a customer?
Don’t ask if it’s “done”.
If you’re answering questions
Don’t take any questions at face value. If the answer to a question is something the person asking is unqualified to understand, ask them to rephrase. Ask them to ask exactly what they want to know from a business point-of-view.
In the mechanic example above, a more experienced mechanic might have answered “the engine is fixed but we still have to put it back into the car”, but then they give away more information for the customer to make even more incorrect conclusions, or worse, ask “oh how long will that take?” which would of course be answered with the dreaded “depends”.
The mechanic might have answered with a very conservative “no” because the engine might be fixed now, but other issues might be found when putting it back into the car.(which would affect how long it takes to put it back into the car).
The thing with hearing “no” very often when asking if something is done, is that then the complaint will be that things take too long to get done.
So, maybe. If you’re having meetings to discuss the definition of “done” you’re just not asking the right questions and expect a definition of a word to magically solve your issues.
Defining done in the right context
“Is it done?” is rarely asked without context. But the context matters. It matters who you ask it to, and what you mean by it. If you ask “Is the user story US-69420 done?”, and by “done” you mean its status, then, first of all, it’s a waste of someone’s attention. You can just GO to US-69420 in your task management system and check if that’s the status! gasp
However, this is the thing that needs defining. Done as a status for a task. And you never need to ask this, because you can go look at the task.
Case 1) I’m a developer and I’m done developing a feature. You ask me if I’m done. Well, my part is done, so I might say “yes”. But QA isn’t done, and it isn’t in production yet. So, I’m “done”, but the status of the task isn’t “done”.
Task statuses can be as complicated or as simple as you wish, but for the sake of brevity, let’s assume you have a basic one like this:
To do -> Doing -> Done
This is extremely simplified. In reality you may have some status related to QA, etc.
But anyway, this is the done you want to define.
As a business person, something being done, for you, probably means you can interact with it. If it’s only working on the developer’s computer, you can’t interact with it.
…but wait, yes you can. You can just go over to them and try it out. Does this mean it’s done? It’s not yet on the server.
Ok, then, as a business person, done means the customer can interact with it, and it’s probably on a server, and it’s probably tested.
TL;DR;
“Is it done” is a bad question. Ask more specific questions.
If the customer can use it, it’s done.
If you have to ask if something is done, you should probably open up your task management system to check for yourself and not interrupt someone’s thinking.
The status “done” should be defined. Not necessarily the word.