I've spent the last ten years of my life working with developers, and sometimes speaking to developers feels like speaking an entirely different language.
For non-technical people, software can feel incredibly complex. There are systems behind systems, acronyms you've never heard before, and conversations where everyone seems to understand what's happening except you.
Ironically, the first step to understanding it is simplification.
1. Simplify before you try to understand everything
Imagine a developer tells you:
"The API is returning a 401 because the access token has expired and the refresh token isn't being persisted correctly."
If you're non-technical, there are suddenly five things in that sentence you might feel like you need to understand. API. 401. Access token. Refresh token. Persistence.
You don't.
Start with: what does this mean for the user?
"They're getting logged out when they shouldn't be."
Okay. Now you have something you can work with.
Then ask: what's causing that?
"We're failing to renew their session."
And then, if you actually need to know: what needs to change?
"We need to fix how the refresh token is stored."
The technical explanation hasn't disappeared. You've just put it into layers. You can go as deep as the conversation requires instead of trying to swallow the entire system in one go.
And don't be afraid to ask someone to explain something differently. "I don't understand" is a perfectly useful thing to say. Pretending you understand and making decisions based on something you've misunderstood is much less useful.
The goal is to understand what's happening, not to become the person who decides how to fix it.
2. Don't solutionise
There's a quote I always think about here:
I used to confidently tell people this was Henry Ford. Apparently Henry Ford never actually said it, which I discovered while writing this after quoting it for years. So that's great.
Whoever said it, though, had a point.
The idea isn't that customers are stupid or don't know what they want. It's that the person experiencing the problem isn't necessarily the person best placed to design the solution.
And when you're working with a developer, you're the customer. You know the problem. They know the system.
A client of mine started getting customers overseas, so they asked their developer for a time zone dropdown on the booking page. The developer built exactly that.
Here's what happened next.
A customer in New York picks New York from the dropdown, sees a 2pm slot, and books it. But the times on the page are still being rendered in the client's time zone, Dubai. So the 2pm the customer saw wasn't the 2pm they got.
The confirmation email came through in the customer's time zone, which made it look correct. Nobody had any reason to think something was wrong until people started joining calls at the wrong hour and the client sat waiting for customers who'd already been and gone.
The dropdown wasn't wrong. It just answered a question nobody had checked was the right one.
What the developer got was a solution.
What they needed was the problem:
We're suddenly selling into three countries, our customers are seeing times that don't match what they booked, and we don't know how far the issue goes.
Give a developer that, and they'll tell you the dropdown is the smallest part of it. Every time on the site, every automated email, every calendar invite has to render correctly for the person looking at it. That's a bigger job than it looks.
The same thing happens with less obviously technical problems.
You ask for an export button.
The developer asks why.
"Every Monday I export these records, copy four columns into another spreadsheet, format it, and email it to Finance."
Now the question isn't necessarily how to build a better export button.
It's: why are you doing any of that manually?
Maybe the report can be generated automatically. Maybe Finance can receive it automatically. Maybe the two systems can talk to each other and the spreadsheet doesn't need to exist at all.
That's the value of giving developers the problem, the context and the goal. It gives them room to suggest things you didn't know were possible.
Some developers will interrogate a brief until they understand why. Plenty won't, and that's not a failing. You asked for a thing and they built the thing.
3. Tell them what success looks like
Giving a developer autonomy doesn't mean being vague.
You can be completely open about how something gets solved while being incredibly specific about what needs to be true when it's finished.
One of the easiest ways to do this is with a user story.
It sounds like software jargon, but the format is ridiculously simple:
For example:
As a customer, I want to reset my password so that I can regain access to my account.
You haven't said anything technical. You haven't told the developer how authentication should work, what database to use or how to structure their code.
You've told them who needs something, what they need and why.
Then you can define what needs to happen for you to consider it done. In software teams, these are often called acceptance criteria.
A common format is:
For our password reset:
Given I've forgotten my password
When I request a reset using the email address associated with my account
Then I receive a password reset email.
And:
Given my reset link has expired
When I try to use it
Then I'm told it's expired and given the option to request another.
You don't have to be technical to write any of that. In fact, as the person who understands the user or the business need, you're probably better placed to define it.
What you shouldn't be doing is deciding how the developer achieves it.
4. An estimate isn't a promise, but it shouldn't be a shrug either
If you've worked with developers for long enough, you've probably had some version of this conversation:
"How long will this take?"
"Probably two days."
Three days later:
"You said it would take two days."
Software estimation is difficult because you're often estimating something before you've actually discovered everything involved in building it.
A change that looks tiny might touch an integration nobody knew about. Old code might behave differently than expected. Fixing one problem might expose another one underneath it.
But "software is hard to estimate" also shouldn't mean timelines are meaningless and everyone just hopes for the best.
Early on, when you're comparing pieces of work and don't know enough to put sensible numbers against them, something as simple as T-shirt sizing can be useful:
You're not pretending you know whether something will take eleven hours or thirteen when nobody has looked at it properly yet. You're saying, relative to the other work we're looking at, this seems small or this seems complicated.
As you learn more, estimates can get more specific.
Then check in.
And when an estimate changes, don't just ask when the new deadline is. Ask:
Maybe there was an undocumented dependency.
Maybe an integration behaved differently than expected.
Maybe the requirement changed halfway through.
Maybe the existing code was much more complicated than anyone realised.
Or maybe the original estimate just wasn't very good.
That's useful information too.
Document why estimates were wrong, especially when you start seeing patterns.
If every piece of work involving the same integration takes twice as long as you expect, eventually "this integration is always more complicated than it looks" should become information you use when estimating the next piece of work.
If a certain type of requirement constantly grows once development starts, maybe those requirements need more investigation before they're estimated.
If estimates keep changing because requirements keep changing, you don't have an estimation problem.
The point isn't to find someone to blame every time a date moves. It's to learn why it moved so the next estimate can be better.
Size early. Estimate when you know more. Check in. Understand what changed. Learn from it next time.
The goal isn't to make developers predict the future perfectly. It's to get better at predicting it together.
5. "It doesn't work" isn't a bug report
You find something broken and tell the developer:
"Login isn't working."
They try it.
It works.
And then come the four words guaranteed to annoy absolutely everyone involved:
It can sound like the developer equivalent of "sounds like a you problem."
But it's actually useful information.
If it works for them and doesn't work for you, something is different.
Your job together is to figure out what.
A developer can't investigate something they can't reproduce, so instead of just telling them that something is broken, give them enough information to recreate what happened.
A simple format is:
So instead of:
"Login is broken."
You might say:
I was: trying to log into my account on Safari on my iPhone.
I did: enter my email and password and tap Log In.
I expected: to be taken to my account.
Instead: the button spun for about five seconds and returned me to the login screen with no error.
It happens: every time. I've tried three times.
Now the developer has somewhere to start.
Screenshots and screen recordings can help. So can the browser or device you're using, the page you were on, roughly what time it happened and anything unusual you noticed.
You don't have to diagnose the bug.
You just have to describe your reality well enough that someone else has a chance of recreating it.
You don't need to speak developer
None of this requires you to become technical.
You don't need to learn to code to work well with developers. You need to get good at explaining problems, giving context, defining what success looks like and being comfortable saying, "I don't understand that, can you explain it differently?"
And, perhaps most importantly, treat developers like the experts you hired them to be.
- Give them autonomy.
- Listen when they tell you something is more complicated than it looks.
- Ask questions instead of pretending you understand.
- Challenge them when something doesn't make sense, but actually listen to the answer.
- Give them context instead of instructions, and bring them into conversations early enough that their expertise can change the direction, rather than after every decision has already been made.
- Respect their time and their expertise.
- And just generally, be nice to them.
The best developers I've worked with weren't people I handed perfectly written tickets to and waited for code to come back. They were people I could throw a messy problem at, argue through it with, learn from, and eventually arrive somewhere neither of us would have got to alone.
You don't need to speak developer.
You just need to learn how to talk to one.