Working With Developers: A Field Guide for Analysts Who Do Not Code

Developers do not need an analyst who can read their code. They need one who removes ambiguity faster than it accumulates. The expensive part of building software is not typing, it is stopping, because a question came up that nobody in the room can answer. Every hour you save a developer from that is worth more than any technical vocabulary you could acquire.

There is a persistent belief among analysts that the way to work well with engineers is to become slightly like one: learn some SQL, read the repository, speak the vocabulary. That helps, and this site has a whole pillar about it. It is not the thing that makes a developer glad you are on the project.

What makes a developer glad you are on the project is that when they hit a question at eleven on a Tuesday, you answer it that morning with a decision, and the decision holds. That is the job. This guide is about doing it well without writing a line of code. The requirements craft underneath it is the subject of From Vague BR to Functional Requirements.

What do developers actually need from you?

Four things, and they are not the four most analysts optimise for.

A decision, not a menu. A specification that says “the system could reject the payment or route it to repair” has not specified anything. It has moved the choice to whoever is closest to the keyboard when the code reaches that branch, and that person will pick the one that is easier to build, which is a reasonable thing for them to do and a bad way to make a business decision. If you genuinely cannot decide, say who will and by when. An open question with an owner and a date is a plan. An open question phrased as a description is a landmine.

The edge cases before they are hit. A developer implementing a payment validation will meet the null value, the duplicate, the zero amount, and the string with an apostrophe in it whether or not you mentioned them. If you did, they build the intended behaviour. If you did not, they invent something sensible, and you find out in testing that sensible and correct were different.

The why, not only the what. A developer makes a hundred small choices you will never see: what to log, what to do when a downstream call times out, whether to fail loudly or degrade quietly. They make those choices correctly when they understand what the feature is for, and arbitrarily when they do not. Two sentences of context is the highest leverage writing in any specification.

Availability during the build, not only at handoff. The questions that arrive on day three are the expensive ones, because by then something has been built on top of the assumption. Being reachable in that window is worth more than the quality of the document you wrote in the week before it.

Which questions earn credibility?

The right question does two things at once: it gets you information, and it demonstrates that you understand the shape of the work. These four do both.

“What breaks if we do it this way?” This invites the developer to tell you about the consequences they can see and you cannot: the other feature that shares the code, the report that reads the field, the assumption baked in three years ago. It is the single most productive question in the language, and the answer is often a requirement you did not know you had.

“What are you assuming that I have not confirmed?” Developers accumulate assumptions constantly because they must in order to keep moving. Most are correct. The ones that are not become defects, and they surface at exactly the moment they are most expensive. Asking this once mid-build routinely surfaces a wrong assumption while it is still cheap.

“Is that a one-line change or a one-week change, and what makes it the second one?” This gives you the scale before you commit to anything and it signals that you know those are different. The second half of the question is the useful half.

“What would you need from me to start?” Asked before the sprint rather than during it, this converts a vague sense of not-ready into a specific list you can go and close.

Notice what none of them do: none require you to understand the implementation, and none ask the developer to justify themselves. They ask for consequences, assumptions, scale, and inputs, which are all things you are entitled to and equipped to act on.

Which phrases lose it?

Three, and they are worth striking from your vocabulary deliberately.

“It is just a small change.” You do not know that. When it is small, saying so adds nothing; when it is not, you have announced that you think the work is trivial. The version that costs nothing is “I do not know how big this is, what does it touch?”

“Can you just…” The word just carries the same implication in a shorter package. It appears in almost every request analysts make and it is doing no work at all. Remove it and the sentence improves.

“The business needs it by Friday.” Delivered without a scope conversation, this is a demand dressed as information. The version that works names the trade: “The business needs something by Friday. Here is what I think is the minimum that delivers value. What is achievable and what would we be cutting?” That is the same message with the developer inside the decision instead of outside it.

Under all three is one signal: that you do not believe building the system is real work with real constraints. That is the belief that takes months to undo, and it is undone by behaviour rather than apology.

How do you read a technical objection?

When a developer pushes back, they are saying one of three things, and they very often do not label which. Responding to all three identically is the most common way analysts damage the relationship.

What they say	What they mean	What it needs from you
”That is hard”	Difficulty. It is possible, it costs time.	A scope or priority decision. Is it worth the cost?
”That will not work”	Correctness. The requirement is internally inconsistent or contradicts the system.	To listen and change the requirement. This is a free defect.
”That worries me”	Risk. It will work, and it might fail in production.	A risk conversation with the business, and often a non-functional requirement

The middle row is the one to treasure. A developer telling you a requirement cannot work as written has found a specification defect before it cost anything, which is the cheapest defect you will ever receive. The instinct to defend the requirement is strong and wrong. The right response is “say more”, then go and fix the specification.

