Lead engineers without pretending to code: set outcomes, create decision boundaries, ask better questions and build trust with technical experts
Her Success Coach helps women leaders build confidence, overcome self-doubt, and lead with clarity. Cambridge-trained, evidence-based coaching for senior women in tech, business, and finance.
You do not need to be the strongest engineer to lead a technical team when you are not an engineer. What you do need is the ability to create clarity around outcomes, decision rights, risk, and communication. The damaging alternatives are pretending to have technical expertise you do not possess or stepping back from technical decisions entirely. Effective leadership sits between those two extremes..
This situation is common for product leaders, programme directors, founders and managers who inherit engineering responsibility. It can also happen to technical leaders whose expertise is in a different domain. The goal is not to know every implementation detail. It is to know which questions reveal whether the team’s reasoning is sound and whether the organisation is making an informed trade-off.
•Technical judgement: specialists evaluate architecture, feasibility, quality and operational risk.
• Product or business judgement: leaders clarify customer value, economics, sequencing and strategic fit.
•Integrated decision ownership: a named person combines the evidence, resolves trade-offs and is accountable for the choice.
Confusion begins when everyone assumes someone else owns the integrated decision. Write the decision map for recurring choices: technical design, incident response, roadmap commitments, staffing, quality thresholds and risk acceptance.
Technical teams usually notice false confidence quickly. Credibility grows when you are honest about what you do not know, learn the vocabulary needed for decisions, protect engineers from arbitrary commitments and follow through on organisational promises.
Try: “I am not evaluating the implementation. I am responsible for ensuring we understand the customer impact, options and risk. Please explain the trade-off in terms we can use to decide.”
That sentence does not diminish expertise. It gives it a route into the decision.
Avoid “Can’t you just…?” questions that smuggle in an answer. Use:
• What problem does this option solve?
• Which assumptions are we making?
• What fails if we are wrong?
• Which part is reversible?
• What is the smallest evidence we need before committing?
• What are we choosing not to optimise?
• Who carries the operational cost?
• How would you explain this risk to a customer or executive?
You are not testing whether engineers can simplify everything. Some complexity is real. You are testing whether the team can connect technical reasoning to consequences.
Ask the team to communicate on two levels. Level one is the decision summary: context, options, recommendation, major risks and ask. Level two is the supporting technical detail for specialists who need to inspect it.
This prevents two common failures: executives receiving impenetrable detail, and engineers feeling that nuance has been erased. The summary should be accurate enough to support a decision, not simplified into certainty.
Leadership Coaching Services help non-technical leaders move beyond simply relaying messages. A weak non-technical leader carries executive demands to engineering and technical objections back to executives without adding judgment. A strong leader translates interests, clarifies priorities, and brings trade-offs into the open so better decisions can be made..
Instead of “Leadership says it must ship in September,” say: “September protects the commercial commitment. The team’s current estimate says that date requires reducing scope or accepting reliability risk. We need to choose explicitly; I will not present all three as simultaneously possible.”
Psychological safety does not mean avoiding accountability or disagreement. It means people can raise concerns, admit uncertainty and challenge assumptions without humiliation. For a non-engineer leader, this is essential: you cannot see risks that specialists are afraid to name.
Model it by saying what you do not know, thanking people who surface bad news early and separating error analysis from personal blame. Then pair safety with standards: decisions still need owners, evidence and follow-through.
Authority should be proportionate to risk. Use four zones:
• Team decides and informs you.
• Team recommends; you confirm strategic or financial fit.
• Joint decision because consequences span functions.
• Executive decision informed by the technical recommendation.
Publish the zones. Do not pull decisions back merely because you would have chosen differently. Intervene when agreed constraints, evidence or risk thresholds are not being met.
You cannot resolve a technical disagreement by choosing the person who sounds most certain. Ask the experts to state:
If disagreement remains, identify the accountable technical owner or run a time-bounded experiment. Your role is to ensure the process produces a decision—not to win a debate you are unqualified to judge.
Build a “decision vocabulary,” not a substitute engineering degree. Learn the system’s major components, customer-critical paths, security and reliability obligations, cost drivers, known constraints and measures of health. Ask for a recurring architecture or system walkthrough focused on business consequences.
Keep a glossary of terms you genuinely need. Stop when additional detail no longer changes a decision you own. Technical curiosity is valuable; anxious over-learning can become another form of avoidance.
Week 1: interview engineers about what helps and obstructs good decisions. Map recurring decisions and unclear ownership. Week 2: agree the two-level communication contract and the four authority zones. Week 3: facilitate one contested decision using criteria, evidence and reversibility. Week 4: ask for feedback: Where did I create clarity? Where did I add noise? What risk are you still reluctant to raise?
Do not ask whether the team “trusts you” in the abstract. Ask about observable behaviour and change one thing.
Do not promise dates before consulting the team. Do not demand certainty where only probabilities exist. Do not use one favoured engineer as your private translator; it distorts power and hides disagreement. Do not disengage from quality and risk because the detail feels uncomfortable. Do not make engineers responsible for resolving business priorities they do not control.
A product director inherits a platform team. Sales wants a custom integration for a large prospect; engineers warn that the requested approach creates long-term support cost. She does not decide the architecture. She clarifies the commercial value, asks engineering for two technically responsible options, requests support-cost implications, and brings a recommendation to the executive sponsor. The team owns technical judgement; she owns the organisational trade-off.
Leading experts is not about proving that you could do their job. It is about enabling their expertise to shape sound decisions while holding the broader system together. If insecurity keeps pushing you toward pretence, withdrawal or micromanagement, ongoing coaching can help you practise a steadier leadership position.
This page is part of the Her Success Coach resource library — a collection of practical articles, frameworks, and coaching programmes designed for women leaders. Explore in-depth guides on leadership confidence, career transitions, executive presence, imposter syndrome, delegation, strategic thinking, and difficult conversations at work. Book a 30-minute Clarity Session to discuss your goals, or join an on-demand course to develop the skills you need at your own pace.
Iveta Dulova is an executive and leadership coach for women with a decade of experience in global technology and a Diploma in Coaching and Leadership from the University of Cambridge. She works with women managers, directors, and founders across technology, financial services, and consulting who want to build executive presence, negotiate with confidence, and build a career that reflects their values rather than their fears.