We promoted the best engineer on the team. It was obvious: he knew every system, everyone asked him things anyway, and the title felt overdue. Seven months later he resigned, telling me he had not written meaningful code since March and had not enjoyed a single week. A second engineer left a few weeks after him, because the person who had been unblocking her was now in meetings. One promotion, two departures.
The question almost everyone asks first, and why it is the wrong one
“Who should we promote?” is the wrong opening question. It assumes the answer is a promotion and it skips the part that determines whether the hire works: what, specifically, is going wrong right now?
Two very different failures get treated as the same problem. One is coordination — work is unpredictable, priorities shift in private conversations, nobody can say what ships next month, people are blocked and nobody notices. The other is technical — architecture is drifting, decisions get relitigated, quality varies by who wrote the code.
The first needs an engineering manager. The second needs a tech lead or a staff engineer, and hiring a manager for it will not fix anything. Teams that skip this distinction hire a manager, watch the technical problems continue, and conclude the manager is bad.
What I got wrong the first time
I treated management as a reward for technical excellence, which is the most expensive compliment you can pay someone. The engineer I promoted was superb at the job he had and had never once expressed interest in the job I gave him. I read his willingness as enthusiasm; it was politeness. The conversation I should have had — “this role means you stop being the person who solves the hard problem, and that is permanent” — takes twenty minutes and would have saved two people and nine months.
Step 1 — Write down the failure you are solving
One paragraph, in plain language, describing what is going wrong. Not “we need more structure” but “three of the last four commitments to sales slipped, and in each case we found out in the final week.”
Then sort it. Coordination, prioritisation, delivery predictability, people leaving, nobody owning the interface with the rest of the business — that is a manager. Architecture, technical standards, review quality, systems drifting apart — that is a tech lead.
If you genuinely have both, hire for the manager and give the tech lead role to someone internally, in that order. A manager can create the conditions for technical leadership to emerge; a tech lead rarely fixes coordination, because they have no mandate to.
Step 2 — Scope the role in outcomes, not headcount
Most job descriptions for this role are a headcount and a list of rituals: manage six engineers, run stand-ups, do performance reviews. None of that tells a candidate what success looks like, and none of it tells you whether the hire worked.
Write instead what will be true in six months. For example: delivery commitments are met or renegotiated at least two weeks in advance rather than in the final days; every engineer has had a documented development conversation; the team has hired and onboarded one person successfully; escalations that used to reach the founder now stop at the manager.
Those are verifiable by someone who cannot read code, which is the test. Our notes on writing developer job descriptions in Singapore apply here with one amendment: for management roles, the outcomes section matters more than the requirements section, and should be written first.
Step 3 — Decide internal versus external deliberately
Both routes cost something. Price them honestly before choosing.
Internal promotion preserves context, rewards loyalty and signals a growth path. It also removes your strongest individual contributor from the work, and if the person does not want the job — or wants it for the title rather than the work — you can lose them entirely. That is the failure I opened with.
External hire brings practices the team has never had and a perspective nobody inside can offer. It costs a quarter or more of credibility-building, and it lands hardest on the senior engineer who assumed the role was theirs. If you go external, have that conversation before the hire starts, not after.
The clearest signal for promoting internally: the candidate is already doing the coordination work informally, visibly enjoys it, and has said so unprompted. The clearest signal for going external: your team has never seen good management and cannot describe what it looks like.
Weighing a promotion against an external search?
We benchmark the Singapore engineering leadership market and can tell you within a week whether the external option is realistic at your band.
Get startedStep 4 — Source against a thin market
Singapore has plenty of senior engineers and plenty of managers who have run teams inside large technology companies and banks. What it has comparatively few of is people who have built a first engineering function in a small company — which is the actual job.
Searching only for the exact title will stall. Three sources work better:
- Senior engineers already leading informally. They run the planning nobody asked them to run and mentor without being assigned. Ask what they want next; the answer is often this role.
- Managers deliberately seeking smaller scope. People leaving large organisations because they want to be close to the work again are an excellent fit, and are usually screened out by pattern-matching on company size.
- Founders and former agency leads. They have run small teams under resource constraints, which is the closest analogue to a first management role.
If part of your shortlist requires relocation or a pass application, build the timeline in early — our notes on the Employment Pass process for tech talent set out realistic lead times.
Step 5 — Screen for delegation, conflict and hiring
Three behaviours predict success in this role, and none of them appear on a CV.
Delegation. Ask: “Tell me about something you were good at that you handed to someone who was worse at it.” Strong candidates have a specific story and can describe the discomfort. Weak candidates describe assigning work they did not want.
Conflict. Ask: “Describe a disagreement with someone you managed that you did not win.” You are listening for someone who can hold a position without needing to be right, and who did not resolve it by pulling rank.
Hiring. Ask: “Tell me about someone you hired who did not work out. What did you miss?” A candidate who has never made a bad hire has either not hired much or is not being honest. Both are worth knowing.
Insist on past events rather than intentions. “I would sit down with them and…” is not evidence. “In March we had this problem and I…” is.
A pattern worth naming
The most consistent predictor we see across engineering manager placements is whether a candidate talks about their former team’s achievements or their own. It sounds soft, and it is the most reliable signal in the whole process. A candidate who says “I rebuilt the pipeline” about work done by a team of six is telling you exactly how they will behave in your organisation, and the pattern shows up again in reference conversations without fail.
Step 6 — Run a loop that tests the actual job
Three exercises, in this order:
- A one-on-one simulation. Role-play an engineer who is underperforming and defensive. You are watching whether the candidate asks questions before diagnosing, and whether they can be direct without being brutal.
- A prioritisation exercise. Give them a real backlog with conflicting constraints — a security fix, a customer commitment, a piece of technical debt, and half the team on leave — and ask them to decide and justify. You are watching for someone who makes the trade-off explicit rather than promising everything.
- A conversation with the team. Not a panel interview: a genuine conversation with two of the engineers who will report to this person, with their honest read collected afterwards. They will notice things you will not, and they will be living with the result.
Skip the coding test. A first engineering manager should be technically credible — able to read the code, follow a design discussion, and challenge an estimate — but ranking them on implementation speed selects for the wrong thing, and tells them on day one what you actually value. If technical depth is the real requirement, our notes on take-homes versus paired trials cover how to assess it without confusing the two roles.
Step 7 — Define the first 90 days before you make the offer
Write it down before the offer goes out, and share it with the candidate. It changes the conversation from “do you want this job” to “can we agree on what this job is”.
A structure that works: first 30 days, one-on-ones with everyone, understand the current commitments, change nothing structural. Days 30 to 60, one process change, chosen with the team, small enough to reverse. Days 60 to 90, take ownership of delivery commitments and run a full planning cycle.
Then measure the team, not the manager. Did delivery become more predictable? Is retention holding? Did they hire and onboard someone? Do decisions now stop with them? If you instead measure their individual output, you will get a manager who writes code at night and neglects the team — recreating the exact problem the role was created to solve.
What the whole process costs
Realistically eight to twelve weeks for an external hire in Singapore, plus a quarter before the impact is visible. An internal promotion is faster to execute and slower to evaluate, because the honest conversation about whether it is working tends to be postponed by everyone involved.
Either way, the expensive version is the one I ran: promote without asking, measure the wrong thing, and discover the mistake through two resignations. The conversation that prevents it takes twenty minutes and should happen before anyone’s title changes.
The pattern is not local. Our Dubai practice sees the same promotion failure with the same two-departure signature, and our US team reports the same scarcity of first-time managers who have built a function rather than inherited one. If what you actually need is capacity rather than coordination, adding engineers is the cheaper answer and worth ruling out first.
Frequently asked questions
How many engineers justify a dedicated engineering manager?
The count matters less than the coordination load, though six to eight engineers is where most teams start to feel it. The more reliable trigger is behavioural: when the founder or senior engineer holding the team together spends more than roughly a third of their week on coordination, when priorities are being renegotiated informally in direct messages, or when nobody can say confidently what will ship next month. Two teams with identical headcount can sit on opposite sides of that line depending on how much their work requires coordination with people outside engineering.
Should we promote internally or hire externally?
Both options have real costs and the mistake is pretending one of them is free. Promoting internally preserves context and signals a growth path, but it removes your strongest individual contributor from the work and, if the person turns out not to want the job, frequently costs you them entirely. Hiring externally brings experience and an outside perspective, at the price of a quarter or more spent building credibility with engineers who did not choose this manager. Our rule of thumb is to promote internally when the candidate has already been doing the coordination informally and visibly enjoys it, and to hire externally when the team needs practices it has never had.
What should a first engineering manager actually be measured on?
On the team’s output and stability rather than on their own. Useful measures include whether delivery became more predictable, whether engineers are leaving at a lower rate, whether the manager successfully hired and onboarded someone, and whether decisions that used to escalate now get resolved within the team. Measuring a new manager on their personal code contribution is the most common error we see, and it reliably produces a manager who writes code and neglects the team, which is precisely the failure the role was created to fix.
Is the engineering manager market in Singapore competitive?
It is thin rather than merely competitive, and the distinction matters for how you search. Singapore has a deep pool of senior engineers and a substantial pool of managers who have operated at scale inside large technology companies and banks, but comparatively few people whose experience is building a first engineering function in a small company. Those are different jobs. Search plans that only target people with the exact title tend to stall, while plans that include senior engineers already doing the work informally, and experienced managers deliberately seeking smaller scope, generally produce a workable shortlist.
Hiring your first engineering manager in Singapore?
We source candidates who have built a function rather than inherited one, and screen them on delegation, conflict and hiring before you ever see a CV.
Start — get a shortlist