To manage developers without a technical background, focus on outcomes rather than code. Define the problem and what “done” looks like, keep every request in one issue tracker, review working software in a weekly demo, treat estimates as ranges, and bring in a technical second opinion as soon as progress stops being visible.
You don't need to understand the code to know whether the product is moving. You do need a system, because without one you end up either micromanaging tasks you can't judge or trusting status updates you can't check. This is the system I'd set up, and it's the same rhythm I use in my own engagements: weekly sprints that each end in a Friday demo of working software.
How to manage developers by outcomes, not tasks
A task tells a developer what to type. An outcome tells them what should be true for a user when they're finished, and leaves the how to them.
| Task (avoid) | Outcome (better) |
|---|---|
| Add a filter to the bookings page | Front-desk staff find any of today's bookings in seconds |
| Integrate Stripe | Customers pay by card, and failed payments get flagged |
| Make the app faster | The home screen loads in under two seconds on a phone |
The split of responsibilities is simple. You own the problem, the user, the priority order, the acceptance criteria and the final yes. They own the technical approach, the estimate and flagging risks.
When you start dictating the how (which library, which database), you take on decisions you can't judge, and you make it awkward for them to push back.
Write specs developers can build from
Write every piece of work as a user story, with acceptance criteria you can test yourself. Here's a hypothetical example for a clinic booking app:
Story: As a patient, I want to cancel an appointment in the app so that I don't have to phone the clinic.
Acceptance criteria:
- A cancel option appears on upcoming appointments only, not past ones.
- Canceling asks for confirmation, then frees the slot for other patients right away.
- Appointments less than 24 hours away can't be canceled in the app; the patient sees the clinic's phone number instead.
- The clinic gets an email for every cancellation.
Notice what's missing: nothing about databases or frameworks. Every line describes behavior you can check in a demo. A few habits make specs better still:
- Attach a rough sketch or screenshot. It beats a paragraph of description.
- Write down the edge cases you know about: what if the user is offline, or the payment fails?
- Keep each story small enough to finish in a few days. If it's bigger, split it.
- Invite the developer to challenge the story before they start. Good ones will.
- Agree on one shared definition of done, for example: tested, reviewed by a second person where possible, running on staging and meeting every acceptance criterion.
Deciding what belongs in the product in the first place is a separate skill, covered in how to scope an MVP.
Run the week around a demo and an issue tracker
A simple, fixed rhythm replaces most of the meetings you'd otherwise feel the need to hold:
- Monday, 30 minutes: agree on the week's work from the top of the tracker. You set the order; they say what fits.
- Every day, in writing: three lines from each developer covering what's done, what's next and what's blocked.
- Friday, 30 to 45 minutes: a demo of working software on a real environment, either a staging copy or the live product. Not slides, not screenshots. You drive: click through each story and check its acceptance criteria yourself.
- Once a month, an hour: step back. What shipped, what slipped, what to change in how you work, and next month's priorities.
The issue tracker is the single source of truth. Every request goes in it, including the idea you had in the shower and the request a customer sent you on WhatsApp. If it isn't in the tracker, it doesn't exist.
Keep the columns simple (To do, In progress, In review, Done), own the order of the To do column yourself, and allow no more than one or two items in progress per developer. Log every bug with the steps to reproduce it, what you expected and what actually happened.
How do you measure developer progress?
By software you have used yourself. Everything else is a proxy. These are the signals worth watching:
- Stories accepted in the demo each week (watch the trend; don't set a target).
- How long items take to go from “in progress” to “done”.
- Bugs your users find compared with bugs caught before release.
- How often you can release without drama.
- Anything stuck in “in progress” for more than a week.
Ignore hours logged, lines of code and the number of commits: they measure activity, not progress. Never accept “80% done” either. A feature either meets its acceptance criteria or it doesn't, and the last stretch often takes as long as everything before it.
If your team uses story points, treat them as a planning aid, not a productivity score. Once points become a target, they inflate.
How to handle estimates and scope without losing trust
Estimates are guesses with error bars, so ask for them that way. “Two to four days, assuming the payment provider's test account works” is far more useful than “three days.” Break anything bigger than about a week into smaller stories, because small estimates are much more reliable than big ones.
When something runs over, don't ask for longer hours. Negotiate scope with questions like these:
- “What's the smallest version that solves the problem by Friday?”
- “What's the riskiest part, and can we do it first?”
- “What would you cut, simplify or postpone to hit the date?”
- “What do you need from me to make this estimate more certain?”
Your levers are cutting a feature, simplifying it (a manual step instead of automation), splitting it into phases, or moving the date. Quality is not one of them.
Rule of thumb: fix the date and flex the scope. Never quietly trade away testing or security to hit a deadline; you'll pay it back later, with interest.
When your developers ask for time to clean up old code, don't dismiss it as a distraction from real work. Here's how to think about technical debt and when it's worth paying down.
How to give developers feedback that helps
- Be specific and tie it to users. “Patients can't find the cancel button on small phones” beats “the design feels off.”
- Separate bugs from changes. A bug fails the acceptance criteria. A change meets them, but you've changed your mind. Changes and new ideas go into the tracker for Monday, not into this week's work.
- Don't redesign during the demo. Note the idea, then prioritize it in the next planning session.
- Praise specifics, and raise concerns early and in private. “The way you handled failed payments will save us support tickets” lands better than “great job.”
- Protect their focus. Batch your questions into one message and avoid “quick calls” in the middle of the day. Hard problems get solved in long, uninterrupted stretches.
- Ask for their view. “What would you build next if it were up to you?” Developers close to the code often spot cheap wins you'd never see.
Warning signs your software project is in trouble
In my experience, trouble in a software project is visible weeks before it becomes expensive, if you know where to look. Watch for these:
- A task has been “almost done” for more than a week.
- Demos get postponed, or turn into screenshots and explanations.
- There's no staging environment you can open and use yourself.
- Updates get vaguer: “working on the backend”, “refactoring”.
- Bugs you saw fixed keep coming back.
- Only one person can deploy, and you don't have admin access to the accounts.
- Estimates keep growing while the scope stays the same.
- A sudden proposal to rewrite large parts of the product from scratch.
One sign is a conversation; two or more lasting a couple of weeks is a pattern. Within a week, ask for a demo of whatever exists, confirm you have admin access to the code repository, hosting and app store accounts, and ask the developer directly what is blocking them. Often it's an unclear requirement, or a technical problem they're embarrassed about.
If things are already badly off course, follow a structured plan to rescue a stalled software project.
When to bring in technical help
You can run the weekly rhythm on your own. Some decisions you shouldn't make on your own:
- Choosing or changing the tech stack or the architecture.
- A developer proposes a rewrite or a major migration.
- Two or more warning signs persist for a couple of weeks.
- You're hiring the next developer and need someone to assess candidates and review code.
- A security incident, a data protection question or investor due diligence.
- Cloud or vendor bills rising without a clear reason.
A trusted senior engineer can handle a one-off review. If you need someone to own these decisions month after month, that's the case for a fractional CTO working alongside a non-technical founder. And if you're still building the team, my guide on how to interview developers covers the hiring side.
The bottom line
Managing developers without a technical background comes down to a handful of habits: describe outcomes, write testable acceptance criteria, keep one tracker, judge progress only by working software in a weekly demo, negotiate scope instead of quality, and act on warning signs within a week.
None of it requires reading code. It requires consistency, and that's the part only you can supply.
Frequently asked questions
Should I run daily standups with my developers?
Not necessarily. With one to three developers, a short written update each day works as well as a meeting and doesn't break anyone's concentration: what I finished, what I'm doing next, what's blocking me. Save live time for weekly planning and the Friday demo. If the written updates get vague or stop arriving, that tells you more than any standup would.
Should I track my developers' hours?
For salaried employees, usually not. Hours say little about progress, and tracking them signals distrust. Track outcomes instead: what shipped, what was demoed and what is blocked. Contractors who bill by the hour are different. You should see their timesheets, but read them against what was delivered that week, and ask about any stretch with plenty of hours and nothing you can see working.
How do I manage developers in a different time zone?
Agree on at least two or three hours of overlap each working day and use them for questions and decisions, not status. Move status into written updates, record demos when live attendance is hard, and keep every request in the issue tracker so nothing depends on chat history. Clear acceptance criteria matter even more across time zones, because one misunderstanding can cost a full day.
What tools do I need to manage a small development team?
Fewer than you might think: a company-owned code repository, an issue tracker, a shared place for specs and decisions, a chat tool, and a staging environment where you can try features before release. GitHub's built-in issues and project boards are enough for many small teams. The tool matters far less than the habit of putting every request in one place and reviewing it weekly.