# Out of your depth *What to do when you don't have all the answers* --- Sooner or later you'll be accountable for a part of the business you've never worked in, and the updates will come in a language you only half speak. When something sounds technical, it's tempting to stop asking questions, partly because you assume there's thinking behind it that you can't see, and partly because you don't want to look stupid in front of your team. I've done that more than once, and it's almost always been a mistake. The usual advice is to ask anyway. That helps, because explaining a plan to someone outside the field often shows whether it has been thought through. But you still have to judge the answer, and if you don't know the area it's hard to tell whether someone knows what they're talking about or just sounds as if they do. So instead of judging the person, judge the plan. What helps is getting the plan put in terms you can check without knowing the field: what the business will be able to do when the work is finished, what has to go right along the way, and how similar work has gone before. The plainest test is what the work will let the business do once it's finished. Every field has its own vocabulary, and the words that cause most trouble are the ordinary ones that everyone assumes they share, like "finished". On one project, not pinning down what "finished" meant cost us a year of selling. The plan said we needed some new functionality before we could sell into a new market, and I didn't dig any further. What sales needed before they could sell and what development had committed to build turned out to be different things, and the gap only showed up later. Asking each side to finish a plain sentence, such as "when this is done, we'll be able to sell to these customers", could have shown it sooner. You don't need to know how the software is built to see whether two teams finish that sentence the same way. What has to go right comes out of plain questions too: what happens in the worst case at a particular stage, or what one piece of work is waiting on. As with the "finished" sentence, ask two people separately and compare their answers. Where their answers differ shows you and the team which assumptions the plan leans on most, and where the risk sits. Most work like this has been done before in some form, by this team or one like it, so ask about that record: how long it took against the plan, what went wrong, and what surprised people. Projects [[What estimates mean|tend to run long]], and that record tells you by how much. Where it went wrong before is where to put milestones this time, and how far it slipped tells you how often to review progress. ---