What Leadership Presence Actually Means

The word "presence" in leadership conversations often conjures something performative - the ability to command a room, to project authority, to have a certain gravitas in front of an audience. This is almost entirely useless as a guide to how engineering leaders should operate.

In an engineering context, presence is something more specific and more functional. It is the experience the team has of being led: do they feel oriented? Do they know what matters and why? When things are unclear, do they know what to do with the ambiguity? When they need the leader, can they access them?

Leadership presence in this sense is not a personality trait. It is built through behaviours that are observable and learnable:

• Consistency - the same person across contexts; the same values showing up in the easy conversations and the hard ones; not a different leader in public and in private.
• Clarity - communication that is unambiguous about what is important, what is decided, and what is uncertain.
• Availability - not constant availability, which is both impossible and counterproductive, but reliable access at the points that matter.

Charisma is optional. Consistency is not.

Presence as Signal, Not Performance

The engineering context is useful here because engineers are unusually good at detecting inconsistency. They observe what actually happens - in code review, in planning meetings, in how incidents are handled - and they update their models accordingly. A charismatic all-hands presentation that contradicts what they observed in the last sprint retrospective will be noticed, catalogued, and factored into their trust model.

The inverse is also true. A quiet leader who consistently does what they say they will do, who is frank about uncertainty, who gives the same quality of attention to a junior engineer's question as to a senior stakeholder's - that leader builds genuine trust, which is a more durable form of presence than charisma.

Running Effective 1:1s

The 1:1 is the single most important recurring practice available to an engineering leader. Done well, it is where development happens, problems surface early, trust is built, and the leader gets an accurate picture of how the work and the team are actually going. Done badly, it is a status update that wastes both people's time and trains the engineer that their development is not a priority.

Structure and Purpose

A 1:1 has three potential purposes:

1. Development - what is the engineer working on in terms of growth? What is getting in the way? What do they want to be better at?
2. Connection - how are they doing, not just in work terms? What is the quality of their experience on the team and in the organisation?
3. Direction - are they clear on priorities? Is there context they need that they do not have? Are there decisions they are blocked on?

A well-run 1:1 touches on all three, in whatever proportion the person needs at that moment. A poorly-run 1:1 focuses almost exclusively on work status: "what are you working on? any blockers? great, same time next week."

Status updates belong in standups, ticket systems, and weekly updates. The 1:1 is not the right vehicle for them.

Whose Agenda

The most common structural error: the manager sets the agenda and the engineer responds. The result is a conversation that reflects what the manager thinks is important, not what the engineer needs.

The 1:1 should be driven primarily by the engineer's agenda. A simple question at the start sets this up: "What do you want to use this time for today?" or "What's most on your mind?" For engineers who are not used to this framing, it may take a few sessions before they start coming with real agenda items rather than "nothing specific."

The manager's agenda items - feedback to give, direction to communicate, context to share - belong at the end, after the engineer's needs have been addressed. If the manager always has so many agenda items that the engineer's needs get crowded out, the meeting should be structured differently.

Frequency and Format

There is no universal correct frequency. The general guidance:

• Weekly for people who are new, going through significant change, or need more support
• Fortnightly for established team members in stable situations
• Monthly at minimum for anyone on the team

The mistake is skipping 1:1s under delivery pressure. This is the equivalent of not checking your instruments because you are flying too fast. The times when the team is under most pressure are the times when the leader most needs to know what is actually happening.

Format is secondary. In-person, video, walking - whatever works for the relationship. What matters is that it happens consistently, at a predictable time, and that the engineer experiences it as genuinely useful.

Questions That Make 1:1s Valuable

Keep a bank of questions that open real conversation rather than producing status:

• "What's the most frustrating part of your work right now?"
• "Is there anything on the team that we're not talking about that we should be?"
• "What would make your job significantly better that we haven't done?"
• "What are you learning? What do you want to learn?"
• "What do you think I'm missing about what's going on right now?"
• "Is there anything I'm doing that is getting in your way?"
• "What does a good next six months look like for you?"

