Helping someone on your team improve is not one activity, it is three. Coaching, teaching, and directing are distinct modes of working with a person, and each is the right choice in different circumstances. A lot of leadership advice treats one of them (usually coaching) as the enlightened option and the others as failures of patience. In practice, a leader who can only coach is as limited as one who can only give orders. The skill is in knowing which mode a situation calls for, and moving between them deliberately.
Coaching is the most holistic of the three, and it takes the longest view. When I coach someone, my job is not to solve their problem, it is to help them introspect and answer their own questions. The conversation is built around what they think, what they have tried, and what they believe the options are. The problem in front of us is almost incidental; the real work is building their ability to reason through the next problem without me. Coaching compounds, which is why it is where I try to spend most of my time.
Teaching is what I fall back to when someone is not yet equipped to be coached on a topic. When the subject is too unfamiliar for introspection to get them anywhere, I instead ask leading questions to explore the concept with them, and/or demonstrate how I would solve the issue. Teaching is still interactive (they are working through it, not watching me or being lectured), but I am supplying the scaffolding they do not yet have. The aim is to build enough of a framework that next time, coaching becomes possible.
Directing is where I directly tell someone what to do. I will provide context where I can, because instructions land better when people understand the reasoning, but the defining feature is that the decision is mine and the direction is explicit. It is the least developmental of the three, and it is sometimes exactly what the moment requires.
Three attributes drive the choice for me: jeopardy, urgency, and capability.
Jeopardy asks: “what is the cost of them getting this wrong?” If the mistake would harm the company (a security incident, losing a major customer, a data loss), I must err towards directing and tell them how to avoid it. If the downside is a minor annoyance, like perhaps they explore a dead-end for a couple of hours, I can let them explore freely and treat whatever happens as tuition. Most situations sit somewhere between, and the honest question is whether I am comfortable underwriting the worst realistic outcome of them finding their own way.
Urgency asks: “how much time do we have?” If something is needed immediately, I have no choice but to direct; there is no room for a learning journey when the answer is due now. If there is a little time, I will teach. Ideally there is enough time for me to give them the framework and then let them resolve it themselves, which is where teaching starts to shade into coaching. This usually takes the shape of me explaining a customer problem or even sharing the customer feedback and asking the engineer to spend a few hours making a plan to solve it, which we review together.
Capability asks: “how close is this to something they have done before?” If the task is similar to their past experience, coaching is the ideal option, because they have the raw material to reason with. If it is pretty dissimilar to previous experiences, I will need to teach or direct, and the choice between those two depends on the size of the gap between their abilities and the demands of the task. A modest gap is a teaching opportunity; a chasm means directing them through it this time and building the capability afterwards.
The three attributes interact, and the most restrictive one wins. A capable engineer facing a novel problem with high jeopardy and no time gets directed, however experienced they are. The same engineer facing the same problem with low stakes and a loose deadline gets coached, however messy their first attempt is likely to be.
I try to coach as much as possible. It is the mode that builds durable capability, it signals trust, and it is the only one of the three that eventually makes me unnecessary for a given class of problem, which is the point of developing people in the first place.
But it is important to use the other two as necessary. Giving people freedom to grow can easily slide into giving them too little structure to learn. Coaching someone through a problem they lack the foundations for is not empowering, it is abandonment dressed up as trust. They will flail, feel lost, lose confidence, and learn less than they would have from an hour of honest teaching. Equally, refusing to direct in an urgent, high-jeopardy moment does not protect their development, it puts the team and the company at risk for the sake of a principle.
The failure modes are symmetrical. Direct everything and you build a team that waits to be told; coach everything and you build a team that was never shown. The leaders I have learned the most from moved fluidly between all three, and were transparent about which one they were using and why. That transparency matters: telling someone “I’m going to be directive here because we have two hours and the stakes are high, and we’ll do a proper debrief afterwards” preserves the relationship that coaching depends on, even in the moments when coaching is off the table.
The practical upshot of all this is a quick check before any conversation about a problem someone owns: what is the jeopardy, what is the urgency, and how far is this from what they have done before? Those three answers usually make the right mode obvious. The discipline is in actually asking yourself, rather than defaulting to whichever mode is most comfortable (for most of us that is either always rescuing people or always leaving them to it). Over time the assessment becomes instinctive, and the payoff is a team that gets the structure it needs when it needs it, and the freedom it can use when it can use it.
Applied consistently, this practice helps build a trusting and capable team that gets better and better with time. So don’t just coach - know when you need to teach, and even direct; your team will be better for it in the long run.
]]>As engineering teams grow, communication overhead grows faster. Every extra person adds more conversations, more channels, and more opportunities for information to get lost or duplicated. The teams that run smoothly are not the ones that communicate the most, they are the ones that communicate deliberately. Over the years I have settled on a set of conventions for how I use Slack, and they have made a noticeable difference to how quickly decisions get made and how little time we spend repeating ourselves.
The majority of communication should happen in public Slack channels. When a conversation happens in a DM, the information in it reaches exactly two people. When the same conversation happens in a public channel, it radiates outwards: teammates skim it, stakeholders spot things relevant to them, and people joining a project later can read the history rather than asking someone to repeat it.
Working in the open feels slower at first (there is a natural instinct to keep half-formed thoughts private), but the compounding effect of information reaching a wide audience by default is one of the highest-leverage habits a team can build.
Slack channels are free to create, and the unread tab makes it easy to stay up to date on a large number of them. That said, an unstructured sprawl of channels becomes unwieldy quickly, so we create channels in one of two modes:
project-design-system-v4, a long-running channel for all stakeholders of a project, and engineering-team-doc-brown, a team-based channel for coordinating work on whichever projects the team is tackling.incident-20260131-us-db-errors or event-20260412-ai-conferenceIf a channel does not fit one of those two modes, question whether it should exist.
There is some overlap - what if I’m working on some nuance for the design system project in team Doc Brown? The deciding factor is “do the broader stakeholders care or is this a purely functional conversation?”. So, for that example, the naming structure for the CSS will impact the design team as well as engineering, and deserves to be in the project channel. Reviewing the PR that implements it is purely an in-team thing for the team channel. The PR being merged may be worth a post in the project channel.
Threads are excellent for keeping a channel readable by allowing side-bars, but they have a failure mode: the never-ending thread that becomes a shadow meeting. Our rule of thumb is that a thread should not run for more than 12 messages. If a discussion passes that point, it is a signal that the topic is bigger than a thread can handle. Take it to a call, a short-term channel, or a written proposal instead.
Cross-posting the same message into multiple channels creates noise and waste. Everyone who follows both channels reads it twice, replies fragment across two locations, and nobody is sure which copy is canonical. Post in the single most appropriate channel and trust the open-by-default culture to carry the information to the people who need it.
The same discipline applies within a channel. Slack lets you send a thread reply to the channel as well, and this should be used for exactly one purpose: summarising the outcome when the thread concludes. It should not be used to keep both the thread and the channel updated as the conversation unfolds, which forces everyone to follow two versions of the same discussion.
I’ve also seen cases where people decide the channel to message based on who is already in there, rather than the context of the message. The canonical example would be a support engineer messaging about support tickets in the #engineering channel because they want an engineers help. However, we have a #support-engineering channel that has the superset of both teams in for this purpose, and it gives us one place to spot escalations and a single spot to audit to spot the topics that are getting escalated most frequently.
It’s much better to put the message in the channel that most closely represents the context and invite people to the channel as needed, rather than going to them (or even worse, direct messaging them). This keeps each channel as the chronicle for a given concept or type of work.
We use an emoji at the start of a message to denote it has extra importance or to add context.
For example, conversations meander, and the decision buried in message 12 of a thread is easy to miss. When a decision is made, we mark it with the 🦺 emoji to show this needs to be highly visible.
Some other examples are:
We carry these patterns into reactions to messages too, simplifying common interactions.
These are tiny conventions with an outsized payoff: anyone can scan a channel or thread and find the decisions and many actions taken in seconds, without reading everything.
Huge amounts of ‘filler’ conversation is replaced by an emoji - “Sorry but I don’t question follow what you mean, there’s not enough context in here for me to know what you’re looking at, can you explain more please?” becomes a simple polite 🔮 reaction.
An @-mention sends a notification, and notifications interrupt focused work. Reserve them for urgent issues that genuinely need someone’s attention now. In normal conversation, type the person’s name as plain text without the mention. They will see it when they next read the channel, which is soon enough for anything that is not urgent, and their concentration stays intact in the meantime.
Everything in Slack should be treated as having a shelf life of a couple of weeks. It is a stream, not an archive: search is unreliable, context evaporates, and conversations scroll away. Anything worth keeping longer (decisions, designs, playbooks, agreed processes) need to be promoted out of Slack and into internal documentation, where it has a permanent home and a clear owner.
A useful habit is to end any significant thread by asking whether anything in it deserves to outlive the fortnight. If so, the thread’s summary becomes the seed of a document. LLMs are proving very helpful in turning conversations into draft docs to kickstart that process.
None of these conventions are complicated, and each one on its own saves a few seconds or a single duplicated message. Together, they change the character of how a team communicates: information reaches the people who need it without being repeated, decisions are easy to find, interruptions are rare, and knowledge that matters ends up somewhere durable. That is what smooth-running looks like day to day, and it is built out of small, consistent habits rather than grand process.
]]>Engineers often prize being correct over most other things. After all, we are logical and want to make things as good as we possibly can.
Unfortunately, this makes certain types of conflict much more prevalent; many of us have worked with someone who is really smart and accustomed to being right. Maybe this is you; it’s certainly been me at least twice. This adds friction into our teams, and friction generates heat and wears things down.
It’s a delicate topic when we’re talking about the people we work with, but it comes up often enough that is worth some thought. The answer isn’t to empower a gifted “lone wolf” - that just sidesteps the issue and creates a single point of failure.
So what can we personally do to mitigate it?
An unfortunate pattern I’ve seen play out more than once is the smart engineer who is often right: so often that they find it difficult to be wrong. They might make snide remarks like “If we’d built it my way instead, this wouldn’t be an issue” or bring up their pet rework project every planning session, despite the idea being thoroughly discussed and decided it wasn’t going to provide enough benefit for at least a few years.
The team dynamics quickly shifted into factions:
Often, the difficult engineer would have one or two people who vehemently agreed with them in private, stoking the righteous fury that things were not as good they could be. Arguments were rehashed often, with decreasing respect, as both sides tired of the others perceived stubbornness.
In each case, the result was the same: trenches were dug and the team became highly dysfunctional until major interventions occurred.
While there are many great posts, books and talks on how to resolve conflicts like this, prevention is better than cure.
This is where the first quote really hit home with me:
Never win more than 70% of the time. [Citation needed]1
This advice really hits the mark in two different ways:
This advice does not mean “just shut up” or “argue the ridiculous to lose on purpose” - both of these options are going to deprive the team of your expertise or compromise your integrity and add to a feeling of immaturity around conflict.
Instead, shift your focus to asking better questions as neutrally as possible, and facilitate discussion towards a decent solution. Even if it’s not the best answer, help those around you work through it: give them the benefit of your expertise not by telling them an answer, but by making them think though the pitfalls they’ve not spotted yet. Make sure others are the ones in the spotlight.
By shifting into this mode at least 30% of the time, you can not only avoid fueling resentment, but you can still provide value in a way that helps your colleagues grow and makes you a better communicator.
One of the most precious resources we are trusted with as more senior engineers, is the time of those we are working with. This is both expensive in terms of raw capital used to pay everyone, as well as in the social capital that we gain when we help everyone succeed.
Failing to deliver carries a negative connotations, but most companies are trying to do things that haven’t been done before; this paradox of “break the mould but in a reliable way with no missteps” is probably one of the biggest contributing to poor performance in Software Engineering teams2.
We also learn most when we’re right on the edge of our comfort zone, and that means trying things that may not pan out.
I can accept failure, everyone fails at something. But I can’t accept not trying. Michael Jordan
Thankfully there’s a huge amount we can borrow from other fields to take sensible gambles. By far the biggest one is to always find the smallest step we can take from here to something that will generate feedback.
Sometimes this is easy an obvious, but other times not so much, and we need to go a bit off the path to find it.
A recent example is in building a logging/journal system, where we wanted to optimise for high throughput. However, writing all the data to disk isn’t very useful unless we can retrieve it too. This means the smallest features we could think to build amounted to half of the system - a journal writer and some indexer to perform basic queries against.
We discussed ways to find something smaller or easier to gain feedback that both sides could be fast enough.
The smart decision was to write the files with filenames that included the three fields we wanted to query by in the filename. No longer would we need to to build a whole indexer to query - for a minimum viable product, we could use good old find, or ls and grep. This halved what we needed to build and we had something working just about quick enough inside of 3 weeks instead of 6+.
It’s not always clear what the smallest step is, but it is almost always worth taking a small detour now to guarantee confidence tomorrow, rather than trying to build the perfect system and not getting confidence for two weeks.
The term “Authority Gradient” describes the perceived imbalance of power between colleagues of different seniorities. It has often been cited as a contributing factor to accidents, where a more junior person has spotted something or wanted to question something but has avoided it for fear of looking foolish or appearing to challenge their seniors. This is clearly a risk to software teams too, where we can have quite a wide spread of experience.
It is also easy to prioritise your own satisfaction of solving a problem over another’s. One of the most destructive things you can do to an engineer is deny them their sense of accomplishment. It can be as blatant and accepting praise without sharing credit, or as subtle as denying others the chance to solve a problem for themselves or in collaboration, but be mindful to collaborate and foster a sense of team success over individual when you can.
Another omnipresent risk is Imposter syndrome; while it is experienced at all levels, it’s possible to exaggerate it in more junior teammates when they see you easily complete something they are struggling with.
Showing that we are fallible can help demystify the areas where building things are more art than science, and show that recovering from mistakes, learning from them and not beating yourself up are all skills too.
Mistakes should be examined, learned from, and discarded; not dwelled upon and stored. Tim Fargo
Dwelling on mistakes is something that I’ve spent far too much energy on in the past, and that brainpower could be spent on fixing the issue rather than replaying the mistakes. I hope to help those around me accept, learn and recover faster than I have in the past.
I find it useful, both for the team and myself, to share a short summary of mistakes that have happened. This can be written or, if short enough, said at a retrospective or stand-up meeting. The recipe is simple:
I often advocate for working through problems and thought-processes aloud when possible, but there is a hidden gotcha in this too. Being too vague around key mechanisms can really cause a focussed team to suddenly diverge just as momentum is building. For example, knowing that you are building 3 components that will pass data around is fine, but deciding that data will be JSON with certain pre-designed keys can vastly de-risk a project.
This is where another excellent quote comes in:
Vague sticks around, but Wrong gets Corrected Tanya Reilly - The Staff Engineers Path
It’s better to decide something to the resolution that it can be worked with and built again, even if that thing is wrong.
The assertion might be wrong, but it’ll definitely be spotted and discussed or documented if it doesn’t work. A vague option can lurk, fester and spread, adding bet-hedging code that may never be removed or discussed.
All of the above advice served me very well. However, as I moved into roles with more influence, it’s been important to remember that you can also say too much. For example, in situations with a large experience gap, a principal engineer’s half-baked wondering could become a junior devs project for the week.
It’s always important to be mindful of your audience, and be extra mindful to show more junior devs the process to derive an answer. Idle wondering in-front of a senior who knows enough to know a bad idea when they hear it is one thing, but be careful to explain a few options and why you’re recommending one over the other to more junior colleagues.
Some situations are going to need you to lead much more directly; perhaps it’s a live issue, or you have more context or insight into a time sensitive problem, and you can’t afford to trade speed for harmony. There are two key rules for these times:
Being wrong helps to humanise one another, makes space for everyone to contribute, and fosters trust and collaboration. But like so many things, it is just one tool. Leaning too hard on it so hard that people feel pandered to, or that you genuinely don’t know what you’re doing.
However, as your experience gives you ready answers in more situations, it’s important to not lose sight of the power of being wrong.
I can’t find the source for this but I heard it once and it really stuck with me - if you know where it is from then please get in touch! ↩
Apart from all the other ones. ↩
The best interview processes will recognise that it is a two way process:
As a candidate, you should get a chance to ask some questions and learn as much as you can about what it is actually like to work there.
This can be daunting, so I’m keeping this page updated with a list of questions I’ve asked or been asked that have given some really great insights or triggered interesting conversations.
If you have any that you’ve used or heard, then please let me know! My social links can be found on my homepage.
Try to root your questions in what actually happens by asking for a recent example rather than an opinion.
“How would you deal with a production issue?” invites someone to tell your their ideal process, whereas “Can you tell me about how a recent issue was resolved” asks someone to recall what happened.
Taken the wrong way, some of these questions can sound judgemental.
No organisation is perfect, so be aware that you could be putting someone on the spot - they are going to want to show their organisation in a good light.
Be especially alert for anyone acting defensively or embarrassed - it’s important to be respectful and reiterate that you want to know the reality of the job you’d be doing, and that it’s unrealistic to expect perfect.
At the same time, don’t be fobbed off! We do our best work when we’re engaged and nothing will kill that faster than finding out that the culture doesn’t align with your values or that your role doesn’t match what you expected to be doing.
You’re not going to have time to ask all of these questions, so focus on the areas you have the most doubts and care about the most.
These are loosely categorised to help find something while actually in an interview, but questions can easily overlap.
How does a feature go from an idea to being in front of customers? via Garry Shutler
How were your/the teams most recent objectives decided and communicated?
What is the process to order a book or go to a conference?
Who is involved in designing features?
How does that process ensure a wide range of viewpoints are considered?
How often are the company values often mentioned outside of the review/360 process?
When was the last time the company values were reviewed or changed?
How did that process happen?
What would you change about your culture? via Garry Shutler
How many conversations happen in public Slack channels vs direct messages?
How are big strategy decisions made, recorded and communicated?
How hard do you find it to get time to discuss issues with someone you don’t work with daily?
Can you tell me about a recent disagreement and how it was settled? via Mark Harbottle
How do you ensure the company/department is working effectively? via Garry Shutler
What is done to communicate these issues to the company and customers?
How does the company make it’s money?
What is done to provide stability and resilience in uncertain times?
What experience do the leadership team have of starting/scaling/running companies?
What are the shortest and longest running projects you’ve seen in the last year?
Can you tell me about a time something went badly?
What were the causes and the resolution?
How safe is it to make a mistake?
What was done after your last live incident to ensure it didn’t happen again?
What does being on call look like? via Garry Shutler
How are live issues triaged and dealt with?
How are bugs managed? via Garry Shutler
How long did your last change take to go from reviewed/approved to in front of a customer?
How are new feature releases communicated both internally and externally?
What’s an area or project that people don’t like working on?
What’s lead it into that state?
Is there a plan to tackle it?
What is the biggest issue you are facing right now?
What is the next bigger problem you foresee having? via Garry Shutler
How do you know a feature is providing value? via Garry Shutler
How automated are the processes for running the team?
How many things are late or missed because of people being too busy or having forgotten?
What visibility does the average engineer have on the scale and performance of the system?
What visibility does the most privileged engineer have?
How much autonomy will I have?
What is the biggest challenge for <role/team>?
What would the perfect candidate have completed in 6 months?
What do you think the most important obstacle to overcome is in that time frame?
]]>What are the growth opportunities for someone in this role? via Garry Shutler
It is hard to be respectful, concise and also convey how strongly held an opinion is. Is a comment in a code review just a suggestion or an essential comment which cannot be ignored?
There’s a simple system that has really helped a few teams with these scenarios:
Assign how much you care about an opinion or comment out of ten.
This gives an instant reflection of how confident you are, or how important you think a comment is.
For example, during a code review I’ll write something like:
1/10: this would be easier to read if split over 3 lines.
or
8/10: this will cause a breaking change for accounts with X enabled.
This gives the reader an insight as to how vital this comment is without needing a lot of words; It’s easy to see that a 1/10 issue is a minor matter of taste that could be addressed or ignored, while the 8/10 comment is a serious issue that needs some thought.
For example, Alice and Bob disagree on the best design, and neither has managed to convince the other after a discussion. Alice is 7/10 confident while Bob is only 4/10, so they agree to go with Alice’s choice.
This has also worked well when discussing solutions in person - it’s just become part of the way we communicate. Someone might make a statement and then say “That was all 3 out of 10 level stuff” and we all instantly have an understanding of the confidence and importance they wanted to convey.
The numbers themselves don’t mean something concrete - there is not a formal definition. The goal is to make people consider the strength of their convictions; similar to tools like Planning Poker.
However it can be useful to have a rough guideline to foster a common understanding so here’s an outline of how I think of it:
| 1/10 | Very optional feedback (almost always about stylistic choice around formatting) |
| 3/10 | Far from critical but made me frown; others will probably notice or be distracted by it. I use this as the threshold for still approving a PR without wanting more of a discussion. |
| 5/10 | This issue feels important and needs reconsidering/discussing |
| 7/10 | This is important and I think I may have a better idea here |
| 10/10 | This will literally destroy the company/team/customers/planet |
This system won’t save you from a colleague who feels like they need to “win” discussions.
It’s a tool to save time and overly-polite wrangling in a respectful dialogue. The goal is to help you communicate clearly and find the best path together, not just say the biggest number.
I’ve benefited greatly from the time saved and clearer gauge of how much things matter to my colleagues, and I hope this helps you and your team achieve the same!
]]>