You are a non-technical manager for a team of programmers or other highly skilled domain experts. You sometimes have some difficulties “speaking the same language” as your team and sometimes that means things don’t go well.

Here is an introductory checklist of some questions to get you started on getting the answers that will actually help you get the information you need to do your job well. These are things you should expect your team to be able to answer in a way that you can understand, so that you can have the confidence you need to say yes or no to the right things.

You need to communicate that you expect all answers to be in plain English (or whatever language you’re speaking.) Stop if there is anything at all you do not understand. Not “I have an idea of how it works…” but actual understanding. If you don’t understand, you’re speaking at the wrong level in the conversation and you’re going to get snowed. Making sure you’re communicating well is your responsibility as manager.

Let’s assume you have a team of programmers. What should you be asking?

Understand the problem

☐ Ask: What problem are you actually trying to solve? No metaphors (“It’s like a car…”). Expect the people on your team to describe the actual, concrete problem they want to solve for the benefit of a specific person or group. Describe it from that person or group’s point of view. Is it an iteration problem? Is it a usability problem? Is it a problem of meeting expectations? These things are all things you can quantify and verify. Unless you have a satisfactory answer to this question, you do not move on with any project, no matter how small it seems.

☐ Ask: What is one concrete example of a problem this will solve? A trap a lot of technical people can fall into is wanting to create something simply because it’s interesting, not because it’s actually useful in any way. If you don’t have a satisfactory answer to even one problem that could be practically solved, then it’s at best considered research. Perhaps you can make room for research and that’s fine. But you need to know that’s what it is. And not put it into production.

☐ Ask: Who specifically will represent the users of this system? You should expect your team to tell you who they are actually creating something for. Who will directly benefit from the work. And a real life individual person they will consult with on questions and who can verify it meets their expectations, at least. If your team is working in a vacuum, it’s a sure sign they’re working on the wrong thing.

☐ Ask: What are the platform constraints? What you don’t want to happen: You discover only when you try to ship on a particular platform that it doesn’t work and was never intended to work. Or, that you spent twice as long creating a solution that would work on platforms that will never be used or tested. Regardless of what anyone may try to tell you, you have a finite set of platform constraints. “Everything” is nonsense. Enumerate what is expected to work well. Is it for PC desktop? What are the minimum specs for all the hardware? Is it for the browser? Which browsers? What versions? What hardware will those be running on? Is it custom hardware? What CPUs, GPUs, OSs, other software, performance characteristics of peripherals, networking, etc. Get answers that are as specific and thorough as possible. Create the list because you have to make sure it all gets tested.

☐ Ask: What are the memory constraints? Memory access is the most common real bottleneck in any software system. Understanding the deeper issues is well beyond this simple introduction, but you should at least expect to have an answer to how much memory will be needed. Memory on real hardware is not infinite. What are the limits? Is it a fixed amount or does it depend on what’s happening in the system? What are the real limits of the system, given the various platform limits outlined above? If you can’t get satisfactory answers to these questions, send it back to the drawing board.

☐ Ask: What are the performance constraints? Every system has performance requirements. They’re either explicit or will surprise you when you’re not ready. What are the exact performance requirements for this problem? Would it be acceptable if it took a week to calculate or 20 minutes to open the application? Does it need to happen in 30 seconds or 5 milliseconds or 100 microseconds? There is an acceptable upper bound and you need to have absolute clarity on what that is. If your team can’t answer this now, then whatever they do design will inevitably fail to meet the unarticulated real world constraints at some point.

There are also some phrases you should aware of that are red flags and generally very good signals of bullshitery. When someone on your team says…

It means: I don’t understand the constraints of the actual problem, so I’m going to design an even bigger problem that we have no way of verifying the efficacy of.

It means: I’m not interested in solving the actual problem, so I’m going to create something else so that the person that actually will solve the problem has to also fix the problems in my stuff on top of that.

It means: I literally have not spent two seconds thinking about what platforms this will obviously not work for.

It means: I believe in fairies.