Most of these questions will not get a deep answer the first time you ask them. The relationship has to establish safety before real answers emerge. Asking them consistently, and responding well to the answers, builds the trust that produces honest responses.

Communicating in Uncertainty

Engineering organisations are in a state of near-permanent uncertainty. Business context changes, technology evolves, priorities shift, org structures get revisited. Leaders who can only communicate clearly when things are settled are rarely communicating clearly when it matters most.

The most common and most damaging response to uncertainty is silence. The leader does not know what to say, so they say nothing. The team fills the silence with the most anxiety-generating interpretation available to them.

What to Say When You Do Not Know

The "what we know / what we do not know / what we are doing about it" framework is simple and consistently effective:

What we know - state the facts clearly. Not the interpretation, not the implication - the facts. "The company has announced a restructure that will affect our division." "The product roadmap is being reviewed and we expect to know the outcome by the end of the month." "We have been asked to hold headcount decisions until Q2."

What we do not know - be explicit about the uncertainty. "We do not yet know what the team structure will look like on the other side." "We do not know which projects will be affected." This is harder than it sounds because leaders often feel that admitting uncertainty undermines confidence in them. The opposite is true. Pretending to know things you do not know is visible and destroys trust faster than acknowledging uncertainty.

What we are doing about it - what actions are being taken, what information you are trying to get, when you expect to be able to say more. This is the component that converts anxiety into productive waiting. "I'm in a meeting on Thursday where I expect to get more detail - I'll share what I can immediately after."

Why Silence Is Almost Always Worse

The instinct to wait until you have complete information before communicating is understandable but usually wrong. In the absence of communication, people generate their own explanations. In uncertain conditions, the explanations they generate are almost always worse than the reality.

If a leader says nothing for two weeks during a restructure, the team will spend those two weeks cycling through every plausible scenario, updating each other on rumours, and making career decisions based on anxiety rather than information. A brief, honest communication - "I know you have questions, here is what I know and here is what I don't" - is significantly more useful than silence, even if the actual information content is low.

The Frequency Question

More frequent communication in uncertain periods is almost always better, even if each communication is brief. A daily "no update yet, still expecting to hear Thursday" is more reassuring than silence followed by a large update. Frequency signals attention - that the leader is paying attention to the situation and will share when there is something to share.

Async-First Communication

Engineering leaders communicate through many channels - meetings, standups, Slack or Teams, email, documentation, code review comments. The quality of written communication - which is async by default - has a disproportionate effect on team clarity and alignment.

Writing Decisions Clearly

A decision communicated in writing should contain:

1. What was decided - unambiguous, in plain language
2. Why - the key reasoning, including what alternatives were considered
3. Who decided it - the owner
4. What changes as a result - implications for the team
5. What does not change - often as important as what does

The most common failure: decisions communicated as announcements. "We are moving to a new deployment pipeline from next month." This tells people the what but not the why, and leaves them to speculate about the implications.

The Difference Between a Memo and a Message

A message is a prompt for someone to take action or respond. "Can you look at the monitoring dashboards? Something looks off." This is fine for asynchronous communication of immediate tasks.

A memo is a communication that informs, orients, or explains. It is not asking for a response - it is providing context. Senior engineering leaders underinvest in memos. They rely on meetings to communicate direction, which means the communication is not recorded, is heard differently by different people in the room, and is inaccessible to people who were not in the meeting.

A short, well-written memo - "here is what we are doing, why, and what it means for you" - is worth three meetings. It is re-readable, searchable, shareable, and consistent across the team.

Practical guidance for writing memos:

• Lead with the conclusion, not the background. "We are adopting X because Y" not "We have been looking at X for some time..."
• Use short sentences and short paragraphs.
• Be explicit about what you want people to do, if anything. "No action required" or "Please review and surface concerns by Thursday."
• Write for the person who joins the team in six months and needs to understand why this decision was made.

The Async-First Principle

Meetings are expensive - the collective time cost is often invisible because it is distributed across many people's calendars. Before scheduling a meeting, ask: could this be a memo? Could this be a Slack thread? Could this be a short recorded video?