The third row is the one analysts most often mishandle, because “that worries me” sounds like reluctance and is actually engineering judgement about failure modes. Treat it as an input to a non-functional requirement, not as an obstacle. The developer who says “this will work but it will fall over at month end volumes” has just written your performance requirement for you.

How do you have the estimate conversation?

Never negotiate the number. Ask what is inside it.

An estimate is usually three separable things wearing one figure, and only one of them responds to anything you can do.

Complexity is real work: the code that must exist. It does not shrink because the date is important. Uncertainty is the padding for unknowns, and it does shrink, immediately, when you supply an answer. “How much of that is the unresolved question about partial settlement?” is a fair question, and often a third of the estimate is sitting on one open decision you can close that afternoon. Unfamiliarity is the cost of the developer not having worked in that area before, and it shrinks with a spike, a pairing session, or a different assignee, which are all scheduling responses rather than analysis ones.

Asking which of the three dominates turns a haggle into a joint problem. It also, occasionally, gets the number down honestly, which never happens by pushing.

One warning. If the answer is “it is mostly complexity”, the conversation is over and the correct move is to go and change scope, not to ask again more firmly. Asking twice is how you find out that the estimate was optimistic and nobody wanted to say so.

What do you do when you do not understand?

Say so, and redirect to consequence.

“I do not follow the mechanism, and I am not sure I need to. What does it mean for the customer, the timeline, or the data?” That sentence is available to you at every level of seniority and it is what senior people actually say. It gets you the part you need, and it tells the developer where to pitch the rest of the explanation.

The alternative, nodding, is expensive twice over. You will make a decision later without the information you pretended to have. And the developer will proceed believing you understood, so they will not flag it again when it matters.

There is a version of this that is genuinely worth resisting: asking a developer to explain something you could look up in ten minutes. The line is roughly whether the answer is general knowledge or specific to your system. What a message queue is, look it up. Why your system retries three times and then gives up, ask. Building your own reference of the second kind is what a second brain is for, and it means you ask each question once.

How do you talk about technical debt?

You will be asked to advocate for work that has no visible business output, and this is one of the places a good analyst is disproportionately useful, because developers are usually bad at making this case and you are equipped to make it.

The move is to translate the engineering statement into a business consequence with a number attached. “The payment repair module needs refactoring” persuades nobody. “Every change to payment repair currently takes three times longer than an equivalent change elsewhere and has caused two of our last five production incidents, and we have four repair changes in the next two quarters” is a business case. Same request, expressed in delivery cost and risk.

Get the inputs by asking two questions: what does this cost us every time we touch it, and what is the chance it hurts us in production. Then say it in the language the person holding the budget uses. That is the job you are actually there to do, and it is the same skill as writing any business requirement.

A worked example

A developer tells you: “We cannot make the payment submission endpoint idempotent the way you have written it.”

The unhelpful responses are to accept it and quietly change the requirement, or to insist because the requirement says so. Both skip the actual content.

Work the three-row table. Ask “is that a difficulty, a correctness problem, or a risk?” Suppose the answer is correctness: the requirement says to deduplicate on the customer reference, and the developer knows that reference is not unique, which if you have read the identifier taxonomy you now know is entirely correct, since customer-assigned references collide and NOTPROVIDED is a legal value.

Now you have a genuine finding. The requirement was wrong, not the developer. The fix is a real decision that belongs to you: deduplicate on a key that is actually unique, and define what the system does when a duplicate is detected, since returning the original payment and rejecting the request are different behaviours with different customer consequences. That decision goes back in writing, the developer builds it, and the whole exchange took twenty minutes and prevented a duplicate payment in production.

That is the loop. You did not need to know how the endpoint is implemented. You needed to hear which kind of objection it was, and to own the decision that came out of it. The technical foundations that make these conversations easier over time are in The Technical Skills Guide for BAs.

The takeaway

Developers do not need you to read code. They need ambiguity removed faster than it accumulates, which means decisions rather than menus, edge cases resolved before they are hit, two sentences of why alongside every what, and your availability during the build rather than only at handoff.

Ask what breaks, what they are assuming, how big it is and why, and what they need from you to start. Drop the word just, stop treating estimates as opening bids, and never bring a deadline without bringing a scope conversation with it. When you meet an objection, work out whether it is difficulty, correctness, or risk, because those need a priority decision, a specification fix, and a non-functional requirement respectively. When you do not understand, say so and ask for the consequence.

Do that for a quarter and you will find developers bringing you problems early, which is the only reliable sign that the relationship is working.

Start with From Vague BR to Functional Requirements for turning intent into something buildable, and The Technical Skills Guide for BAs for the vocabulary that makes these conversations shorter, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Collaboration, Delivery, Requirements, Engineering