#2 “It depends” is the most honest answer you can get from an engineer

What engineers need to know before they can give a useful answer

Welcome to edition #2 of the LMT IoT newsletter! This time, we’re looking at a phrase anyone who works with engineers has probably heard: “It depends.”

It can sound frustrating when you need a clear answer. But why have those words become so common in the workspace? We asked Valters Skrastiņš, Hardware Technical Manager, Rūdolfs Arvīds Kalniņš, Firmware Engineer, and Arturs Lalovs, Head of IoT Business Unit, what’s hidden behind those two words.

There’s an inside joke that the 💯 emoji looks a little different to engineers: the number in their eyes is 99. “Nothing is ever truly 100% when you’re an engineer,” says Valters Skrastiņš, Hardware Technical Manager at LMT IoT.

He remembers studying circuit theory at university. At first, components were introduced through their intended functions: a resistor was a resistor, a capacitor was a capacitor, and an inductor was an inductor.

Then came the physical components. A real resistor also has some capacitance and inductance. Its behaviour is affected by tolerances, other components, and the environment around it.

The simplified model is useful. It just needs context. The same is true of many answers in engineering: before you can say whether something will work, you need to know what you want the intended outcome to beo, under which conditions, and what will affect it.

The question behind the question

Arturs Lalovs, Head of IoT Business Unit at LMT IoT, has been on both sides. He has said it himself, and he’s heard it while bringing customer questions to the engineering team.

One familiar example is: “How long will the battery last?”

“What sensor will it use? How often will it take a measurement? How often will it send data? What will the network coverage be like?” Arturs asks back. “There are a lot of factors involved.”

A battery-life estimate becomes useful once those conditions are defined. Then the team can ask how long the device is *likely* to run under a particular operating profile.

For someone making a product decision, “it depends” may feel like a delay. For the engineer, giving a number before those details are known could result in an unearned confidence in that number.

When he’s met with the “it depends” answer, his response is simple: “Depends on what?”

The next step is to identify the factors that would change the answer, agree on a set of assumptions, and work from there. The answer may still be an estimate, but now everyone knows what it’s based on.

Rūdolfs, a firmware engineer at LMT IoT, takes a similar approach. Before he starts building, he needs at least a general direction: what’s the goal, and what are the customer or his colleagues trying to achieve?

That doesn’t mean every detail has to be settled at the start. Requirements often become clearer when people see the first version of a solution.

He recalls building an internal tool for a small group to organise images and upload them to a website. It initially handled a modest amount of data. Later, he learned that it would need to handle a much larger collection, many uploads at once, and many more users. Those details changed how the tool needed to be designed.

The original question might have been, “Can you build a tool to upload images?” The more useful questions were: how many images, how many at once, and how many people will use it?

Rūdolfs sees the same principle in firmware. Consider a device that restarts: **does its data need to survive the restart?** If it does, the software needs a way to store and recover that data. If it does not, part of that work may be unnecessary.

It’s a small question with a large effect on the solution. It’s also easier in the long-run to answer these questions before the product has been designed, rather than after.

Rūdolfs doesn’t expect that every detail will be known at the get-go. People may discover what they need only after seeing what a first version can do. He favours keeping the conversation going: build enough to make the options concrete, show it, and ask what has changed.

 “It depends” is an honest answer when the conditions really do change the solution. But it becomes useful only when the conversation continues:

• Depends on what? 

• Which conditions matter most? 

• What can we assume for now, and what do we need to test?

The person making the decision may need an answer to plan the next step. The engineer needs to understand what the product must do before they can give one. Both have information the other needs.

Clearer questions help both sides move from “it depends” towards a decision they can stand behind.

Keep asking questions and keep talking!