The cases where a meeting is the best vehicle:

• Decisions with high emotional stakes where the absence of back-and-forth creates risk
• Complex topics where real-time clarification is genuinely needed
• Relationship-building that benefits from synchronous presence
• Time-critical situations where async would be too slow

Most status updates, most informational sharing, most decisions with limited complexity - these are not good cases for meetings. They are good cases for clear written communication.

Listening as a Leadership Skill

Leaders who are technically strong and intellectually quick are often poor listeners. Not because they do not care - but because they are processing the incoming information against their existing models and arriving at responses before the person has finished speaking. The result is a conversation where the other person feels heard but not listened to.

Active Listening vs Waiting to Respond

Active listening is not a technique - it is an orientation. The question it asks is: what is this person actually communicating, and do I understand it accurately? This is different from: what will I say next, and do I have enough information to say it?

The distinction is visible in behaviour:

Signalling That You Have Heard Something

The difference between someone feeling heard and someone feeling listened to is whether the listener can demonstrate that they understood. This does not require agreement - it requires accurate reception.

The simplest practice: before responding, briefly summarise what you heard. "What I'm hearing is that the problem is not the new process itself but the fact that it wasn't discussed with the team first - is that right?" This is not parroting - it is checking. It gives the other person the chance to correct a misunderstanding before you respond to the wrong thing.

Listening to Understand vs Listening to Fix

Engineering leaders have a strong problem-solving instinct. When someone describes a problem, the instinct is to generate a solution. This is often not what the person needs. Sometimes they need to think out loud. Sometimes they need to be heard, not fixed. Sometimes the solution they need is one they will only find themselves.

The question to ask, explicitly, at the start of some conversations: "Do you want me to help you think this through or would it be useful to just talk about it for a bit?" Most people can answer this. Asking it prevents the frustration of offering solutions to someone who needed something different.

Narrative and Context

Engineers need to understand why. This is a genuine difference from some other professional communities. Engineers who understand the purpose of their work make better decisions, write better code, ask better questions, and spot misalignments that would otherwise surface late and expensively.

Why the Why Matters

An engineer implementing a feature who knows only the specification will implement the specification. An engineer who knows the user problem being solved, the business reason for prioritising it, and the constraints within which the solution needs to work will implement something better - and will flag it when the specification does not solve the problem.

The investment in sharing context - the business context, the strategy, the reasoning behind prioritisation decisions - pays for itself in the quality of the work and in the alignment between what gets built and what is actually needed.

Communicating Strategy in a Way That Connects to Daily Work

Strategy communicated as abstraction is useless. "We are prioritising developer experience" means very little to an engineer deciding how to structure a pull request. "We are prioritising developer experience because our build times have grown to 45 minutes and it is killing our deployment frequency - everything that reduces that is a priority" is actionable.

The translation job - from strategic language to operational meaning - is the leader's. Engineers should not have to do it themselves; they have enough to do.

A practical format for communicating strategy:

1. Where are we going? (in concrete, not abstract terms)
2. Why does it matter? (the business or user problem we are solving)
3. What does this mean for our team specifically?
4. What decisions should we be making differently given this direction?
5. What questions should this answer, and what questions does it not answer?

Narrative as Cohesion

Teams that share a coherent narrative about their purpose and direction are more resilient under pressure. When a difficult decision needs to be made under time pressure, a team that shares a narrative can apply it. A team that does not has to reconstruct from scratch, or defaults to local optimisation.

The leader's role in maintaining this narrative is not a one-off communication. It is regular, consistent reinforcement - connecting the work to the purpose, acknowledging when things have changed, updating the narrative when reality changes it.

Common Failures

Over-Communication of Activity, Under-Communication of Direction

Leaders who send many updates about what is being done and few communications about why, where things are heading, and what matters most. The team knows the leader is busy. They do not know what to prioritise.

This is often driven by a desire to appear active and in control. The more useful measure is whether the team has the context to make good decisions themselves.

The "My Door Is Always Open" Leader Who Is Never Available

