Last updated: September 23, 2026
Managing developers when you’re not technical works if you manage outcomes instead of code: define finished in business terms, look at working software every week, and borrow technical judgment for the calls you can’t make yourself. You don’t need to read the code. You need to stop pretending the status report is the software.
“Is the portal done?”
“Basically.”
That exchange happened in a CFO’s office at a building-supply distributor I was working with, and it happened again three weeks later, word for word. Same CFO. Same developer. Same answer. Nobody was lying. The developer meant the hard parts were finished. The CFO heard that customers could log in on Monday. Those are different planets, and the gap between them cost about forty thousand dollars of developer time before anyone noticed they weren’t talking about the same thing.
I get called into that gap a lot. It’s most of my job, honestly.
Consulting Is the Hardest Job on Earth. Congrats, You Have It Now.
Here’s my pitch for why consulting is the hardest job on earth.
I’m accountable for software I usually didn’t write, built by developers I often don’t employ, for a buyer who can’t read it and is paying by the hour. The developers assume I’m a suit who’s going to add scope. The executives assume I’m a meter running. Nobody trusts me by default, and the only thing that earns it is being right in front of both groups, repeatedly, in words each of them understands.
Okay. Hardest on earth is a stretch. Crab fishermen would like a word. Among jobs with a chair, I’ll defend it.
Now look at your own seat. If you run operations, finance, a product line, or a company, and there are developers reporting to you, you’re in the consultant’s chair whether you signed up for it or not. You’re the translator between people who build and people who pay. The only difference is that consultants get fired fast when they’re bad at it, so we build habits out of self-defense. You’re allowed to steal them.
Everything below is those habits. Some came from Foretopia’s own written change-control process, which exists because regulated clients audit us and “trust me” is not an audit finding. Some came from getting it wrong in front of a client, which is a more expensive teacher.
If you’re still at the step before this one and don’t have developers yet, the earlier problem is hiring them without being able to read their work, and there’s a separate guide on hiring engineers as a non-technical founder. When the team needs to grow past what one person can supervise, KORE1’s software engineer staffing desk is where I send people. Disclosure: I’m writing on KORE1’s site and they place developers. Weigh my enthusiasm for hiring help accordingly.
What Managing Developers Actually Means When You Can’t Read the Code
Managing developers as a non-technical leader means owning the what and the why while delegating the how. You set priorities in business terms, define what finished looks like, inspect working software on a fixed rhythm, and bring in someone technical to judge the code quality you can’t evaluate yourself.
Notice what’s missing from that. Picking the framework. Estimating the tickets. Reviewing pull requests. Deciding whether the thing should be a microservice. You don’t do those, and the fastest way to lose a good developer is to fake an opinion about them. They can smell it. Every developer I’ve managed could smell it.
What you do own is harder than it sounds, because each piece requires you to say something specific out loud. “Make the portal better” is not a priority. “A contractor should be able to reorder last month’s lumber without calling us” is.
The Three Words That Do Most of the Damage
Done. Just. Quick.
Almost every blown timeline I’ve been called in to clean up traces back to one of those three, used by someone who meant something different from the person hearing it.
Done is the portal problem. To a developer it often means “the code is written.” It might not be tested. It might not be deployed. It’s almost certainly not in front of a customer. I once spent forty minutes in a conference room with a developer and a controller before we figured out that deployed meant, to him, sitting in a sandbox account nobody in finance had a login for, which explained the controller’s face. So I stopped asking whether things were done and started asking whether a named person could do a named thing, today, in the live system. “Can Maria in AR pull an aging report by branch right now?” Yes or no. There’s no “basically” available in that sentence.
Just is worse, because the business side says it. “Can you just add a field?” I watched that one eat a client alive. A wholesale food company wanted a requested ship date on the NetSuite sales order. A field. Twenty minutes, right? Except the ecommerce connector had to send it, the pick ticket template had to print it, two saved searches the warehouse lived in had to show it, and a workflow that emailed customers their order confirmation had to include it or the customer service team would get the calls. Two days, quoted. Nine days, actual. The developer wasn’t slow. The word “just” hid seven dependencies from everyone who didn’t have to build them. It’s the same trap behind most customization requests, which is why I’m stubborn about when to build and when to adopt.
Stack Overflow’s 2024 survey found technical debt was the most common frustration developers reported, cited by 62% of respondents, about twice the next item on the list. A lot of that debt starts as somebody’s “just.”
Quick is a request for an estimate disguised as a compliment. Skip it. Ask what would make the estimate wrong instead. Good developers always have an answer to that, and the answer is the actual risk in the project.
Watch the Software, Not the Status Report
Once a week, somebody shows you the thing working. Not slides. Not a ticket board with a lot of green on it. The actual software, clicked through, on a test environment, by the person who built it.
That’s the single most useful habit on this page. If you only take one, take that one.
It matters more now than it did three years ago, because AI tools made “looks finished” much cheaper to produce than “is finished.” Stack Overflow asked about this in its 2025 Developer Survey, and 66% of developers said their biggest frustration with AI tools was solutions that are almost right, but not quite, and 45% said debugging AI-generated code takes longer than expected. Almost right compiles. Almost right demos fine for thirty seconds. Almost right is how a company ends up with a portal that’s basically done for a month. I wrote more about where that bill actually lands in a piece on AI-augmented development, and it’s not the sprint you’d guess.
What I actually ask during a demo, roughly in this order:
- Show me the ugly path. What happens if the customer enters a PO number that’s already been used?
- Who’s going to use this first, and have they seen it yet?
- What did you decide not to build this week, and why?
- Where does it break if our order volume doubles in November? (Distributors always say November.)
- Anything you need from me. This one matters more than the other four combined, because half the time the blocker is a decision nobody on the business side has made.
None of those require knowing what a REST endpoint is. They require showing up every single week, including the weeks when nothing interesting happened and the demo lasts three minutes, and staying annoyingly consistent about it until the team stops preparing slides and just opens the software.
Borrow the Judgment You Don’t Have
You can’t evaluate code quality. Fine. Neither can your CFO evaluate your tax attorney’s reasoning, and she still manages to get competent tax advice. She checks the process around the work instead of the work itself.
Foretopia’s change-control procedure says every change is reviewed before merge by a person other than its author, that nothing gets changed directly in production outside the process, and that when a change is classified, the classification gets written down along with the reasoning behind it. We wrote that for regulated manufacturers. It turns out to be a pretty good checklist for anybody who can’t read code, because every one of those rules produces a question with an obvious good answer and an obvious bad one.
| Ask this | A good answer sounds like | Worry if you hear |
|---|---|---|
| Can you show me? | They open it and click through it on a test environment | “It’s easier if I explain it” |
| Who reviewed this besides you? | A name, and roughly what they checked | “It was simple. It didn’t need a review.” |
| What else does this touch? | The integration, the reports, the emails, listed out | “Nothing,” on a system older than a year |
| Where does the code live? | A company-owned repository your admin can log into | “On my machine” or a personal GitHub account |
| What would make this estimate wrong? | A specific unknown, like a vendor API they haven’t tested | A number with no conditions attached |
| Did anything get changed directly in production? | “No,” or “once, here’s the record of why” | A pause, then “only small stuff” |
Some of those answers you’ll still need help interpreting. That’s what a senior developer on contract, a technical advisor, or a fractional CIO is for. The management stays with you. What you rent, a few hours a month, is the part you can’t do, so you can keep doing the part you can.
Write the Scope Down, Then Write the Whole Thing Down Again
The building-supply portal from the top of this piece started as a reorder button.
Then it needed invoice history, because customers asked. Then returns. Then a credit application, because the sales manager saw a competitor’s. Every one of those additions was reasonable and approved in a hallway, and six months in nobody could say what the original agreement was, which meant nobody could say whether the project was late or just bigger. Both, it turned out. Mostly bigger. The worst part wasn’t the money. It was the meeting where the owner asked why the portal was four months late and the developer, the sales manager, and I each gave a different and completely sincere answer about what the portal even was.
Our change-order process has a rule I love for this. Every approved change restates the entire current scope, the original plus every change since, so drift can’t hide between documents. Verbal approval doesn’t count for anything, in either direction. It feels bureaucratic for about two weeks. Then the first argument about whether something was “always part of it” gets settled in thirty seconds by reading one page, and people stop complaining.
You don’t need a formal change-order system for an internal team. You need one living document that says what the thing is supposed to do, updated every time someone says yes to something new, with the date and who said yes. A shared doc works. A ticket nobody reads does not.
The Developer Who Holds All the Keys
I lose sleep over this one, and it isn’t even my company.
A distributor I worked with had one contract developer who’d written every custom script in their NetSuite account over about four years. Great guy. Fast. Knew the business better than half the staff. He went on his honeymoon somewhere with no cell service, which, good for him, and that same week NetSuite’s twice-yearly release rolled into their account. A scheduled script that posted freight charges to invoices quietly stopped running. Nobody noticed for six days, because the invoices still went out. They just went out without freight. The code lived in his personal accounts, nobody else had access, and nobody else knew the script existed.
Roughly $38,000 in unbilled freight, recovered slowly and awkwardly, with a lot of apologetic calls to customers. Brutal.
Our subcontractor policy has a line for exactly this: wherever a deliverable depends on one individual, record what work product the company holds rather than the person, and what the backup arrangement is. Translated for you, that’s three questions you can ask this week without knowing anything technical:
- Is all of our code in a repository the company owns, with at least two people who can get in?
- If our best developer disappeared for three weeks, who could fix a broken script?
- When the platform vendor ships an update, who tests our customizations against it, and when?
If the answers are “I think so,” a shrug, and “we find out when it breaks,” you’ve found your first project. It’s not glamorous. It’s worth more than whatever’s on the roadmap.
Protect Their Afternoons
Paul Graham wrote an essay in 2009 called Maker’s Schedule, Manager’s Schedule, and every non-technical manager should read it once. His point is that managers live in one-hour blocks and people who make things need half-days, and that “a single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.”
Your calendar is full of 30-minute slots. That’s how your job works. It’s not how theirs works, and a 2:00 check-in costs a developer the entire afternoon, not thirty minutes.
I didn’t believe that either until a project ran short a person and I went back to writing code for a few weeks, and the days with one meeting at 1:30 were the days I got approximately nothing done after lunch. Not one thing.
What I do: every recurring meeting with developers goes first thing in the morning or right up against lunch. Status updates go in writing, three lines, end of day. Questions that can survive overnight get saved for the morning, which turns out to be most of them. None of that is sacrifice. I get better work, sooner, from people who like working for me. Nice trade.
What to Measure, and What Makes Good Developers Leave
Don’t count lines of code. Don’t count tickets closed. Both are easy to game and both measure activity, which you already know is not the same thing as progress.
Count things the business can feel. How long from “we agreed to build it” to “a customer is using it.” How often a release breaks something that used to work. How many decisions are sitting on your desk waiting for you, which is the metric nobody wants to track, because the answer is usually embarrassing. Mine too.
The people side matters more than the metrics, though. Gallup’s research found that managers account for at least 70% of the variance in employee engagement, and that companies fail to choose the candidate with the highest talent for the job in 82% of manager hires. Developers aren’t special here. They’re just more mobile than most employees, so a bad manager shows up in turnover faster.
KORE1 reports a 92% twelve-month retention rate on its placements, which is a useful reminder that a hire mostly sticks or doesn’t based on what happens after the offer letter. Whether a developer stays is mostly decided by whether they’re allowed to finish things. Vague priorities that change weekly, surprise meetings, a manager who pretends to understand the architecture, credit that goes upstairs and blame that comes back down. Those are the reasons I hear. Salary shows up on the list. It’s rarely first.
When to Stop Doing This Yourself
Everything above works for one to three developers. Past that, it starts to break. Somebody has to be making technical calls every day instead of once a week, and code review needs an actual owner rather than whoever happens to be free on the Thursday afternoon the pull request shows up.
Three reasonable next steps, depending on your size and money:
A senior developer or lead on contract staffing terms, who reviews code and sets standards while you keep running priorities. Cheapest to start and easiest to undo if the fit’s wrong.
A full-time engineering manager, once the team is five or six people and growing. KORE1 runs a desk for engineering manager staffing if you want someone who’s done the hire a few hundred times.
A fractional technology leader, if what’s really missing is somebody to decide what to build, not somebody to supervise the building. That last one is literally my job, so I’m not neutral about it.
What doesn’t work is staying in the middle forever, holding the translation job with no technical backup, getting “basically” for an answer and hoping it means yes. That sucks for you and it sucks for the developers.
Questions I Get From the Business Side of the Table
Do I have to learn to code first?
No, but learn the nouns: environment, repository, deployment, integration, API, and the names of the systems your team actually works in.
You want enough vocabulary to ask a precise question. “Is this on the test environment or production?” gets you a straight answer. “Is it live-ish?” does not. A weekend is enough for the nouns. Learning to code is a fine hobby. It’s not a management requirement.
How can I tell whether an estimate is padded?
Mostly you can’t, and padding is the wrong thing to worry about anyway.
Estimates are wrong because of unknowns far more often than because of padding. Ask what would make the number wrong, and ask again halfway through whether any of those things happened. A developer who pads is annoying. A developer who hides unknowns is expensive.
My developer says what I asked for can’t be done. Now what?
Ask what it would take instead, because “can’t” almost always means “can’t within the time, budget, or platform you assumed.”
Then you’ve got a real conversation. Maybe it’s possible with another month. Maybe 80% of it is easy and the last 20% needs a separate tool. Maybe your platform really doesn’t do it, in which case you’d rather know now than after the build. That kind of honesty is worth rewarding, loudly, because the alternative is a developer who says yes and delivers basically.
Does any of this change with an offshore or contract team?
It all applies more, not less.
Distance and time zones make “done” even more slippery, and the continuity problem gets worse, because contracts end. Insist on the company-owned repository from day one, the weekly demo recorded if the hours don’t overlap, and a written scope that the vendor restates every time it changes. And have someone on your side, even part time, who can read what they deliver.
The best offshore team I’ve worked with sent a four-minute screen recording every Friday, which I usually watched on my phone in a parking lot, and it did more for trust between the two companies than any status meeting we ever held. Cheap, too.
How often should I check in without turning into that manager?
Once a week for a working demo, plus a short written update at the end of each day.
That’s it. The demo keeps everyone honest and the written update keeps you from wandering over at 2:00 to ask how it’s going. If you find yourself needing more than that, the priorities probably aren’t clear enough, and more check-ins won’t fix unclear priorities. Fixing the priorities will.
When should I hire someone technical above the team?
Somewhere around three developers, or sooner if the software is the product rather than something that supports it.
At that size code review stops happening naturally and architecture decisions start piling up. If the software is how you make money, get a technical leader in early. If it runs the back office, a contract lead or a fractional arrangement usually covers it for a long time.
Be the Translator, Then Hire One
For a while yet, the person in the middle is you. Might as well be good at it. Define finished out loud. Watch the software every week. Ask who else looked at the code. Write the scope down and keep rewriting it. Make sure nobody holds all the keys. Leave their afternoons alone.
Then, when the team outgrows you, get someone technical in the seat above them and go back to running the business, which is the job you actually wanted.
If you’re stuck in the middle of a “basically” right now, hit me up. And if what you need is the developers themselves, or the manager to run them, you can talk to a recruiter at KORE1 directly.