A classic mismatch between stated and actual accessibility. The leader says their door is always open. In practice:

• Their calendar is back-to-back with meetings they cannot move
• Responses to messages take days
• 1:1s are frequently rescheduled or cancelled under delivery pressure
• When they are available, they are distracted

The gap between "my door is always open" and what the team actually experiences is a trust problem. It signals that the statement is performative, not real. The more honest and more useful approach: be explicit about when you are accessible. "I block Thursday afternoons for the team - that's the best time to grab me for anything non-urgent."

Communicating Decisions Without Context

"We're moving to a new platform" without the reasoning. "The team structure is changing" without the rationale. "We've decided to pause this initiative" without the explanation.

Decisions without context create two problems: people cannot apply the reasoning to their own decisions (so they will make worse adjacent decisions), and they feel excluded from the thinking, which erodes trust even when the decision itself is sound.

One-Way Communication

Leaders who broadcast and rarely receive. Town halls with Q&A where the questions are pre-screened. Updates where feedback is invited but not acted on. All-hands where the stage is occupied by senior leadership for fifty minutes and five minutes are left for "questions."

The team learns quickly whether feedback is genuinely wanted or whether the appearance of dialogue is what is being sought. If it is the latter, they stop engaging honestly.

Connection to Your Operating Model

Communication is the connective tissue of an operating model. The structures, the team topologies, the decision rights frameworks - all of these depend on information flowing accurately and at the right speed across the organisation.

Leaders who communicate well:

• Reduce the meetings needed for alignment (because people have context)
• Enable faster local decision-making (because people understand the strategic direction)
• Surface problems earlier (because people trust that honest communication is safe)
• Build higher-trust teams (because consistency between what is said and what is done is the foundation of trust)

Leaders who communicate poorly:

• Create coordination overhead (everyone needs a meeting to understand what someone else meant)
• Centralise decisions that should be distributed (because nobody has enough context to decide)
• Receive sanitised information (because honest feedback is risky)
• Build teams that are dependent on the leader to interpret the organisation for them

The investment in communication skill - 1:1 quality, written clarity, narrative consistency, genuine listening - is not separate from the work of building an effective engineering organisation. It is the work.

Your operating model is, in practice, what gets communicated, how often, how clearly, and in which directions. Everything else is aspiration.

Giving and Receiving Feedback

Communication is not only about direction and context. The feedback loop - the mechanism through which performance improves and problems get corrected - is a communication system. Most engineering leaders are worse at both giving and receiving feedback than they believe themselves to be.

Giving Feedback That Is Actually Useful

Feedback fails in two ways: it is too vague to act on ("you need to be more strategic"), or it is delivered in a way that makes the receiver defensive rather than curious.

Useful feedback has three components:

1. Specific observation - what you actually saw or heard. Not an interpretation. "In the design review, you presented the solution before explaining the problem you were solving" - not "you don't communicate well."
2. Impact - what effect it had. "The result was that two people in the room were evaluating a solution to a problem they hadn't understood yet, which is why the conversation was difficult."
3. Alternative - what would have been different. "If you'd started with the problem statement, the evaluation conversation would have been grounded."

The specificity is what makes it useful. Vague feedback produces defensiveness because the receiver cannot evaluate it - they can only accept or reject it. Specific feedback can be examined.

The Timing of Feedback

Feedback given days or weeks after an event is significantly less useful than feedback given close to the event. The closer to the behaviour, the more vivid the memory, the more the context is shared, and the more chance the person has to apply the learning immediately.

This means building the habit of giving feedback in the moment or very close to it - not saving it for the quarterly review or even the weekly 1:1. "Can I share an observation about how that meeting went?" asked in the two minutes after the meeting is worth more than the same observation delivered three weeks later.

Receiving Feedback as a Leader

Leaders receive significantly less honest feedback than they think they do. The higher you are in a hierarchy, the more effort people exert to avoid giving you uncomfortable information. This is rational - the consequences of challenging a leader are usually higher than the consequences of withholding a concern.

The result is that leaders operate on a systematically distorted view of how they are doing.

The practices that partially correct for this:

Ask specifically, not generally. "Is there anything I could do differently?" gets polite deflection. "In the way I ran last week's planning session, was there anything that didn't work well for you?" is harder to deflect because it is specific.

Respond non-defensively, visibly. The way you receive feedback in the moment determines whether you receive honest feedback in the future. If you explain, justify, or counter-argue when someone gives you critical feedback, the person updates their model - giving you honest feedback is uncomfortable and produces friction. They will give you less of it next time.

Act on it, and say so. "You told me last month that my 1:1s felt too focused on project status. I've been trying to shift that. Is it working?" This signals that the feedback was received, was taken seriously, and is being acted on. This is the behaviour that builds a feedback culture.

Communication Patterns That Scale

Individual communication skill matters. But communication at the team and organisation level also requires structural patterns - mechanisms that ensure information flows in the right directions at the right frequency without requiring the leader to be the bottleneck for everything.

The Information Radiator Principle

Information that is visible by default creates less coordination overhead than information that has to be requested. Teams that make their work status, decisions, blockers, and plans visible by default - through dashboards, public channels, shared documents - spend less time in synchronising meetings.

The leader's role: create and defend the norms that make information visible. Ask for updates in public channels rather than private messages. Write decisions in shared documents rather than email threads. Use tools that default to visibility rather than tools that default to privacy.

Update Cadences

A predictable update cadence reduces anxiety and reduces the number of people who come to the leader for information. The elements of a useful cadence:

The weekly update is the most impactful. A short, honest, consistently formatted weekly update - "here is what happened, here is what I'm concerned about, here is what's coming" - builds trust and reduces the information-seeking behaviour that creates noise.

Managing Up

Communicating well with your own leader is as important as communicating well with your team. The failure modes:

Over-reporting activity, under-reporting decisions and risks. Leaders want to know that the work is progressing, but they also need to know the decisions being made and the risks that are building. Activity updates without decision and risk context leave the leader with an incomplete picture.

Escalating problems without context or recommendation. "We have a problem with the authentication service" does not help a leader who does not have your context. "We have a performance issue in the authentication service that is affecting 5% of logins. I'm planning to have the team focus on diagnosis today and have a fix in place by Friday. The risk is X" gives them what they need to be a useful partner.

Waiting too long to share bad news. The instinct is to wait until you have a solution before surfacing a problem. The cost is that your leader is operating without information that affects decisions they are making above your level. Surface the problem early, with your current thinking, and invite collaboration on the solution.

The Communication Audit

A useful quarterly practice: audit your own communication patterns with the same rigour you would apply to a system.

Questions to ask:

• In the last month, how many decisions did I communicate with reasoning rather than just as announcements?
• How many 1:1s did I run where the engineer's agenda drove the conversation?
• When did I communicate in uncertainty rather than waiting until I had complete information?
• What feedback did I receive, and what did I do with it?
• Is there anything significant happening in the organisation that my team does not have enough context about?

The point of the audit is not to produce a score. It is to make patterns visible that are otherwise invisible because they are the defaults.

The most revealing question: Ask three members of your team: "Do you feel like you have the context you need to do your best work?" The answer tells you more about the quality of your communication than any self-assessment.

Communication in Difficult Conversations

Most leadership communication guidance focuses on the normal case - the 1:1, the team update, the planning session. The harder test is difficult conversations: delivering hard feedback, addressing underperformance, managing through an organisational change that is going to hurt people, or having a direct conversation about behaviour that is affecting the team.

These conversations are where leadership presence is most tested and most visible.

The Structure of a Hard Conversation

Hard conversations fail in two predictable ways: they are softened to the point where the message does not land, or they are delivered with such bluntness that the person becomes defensive and the message does not land for different reasons.

A useful structure:

1. State the purpose directly at the start. "I want to have a direct conversation with you about something that isn't working." Not three minutes of warm-up. The person already knows something is coming from the meeting invite; the warm-up just increases anxiety.

2. Name the specific behaviour or situation. Not the person's character or general approach - the specific, observable thing. "In the last three planning sessions, estimates have been significantly off, and we haven't had a conversation about why."

3. Share the impact. What effect is it having, on the team, the work, or the delivery? This grounds the conversation in consequence rather than judgment.

4. Invite their perspective. "What's your read on this?" The person's explanation may contain information you do not have. Or it may not - but giving them the chance to respond is both fair and strategically useful; you need to understand their perspective to address it.

5. Be clear about what needs to change. Not vague - specific. "I need the estimates to be more accurate, and I need us to have a direct conversation when you're uncertain rather than committing to something you're not confident in."

6. Agree a check-in point. "Let's talk again in two weeks and see where things are."

What Makes These Conversations Hard

The difficulty is almost always in step one and step five. Leaders delay starting the conversation ("I'll give it another week") and then soften the ask ("I just want to make sure we're on the same page"). The result is a conversation that was difficult to have and produced nothing useful.

The instinct to soften is humane. The effect is the opposite of humane - the person does not understand what is being asked of them, the behaviour continues, and the conversation that eventually happens is significantly harder because the situation has been allowed to compound.

A rule of thumb: If you are planning to have a difficult conversation, have it sooner and more directly than your instinct tells you to. The version of the conversation you are dreading is almost always not as bad as the version you will have in three months if you avoid it.

Delivering Difficult Organisational News

Redundancies, restructures, performance improvement plans, team changes that people did not choose - these are the situations where leadership communication is hardest and most consequential.

Principles that apply:

Deliver news directly, not through intermediaries or email. For significant personal impact, a synchronous conversation - even a video call - is the right vehicle. Learning about a redundancy from an automated email is not a communication failure - it is a relationship failure.

Do not over-explain. The temptation is to justify extensively, to explain all the business reasons, to make the person feel that the decision was rational. This is for the leader's comfort, not the person's. A brief, clear explanation of the reason is appropriate. An extended justification is not.

Sit with the silence. Hard news needs time to land. The instinct is to fill the silence with more words. Resist it. Ask: "How are you feeling about this?" and wait for the answer.

Be clear about what you can and cannot say. If there are aspects of the situation that are confidential - details of a restructure that have not been announced, for example - say so directly. "There are things I'm not in a position to share yet, and I want to be honest with you that that's the case." This is better than vague answers that feel evasive.

Building Trust Through Communication

Trust is built through the accumulation of evidence that what you say and what you do are the same thing. This is simpler to state than to practise, because the moments where the two diverge are often moments under pressure, when the cost of consistency is highest.

The Trust Equation in Communication

Trust in a leader is a function of three observable variables:

1. Reliability - do you do what you say you will do? Not 90% of the time. Consistently. The exceptions are noticed and remembered.
2. Accuracy - is what you say accurate? Do you communicate your uncertainty honestly or do you project confidence you do not have?
3. Intent - do people believe you are communicating in their interest, or in your own?

All three can be undermined by a single visible failure. Reliability is undermined by the 1:1 that was cancelled and not rescheduled. Accuracy is undermined by the confident prediction that was wrong. Intent is undermined by the communication that turned out to prioritise the leader's position over the team's interests.

This is not an argument for perfection - which is impossible - but for taking small consistency commitments seriously, because they are more observable to the team than large gestures.

What Kills Trust in Communication

Saying one thing in a 1:1 and another in a group. People compare notes. The discrepancy is discovered and it damages the trust of everyone who discovers it.

Communicating bad news after it is known through the grapevine. Being the last to tell your team something they have already heard from another source is significantly more damaging than being the person who tells them directly, even when you are not in control of the information flow.

Promises with no follow-through. "I'll look into that" and "I'll get back to you on that" are commitments. If you make them and do not follow through, every subsequent commitment is discounted.

Framing that does not match reality. Presenting a difficult situation as better than it is, or a decision that was made for political reasons as a principled one, or a constraint as a choice - people in the team usually know. The gap between the framing and the reality is a trust problem.

The antidote to all of these is not complex. It is consistency, honesty about uncertainty, and follow-through on commitments. None of it is dramatic. All of it is discipline.