Practical posts for tech and systems leaders who want their work to be seen.https://jessestaffordcoaching.comen-ushttps://jessestaffordcoaching.com/blog/frontline-managers-feel-powerless-actually-changeshttps://jessestaffordcoaching.com/blog/frontline-managers-feel-powerless-actually-changesYou can get better at every part of this job and still never get your hands on a wheel that was never connected to yours in the first place. Being a...Tue, 20 Oct 2026 00:00:00 GMT*You can get better at every part of this job and* *still never get your hands on a wheel that was never connected to yours in the first place.* Being a front line manager is like trying to get everyone on a bumper car ride to go the same direction and not run into each other. Except the ride is bolted to the back of a truck driving around the city, and you don't know where the next turn is. I spent most of a quarter building a buffer. A new intake process, a review step, a way to filter decisions from above before they hit my team directly. I thought I was protecting people. It did not work. The decisions still landed. My team still felt them. All I had actually built was a delay, and a new layer of process for people to route around when it got in the way. I had solved the wrong problem. ### The Authority Gap Every Frontline Manager Feels Here is the pattern underneath that mistake. You are accountable for outcomes your team produces, and your team expects you to be able to change the things that shape those outcomes. Some of that is true. A lot of it is not. You have real authority over your team, how you run your 1-on-1s, what gets prioritized, how you communicate with people day to day. You do not have authority over the decisions made above you that your team still has to live with. Those two things get treated as one job. They are not. Most frontline managers respond to that gap by trying to compensate. Communicate more. Add process. Try to influence harder. None of that changes the structure, because the problem was never a skill gap. It is a structural one. Part of why this gets missed is how most people get promoted into the role. You get moved up because you were excellent at the technical or individual work. Nobody hands you a map of what authority actually comes with the title and what does not. You find the edges of it by hitting them, usually in front of your team, sometimes when a decision they are counting on you to change turns out to be one you never could. ### The Shift: Three Circles, One You Actually Drive I use three terms with every leader I work through this with: circle of control, circle of influence, and circle of concern. Picture your team as a bumper car ride. You set the pace, referee the collisions, decide who rides together. That is your circle of influence. The authority inside it is real, and what you are doing there is shaping outcomes, not guaranteeing them. Now picture the whole ride bolted to the back of a truck someone else is driving. You did not pick the route. You cannot grab the wheel. That truck is your circle of concern. You can care about where it is going. You cannot move it. Your circle of control is narrower than either. It is what you can change directly, without asking anyone above you: how you communicate with your team, what you prioritize this week, how you show up in the next hard conversation. Circle of influence is real. It is just not control, and treating it like control is what burns leaders out. It is also what pushed me to spend a quarter building a process that never had a chance of solving the actual problem. ### What the Data Says About Frontline Decision-Making This is not just a feeling. Interactive EQ's 2026 Behavioral Intelligence Index ran more than 5,000 workplace simulations with over 1,700 professionals across 46 organizations and found executives acted decisively more than 90 percent of the time, compared with 58 to 62 percent for people in frontline and customer-facing roles, even when the delay made outcomes worse ([source](https://www.globenewswire.com/news-release/2026/02/18/3240307/0/en/40-of-Professionals-Struggle-with-Accountability-When-Reputational-Risk-Rises-New-Research-Finds.html)). That gap is not a decisiveness problem. That is what happens when you are held responsible for a decision you never had the authority to make. DDI's 2025 Global Leadership Forecast found a related pattern from a different angle: 71 percent of leaders report significantly higher stress since stepping into management, with competing demands from above and below cited as the top cause ([source](https://www.ddi.com/about/media/global-leadership-forecast-2025)). ### Technology Leader Communication: Context Over Process Once you see the split, the fix is not more process. It is more context. When a decision you cannot change frustrates your team, the instinct is to build a buffer between them and it, a translation layer, a filter, a new step in how information reaches them. That buffer does not remove the friction. It just moves it, and it adds a layer people eventually learn to route around. What actually helps is telling your team the real business reason behind the decision, including the parts you do not love. That gives people something to work with when they have to respond to a situation you cannot fix. A new process just tells them to stay in their lane and wait. **Real authority over your team does not translate into authority over the truck.** Both are true at once, which is exactly why the tension does not disappear just because you got better at your job. ### What Not to Do: The Buffer That Backfires Here is what the quarter I spent building process actually looked like from the inside, because it is worth naming specifically. I added a review step so decisions from above would come to me first, get "translated," and then go to the team in a cleaner form. It felt responsible. In practice, it meant my team got information later than they used to, filtered through my interpretation instead of the source, and with an extra step for anyone who wanted to ask a clarifying question. I had made myself a bottleneck and called it protection. The fix was not a better process. It was dropping the process and telling my team directly: this came from above me, here is why I support it, and what I know about how it supports our goals. That was slower to build trust in the moment and faster in every way that mattered afterward. If you are currently building a buffer, a process, a filter, a translation layer between your team and a decision you cannot change, that is worth a second look. It is very likely solving the wrong problem the same way mine did. ### How to Tell Control From Influence Before You React When something on your team is frustrating people, the fastest way through is to ask what you're actually looking at before you decide what to do about it. Can you change this outcome directly, today, without asking anyone above you? That is your circle of control. Handle it. Can you raise it, make a case, and shift it before the next decision point, but not force the outcome? That is your circle of influence. Spend your energy there before the decision locks, not after. And if the honest answer is neither, you are looking at your circle of concern. The only real move left is telling your team the truth about that plainly. Not pretending a new process will make the powerlessness go away. Just: here is what I know, here is what I do not, here is where the decision actually sits. ### Monday Action Before your next 1-on-1, identify one decision your team is currently frustrated by that you did not make and cannot undo. Skip the buffer. Tell them directly what you know about why it happened and what you genuinely do not know. Watch what happens when they have real information instead of a filtered version of it. <hr /> What is something your team expects you to control that you actually do not? <hr /> You're great at the work. Let's make you impossible to ignore. If you are looking for help leading a team you do not have full authority over, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/technology-leaders-get-wrong-confidence-duringhttps://jessestaffordcoaching.com/blog/technology-leaders-get-wrong-confidence-duringYou are already airborne. The business took off before the transformation started.Tue, 20 Oct 2026 00:00:00 GMT*You are already airborne. The business took off before the transformation started.**You do not need every answer, you need the conviction to move with the ones you have.* Seventy percent of organizational change initiatives fail. Not because the strategy was wrong. Not because the plan was unworkable. The research points consistently to the communication layer: what leaders do and do not say to their teams while the change is in motion. Organizations with excellent change management practices achieve their project objectives 88% of the time. Organizations with poor change management practices: 13% ([Prosci, 2026](https://www.prosci.com/blog/5-strategic-decisions-for-building-organizational-change-capability)). That is not a marginal gap. It is the difference between almost certain success and almost certain failure. The single biggest driver of that gap is not the change itself. It is whether leaders communicate clearly about it while it is still being built. ### Why Technology Leaders Go Silent During Organizational Transformation The pull toward silence is understandable. When transformation is underway and the details are still being resolved, leaders feel exposed. They do not have clean answers. The plan above them has not finished forming. Some decisions have not been made yet. The instinct: wait until you have something complete to say. That instinct is expensive. When a leader goes quiet, the team does not wait patiently for information. They fill the gap immediately. They do not fill it with the most optimistic interpretation. They fill it with the worst version of the story they can construct from what they have observed, overheard, and pieced together. By the time the leader has something clean to communicate, the team has already built a narrative. That narrative is usually wrong, and it is usually bad. The leader is now not informing the team. They are trying to correct a story the team has already decided to believe. This is how change fails at the communication layer. Not because the message was wrong. Because the absence of message ceded the space to something worse. ### Leadership Confidence During Change: Not the Same as Having All the Answers There is a distinction that does not get made clearly enough: being uncertain about the details is not the same as being uncertain about the direction. Leaders who confuse these two things end up in one of two failure modes. Some perform certainty they do not have, projecting confidence about specifics they cannot actually guarantee. Others go silent, treating uncertainty about details as a reason not to communicate anything. Both fail for the same reason: the team cannot tell the difference between "we do not have the exact timeline yet" and "we do not actually know where we are going." The leadership move is to separate these clearly and deliberately. You know where you are going. You know the reason the transformation is happening. You know what success looks like at the end. You know what is staying the same. What you do not have yet: the exact path. Some downstream decisions. A few process implications still being resolved. **Lead with what you know. Acknowledge what you do not.** That sequence is not obvious to every leader, but it is the sequence that keeps the team with you. "We are moving toward X. Here is why I believe this is right. I do not have every step mapped yet. Here is what we are doing next." That is a complete leadership communication. It does not require perfect information. It requires knowing the difference between your direction and your gaps. ### Technology Manager Communication During Organizational Transformation The data from Prosci identifies visible, ongoing communication as the factor most consistently linked to change success. Organizations with active leadership involvement achieve a 73% success rate on change initiatives. Organizations without it: 29% ([Prosci](https://www.prosci.com/blog/5-strategic-decisions-for-building-organizational-change-capability)). This is not about enthusiasm or a single well-crafted announcement. It is about sustained, repeated, directional communication over the life of the change. There is an old principle that people need to hear something seven times before they understand it. That principle forgets to add: it is seven times per person. A team of ten requires roughly seventy repetitions of the same core message before it has actually landed consistently. What feels like overcommunicating to the leader is often the first or second time the message has genuinely reached some members of the team. Vary how you say it. Use your team meetings, your one-on-ones, the hallway. Same direction, different words. The message must be consistent. The delivery does not have to be. ### The Three Things Your Team Needs to SEE During Transformation Communication is not just what you say. It is what you do. A leader who states direction clearly but hedges on every actual decision sends a contradictory signal. The team hears "we are going this way" and then watches the leader wait for permission before taking any step. Three visible actions matter more than any message. **Make decisions when decisions are needed.** Waiting for certainty is how leaders end up not deciding. And not deciding is a decision. It just reads as absence. When a call has to be made, make it. You will not always have perfect information. The team needs to see that you can function without it. Make the call. Adjust when the situation requires. **Name it when you have adjusted, and say why.** Leaders who change course without naming it create confusion. The team notices the shift. If you do not name it, they interpret it as evidence that the original direction was uncertain, or that the leader is operating without a real plan. Naming it does the opposite: "We made this call based on what we knew. We have better information now. Here is what we are adjusting." Visible adjustment is not a credibility problem. It is a credibility signal. It tells the team the leader is paying attention. **Keep showing up.** One-on-ones during transformation are not problem-solving sessions. They are the space where team members get to say what they are actually thinking. Your job in those conversations is not to have answers. It is to be present. The team does not need you to have the situation resolved. They need to know you are engaged with what they are working through. Presence is itself a form of direction. It says: we are in this together, and I am not going anywhere. ### The Alternative to Building the Plane While Flying It The alternative to leading while the plan is still forming is not landing safely and starting over from the ground. Landing is not a neutral option. Landing means stopping the business. No revenue. The organization stops. You are already airborne because the business took off before this transformation started. You would not be going through a change this significant if you were not already moving. The plane is in the air because you need to keep making money while you rebuild. That is the only reason you are building it while flying. The team is already in motion. The transformation is already underway. What the team needs from you is not certainty. They need someone who can function at this altitude. Acknowledge the gaps. Be clear about the direction. Make the next call. > **You do not need all the answers to lead your team through this. You need the conviction to move with the ones you have.** ### Monday Action Pick one decision you have been delaying because you are waiting for more information. Ask yourself: do I not have enough information to make this call, or am I waiting for certainty I am unlikely to get before the cost of waiting exceeds the cost of being wrong? If the answer is the second one, make the call today. Tell your team what you decided and why. If you need to adjust later, you will. Leading under uncertainty is not about making perfect calls. It is about making calls. <hr /> Have you watched a leader handle transformation with real confidence under uncertainty? What did they do differently? <hr /> You're great at the work. Let's make you impossible to ignore. If you are looking for help leading your team through organizational change, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/validating-ai-output-real-work-gethttps://jessestaffordcoaching.com/blog/validating-ai-output-real-work-getValidating AI output is some of the most useful work on an engineering team right now, and it is also some of the hardest to point to. I found out what...Tue, 20 Oct 2026 00:00:00 GMTValidating AI output is some of the most useful work on an engineering team right now, and it is also some of the hardest to point to. I found out what that looks like in a contract review. I was reading the statements of work, the whole thing, because I had some extra unallocated moments. A teammate had not read them and had produced an AI summary instead. That summary had hallucinations and errors that would have set back our negotiations. Because I had read the source, they were not set back. There was no crisis and no recovery plan. From the outside, nothing had happened. The catch is real, and it leaves no trace. ### Why Validating AI Output Never Shows Up on a Dashboard Every dashboard your team reports from counts what got built. Pull requests merged, features shipped, tickets closed. That is generation, and generation is easy to count because it produces an object. A catch produces an absence. Nobody opens a ticket for the outage that did not happen or the permission that was fixed before anyone relied on it. On my teams, bug bashes before release work this way. We built them to get the most eyes possible on a project before it shipped, and they turned up several problems that would have been major after release. We handled them early, and almost nobody noticed. AI tools add to this pile, because a model can hand you a contract summary, a block of code, or a plan that reads as finished and is not. Some engineers online complain about spending more time reviewing AI output. That is not quite what I see on my teams. I see a harder question: how do we keep quality high when people who are not yet experienced at driving AI to good results are the ones submitting work? ### The Hidden Cost of Checking AI Work Checking has a price. A September 2025 study from BetterUp Labs and Stanford's Social Media Lab, published in Harvard Business Review, found that sorting out a single low-quality AI-generated deliverable took the person on the receiving end close to two hours ([HBR, "AI-Generated 'Workslop' Is Destroying Productivity"](https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity)). Generating something is cheap. Catching what is wrong with it is not. It can also feel thankless. You read the whole thing while everyone else moves on. Then you decide whether to say anything, because saying it can feel like pointing at a teammate. A lot of people quietly fix it and keep going, and the week's update has nothing to say about it. **A good catch looks exactly like a quiet week.** ### Who Owns Making Validation Work Visible? When I asked myself if making this visible should be more of a manager responsibility or an individual responsibility, I landed on both. The person who did the checking, and the manager who could be asking. Managers only know what their team tells them. They then amplify that message to the people above them. People tend to believe their manager knows and understands everything they are doing, and it just is not true. Do you know everything your manager does? Nope. Quality is everyone's problem. Anyone who is working to only solve their own task is not paying attention to what the product and the business really need. **The first line of defense belongs to whoever brings the tool in.** If you are the one promoting an AI tool on your team, you own the first check, and then everyone needs to be involved. ### Why "Show Your Work" Needs a Different Move for Validators I have spent years teaching people to show their work, and I wrote more about that idea in [my earlier post on showing your work](/blog/stop-managing-up-start-showing-work). That advice assumes you built something to point at. You share your plan, you update on progress, you say what is next. The person doing the checking did not build the thing. Their value is what did not happen. You cannot share a plan for work that was never needed, so the move has to be built around the catch itself. A manager who cannot see the work fills the gap with questions, or with assumptions that the work was never hard. I have written about that dynamic in [The Communication Gap That Triggers Micromanagement](/blog/communication-gap-triggers-micromanagement-close). The validator problem is the same gap, seen from a different angle. ### How to Report a Catch Your Manager Can Repeat I do not have a good answer to this yet. What I keep coming back to is this: **make it about business impact, not technical challenge.** Tie it up for your manager and give them something they can repeat with minimal translation. If they have to decode it first, it stops with them. Your manager carries your work into rooms you are not in. So use three parts, in one or two sentences: what you caught, what it would have cost the business, and what you did about it. A sentence in that shape might sound like this: > "I read the full statements of work and found errors in the AI summary. If we had worked from it, our negotiations would have been set back. I corrected it before anyone used it." And here is the team-level version: > "Our pre-release review turned up problems that would have been major after launch. We fixed them before customers saw anything." Compare either one to "I reviewed the contract summary." Your manager can say the catch out loud in a meeting. "I reviewed it" only tells them you were busy. #### What About Process Fixes Like Quality Gates? Some teams respond with structure: a rotating quality check, or a short written reason when someone approves AI-assisted work. They are worth having. They still do not tell your manager anything until someone says it out loud. The sentence has to come first. For more on how information gets lost between layers, see [my post on why information does not reach employees](/blog/information-doesnt-reach-employees-fix). ### What to Leave Out of a Catch Report The test is business impact, not technical challenge. That means the report is not the place for the tour of how hard the check was. Your manager does not need the stack trace, the tool names, or the hours. They need the part they can say to someone one level up. Keep the technical detail where it belongs, in the ticket or the review thread, in case someone wants to dig deeper. The sentence you send is the one that travels. If you cannot say what it would have cost the business in plain words, that is a signal to ask yourself what the catch actually protected. It is also a little deflating to boil hours of careful work down to one line, and it is still the line that gets repeated. ### What Leaders Can Do to Make Validation Count If you lead a team, you have a move too. Change what you ask about. If the only number anyone brings to you is what shipped, you will quietly teach people that checking does not count, and the careful ones will stop bringing it up at all. Nobody likes doing work that gets no reaction, and people notice quickly when it never will. Ask "what did you catch this week," and then repeat the answer upward. That question changes what people bring you, and it hands you the line your own manager needs to hear. ### On Monday, Look For This The next time you finish checking something and find a problem, write the sentence before you close the ticket: what you caught, what it would have cost the business, what you did. Send it to your manager that same day as a plain update, written so they could repeat it without changing a word. <hr /> If you caught something this week before anyone else saw it, who knows? <hr /> You're great at the work. Let's make you impossible to ignore. If you are looking for help turning checking and fixing work into something your manager can see and repeat, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/ai-notetakers-one-on-ones-theyre-actually-costinghttps://jessestaffordcoaching.com/blog/ai-notetakers-one-on-ones-theyre-actually-costingGetting consent is the legal minimum, not the fix. A signature does not make someone forget there is a second audience.Sun, 18 Oct 2026 00:00:00 GMT*Getting consent is the legal minimum, not the fix. A signature does not make someone forget there is a second audience.* The next version of this is already happening. I have seen it come up often enough now that it stopped feeling like an edge case. Some managers have started using AI to score the sentiment of 1-on-1 conversations. Not what was discussed, not action items, but whether the person on the other side sounded positive or negative. No conversation about it beforehand, no explanation of who sees the score or what it gets used for. Just a running record of how someone came across, building quietly in the background of a meeting that used to be theirs. Once you know this pattern exists, it explains itself in one sentence: the person across from you now has to manage not just what they say, but how a machine will grade the way they said it. When leaders bring this into a coaching conversation, the first question usually turns legal: can my employer record me on company property? In most places, yes. That is also beside the point. The real question is not whether it is legal. It is what it feels like to walk into a conversation that used to be safe and realize it is being graded. ## The AI Notetaker Trust Problem Nobody's Naming Most of what gets written about AI notetakers is a legal or IT conversation: consent requirements, data retention, which vendor has the least risky terms of service. That conversation matters, and it is also missing the actual damage. A 1-on-1 only works because a direct report believes they can say the true version of something and not have it come back to hurt them. That belief is fragile. It does not survive a "yes, but" the way a project deadline does. The moment someone has to wonder who else might read a transcript, or how a sentiment score might get referenced three weeks from now, they stop answering the real question and start answering the safe one. I have watched this happen from the other side of a very similar setup. Early in my coaching training, recording client calls was standard practice, every client agreed to it, and I recorded so my supervisor could review my work. What I noticed had nothing to do with my coaching skill. Clients gave shorter answers once the recording started, less emotional depth, the same person and the same question producing a visibly smaller answer than the one I knew was actually in there. ## Why Consent Doesn't Fix the Chilling Effect None of that changed once I moved to a recorder my clients could not see as easily. The consent was identical. What changed was how present the recording felt in the room, and the answers got longer again the moment it stopped feeling present. That gap between agreeing to something and forgetting it is happening is the whole mechanism. **Consent is a real requirement, and it is also not the fix leaders think it is.** A signature does not make someone forget there is a second audience. **One in three U.S. workers now say an AI notetaker or transcription bot has sat in on their meetings.** Only about a third of that group say they were reliably asked for permission first, according to a 2026 survey commissioned by Kolmogorov Law and reported by ABC17 News. That means most of the workers experiencing this did not get a clear conversation about it at all, let alone a chance to ask what happens to the recording afterward. And even in the minority of cases where someone was asked, the research on how people actually behave once they know a recording exists tells you consent alone will not restore candor. People do not stop talking. They start managing what they say, which looks identical from the outside and is not the same thing. ## How to Keep 1-on-1s Honest When an AI Notetaker Is in the Room If you are serious about protecting the one meeting built for honesty, the work is behavioral, not procedural. A policy in an employee handbook does not do it. **Say what the tool is for, out loud, every time.** Silence about a recording tool is what makes people fill in the worst-case explanation themselves. Tell them who can see the notes, how long they are kept, and what they get used for. Ask what kind of tool you actually have running. A notetaker that only captures what was decided is a different animal from one that scores tone, and if you cannot explain in one sentence why the second kind needs to exist in this specific meeting, it does not belong there. The chilling effect rarely looks like someone refusing to talk. It looks like an answer that used to run three minutes now running thirty seconds, and that shift is the signal, not just a quiet week. **Watch for the shorter answer, not just the missing one.** You do not need artificial intelligence to solve a trust problem. I switched from a visible recorder to a handheld one set near my speakers and got longer, more honest answers back, with the exact same consent in place. A notebook works fine for the conversations that matter most. ## When AI Notetaking Goes Too Far: The Sentiment-Scoring 1-on-1 The sentiment-scoring pattern described above is not a rare edge case. It is where this practice goes once nobody puts a boundary on it, and it is worth sitting with as its own example rather than a footnote. A tool that only logs action items is annoying at worst. A tool that scores whether someone "sounded positive" turns every word choice into something with a running tally attached, and it does that without the direct report ever agreeing to be evaluated that way. The person on the receiving end of this is not upset about being recorded. They are upset that a machine is quietly deciding how they came across, in a meeting where showing up unpolished was supposed to be allowed. This is also where "just get consent" fully falls apart as a fix. Even a direct report who signs off on a sentiment tool is not signing off because they trust it. Plenty of people will consent out of obligation to their job, then quietly adjust what they say to avoid anything that could read as career-limiting later, exactly the behavior the tool was never supposed to cause. You cannot tell that group apart from the group that is genuinely fine with it, because the transcript looks identical either way. That is the actual risk: **the tool cannot show you what it is costing you.** If a tool like that is already running in your organization, the fix is not a better consent form. It is deciding, out loud and in advance, that nothing from the record ever gets quoted back at someone in a performance conversation, and telling your team that is the rule before they have to wonder about it themselves. ## On Monday, Look For This Pick the 1-on-1 this week where the conversation actually matters most, the one where you need the real version of what is going on. Turn off any recording or notetaking tool for that single meeting, and tell the person why you turned it off. Then pay attention to whether their answers get longer. <hr /> If a notetaker sat in on your last 1-on-1, would you have said everything the same way without it? <hr /> You're great at the work. Let's make you impossible to ignore. If you are working out how much of your team's honesty a well-meaning tool might be quietly costing you, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/happens-work-after-delegate-rarely-findhttps://jessestaffordcoaching.com/blog/happens-work-after-delegate-rarely-findThe work didn't disappear when you handed it off. It just moved somewhere you stopped watching.Sun, 18 Oct 2026 00:00:00 GMT*The work didn't disappear when you handed it off.* *It just moved somewhere you stopped watching.* Something always falls out the bottom of a delegation chain. It is not a skills problem. It is not a planning problem. It is the basic physics of how capacity works inside an organization. When you hand work to someone who is already busy, they drop something lower-priority or pass it further down. That chain continues until it hits someone with no one to pass to. At that point, the work gets absorbed or something else gives way. Not many leaders stop to check. They feel the relief of the handoff and move on. The cost surfaces weeks later as a missed deadline, a gap in documentation, or an answer in a skip-level conversation that makes you stop and think. That cost is whatever fell out at the end of the chain. Here is what makes this worth naming: there is no shortage of advice on delegation. There are guides on how to delegate clearly, how to delegate without micromanaging, how to build autonomy through delegation. According to the DDI Global Leadership Forecast 2025, only 19% of rising leaders demonstrate strong delegation skills. That library is genuinely needed. The leaders who already delegate well are the ones most likely to miss this. They are not watching for it. Because when you do the handoff right, the cascade still happens. ### Why Technical Work Becomes Invisible After You Delegate It Technical work is already hard to see from above. Migrations, documentation backlogs, testing cycles, API cleanup: none of it is obvious to someone not in the weeds. When you delegate a technical task and move on, you are not just handing off a to-do item. You are disconnecting from a thread. The person you delegated to is managing their own thread. They may pass the task to someone on their team. That person is managing their own thread. At each step, the original task gets further from your view and closer to someone who has no clear channel for saying "I do not have capacity for this." The gap this creates is not about hiding information. It is not about anyone choosing to be opaque. It is about the absence of a natural feedback mechanism. The work moves down. The signal about what happened to it does not automatically move back up. In most engineering organizations, that signal only surfaces in three situations: when something misses a deadline, when someone raises a concern in a 1-on-1, or when a leader specifically asks. The first two are reactive. The third is the one worth building into how you manage. ### The Technical Visibility Gap That Delegation Creates The scale of this problem is not small. A 2025 analysis from Runn.io found that over half of organizations identify capacity planning as a pressing need. Only 6% feel they are doing it effectively. ([Source: Runn.io Capacity Planning Statistics](https://www.runn.io/blog/capacity-planning-statistics)) That means most organizations are operating without a clear picture of what their teams can actually absorb. When a leader delegates into that environment, they are not just handing off a task. They are dropping a stone into water and never watching for ripples. The Gallup State of the Global Workplace 2025 adds another dimension: manager engagement has dropped from 31% in 2022 to 22% in 2025. Leaders and managers are reporting higher stress and lower capacity. ([Source: Gallup, via mo.work](https://mo.work/insights/gallups-state-of-the-global-workplace-2025-our-key-insights/)) The teams these leaders are delegating to are not carrying slack capacity. They are already full. When you delegate into a full team without a capacity conversation, you are not adding work to an empty bucket. You are adding it to one that is already at the rim. This does not mean stop delegating. It means change the assumption. The assumption that "they will say something if it is too much" is not reliable. The skip-level conversation is one of the few tools that creates an environment where they actually do. ### Technology Leader Communication: Skip-Level One-on-Ones as Your Delegation Visibility Tool The skip-level 1-on-1 is designed to give you access to what your managers' teams are actually experiencing. Not just what your managers report. It is also one of the best tools for tracking where delegated work eventually landed. If you have not run skip-level conversations before, the setup is simple. Here is a full guide: \[A Guide for Skip Level One-On-Ones\]. The short version: you schedule one-on-ones with the direct reports of your direct reports. Not to go around your managers, but to understand what the organization looks like two levels down. In the context of delegation, the questions that matter most are: "What has landed on your plate this month that was not planned?" "What did you have to set aside to make room for it?" "Is there anything that has quietly fallen behind that I might not know about?" "If your manager asked you today what was at risk, what would you say?" People at this level rarely volunteer capacity problems to their own manager. Saying "I am overloaded" can feel like saying the manager made a bad call when they delegated something. The skip-level conversation removes that barrier. There is more distance, and with more distance comes more honesty. What you hear will not always trace back to something you delegated. But when it does, you have a choice: redirect the work, adjust expectations, or make a deliberate decision that the cascade was acceptable. **The point is not to prevent the cascade. The point is to see it and decide consciously, rather than discover it by accident.** ### Three Delegation Patterns That Create Engineering Burnout Downstream Not every cascade happens because a leader delegated carelessly. Some of the most common delegation problems look like good practice on the surface. **Delegating without a capacity question first.** Handing off a task without asking "what would have to give to make room for this?" assumes the person has slack. They usually do not. That three-minute conversation prevents a three-month gap in visibility. **Following up only with the person you delegated to.** "Handled" may mean the work was passed down and accepted. It does not mean it was absorbed without cost. Ask two levels down: "Has anything from last month's handoff touched your team?" That question surfaces what you would otherwise miss. **Closing the loop at completion instead of at absorption.** Delegation often gets treated as complete the moment the task is done. The more useful close is: "What did you or your team end up setting aside to get this done?" That question tells you the real cost of the delegation, not just whether the output arrived. None of these require a new system or additional meetings. They require a slightly different question at an existing touchpoint. ### Monday Action This week, pick one thing you delegated in the last month. Before you do anything else, find out what the person at the end of the chain set aside to make room for it. One question, one conversation. You will know more about how your organization is actually carrying your decisions than you did before. If you want to understand how to run effective skip-level conversations, start here: [A Guide for Skip Level One-On-Ones](/blog/guide-skip-level-one-on-ones). <hr /> What is the furthest down your organization you have ever traced a piece of work you originally delegated? <hr /> You're great at the work. Let's make you impossible to ignore. If you are looking for help understanding how your decisions land across your team and building visibility into what your organization is actually carrying, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/pushing-harder-sometimes-problem-engineering-managershttps://jessestaffordcoaching.com/blog/pushing-harder-sometimes-problem-engineering-managersThere is a move that looks exactly like leadership from the outside. You see a gap, you respond.Sun, 18 Oct 2026 00:00:00 GMTThere is a move that looks exactly like leadership from the outside. You see a gap, you respond. You see slowness, you apply pressure. You fill dead air with new asks. You follow up before anyone falls behind. And it is exhausting everyone, including you. The managers I work with who burn their teams out the fastest are not the ones who are disengaged. They are the most driven people in the room. They believe that constant forward motion is what the role requires. Nobody ever told them there is a question they should be asking before they add any urgency at all. ### The Engineering Burnout Pattern Leaders Create Without Knowing It There is a named leadership style for this behavior. Goleman identified it in his foundational research on leadership effectiveness and called it pacesetting. Constant urgency. High standards. Always-push. It looks like excellence. His research found it consistently produced the worst long-term team performance of any leadership style he studied. Not because the work was hard. Because the relentless pressure produced burnout, resentment, and disengagement without evaluation. The pattern is easy to fall into because it gets short-term results. You push, the team moves. You add urgency, something happens. The problem surfaces later, when the team is too depleted to sustain the pace you need. Teams operating beyond their capacity see quality and productivity drop, not rise. The agile community has a phrase for this: [sustainable pace](https://www.mountaingoatsoftware.com/blog/why-a-sustainable-pace-is-so-important-to-agile-teams). Teams that preserve energy accelerate cumulatively. Teams that run at full sprint repeatedly do not. According to data from [high5test.com's leadership burnout research](https://high5test.com/leadership-burnout-statistics/), managers are 36% more likely to report burnout than individual contributors. The leaders applying the most pressure are often the first ones to break. ### The One Question That Changes How You Lead When a manager I was mentoring told me his team wasn't moving fast enough, I asked him one question before offering any advice: what is the actual business need if things stay at the current pace? He could not answer it. He had been adding pressure for weeks without asking whether more speed was actually required. That question is the reset point. Before you add anything to your team's plate, before you schedule another check-in, before you send the follow-up message about why the deadline matters: **What is the actual business need right now?** If there is a real need, something specific is at risk. A deadline matters, a gap needs to close, or the business cannot deliver something it has committed to. The next question is: what would we say to the team, or change about their work, to actually address that? Not more urgency for its own sake. A specific conversation about a specific need. If there is no urgent need, the right move is to verify direction and let it run. Make sure the team is pointed where it needs to go. Then stop rowing. This is not the same as coasting. You are making a deliberate evaluation. The momentum is real, the direction is right, and adding pressure right now creates noise rather than speed. ### The Sourced Fact According to [Gallup's 2026 State of the Global Workplace report](https://www.gallup.com/workplace/349484/state-of-the-global-workplace.aspx), manager engagement dropped from 27% to 22% in a single year. That is the largest year-over-year manager decline Gallup has ever recorded. Managers account for 70% of variance in team engagement. Disengaged managers produce disengaged teams. And one of the fastest paths to manager disengagement is years of self-imposed constant pressure that never evaluated whether it was needed. ### How to Read Your Team's Signals Before Adding Pressure Stepping back requires knowing what to look for. These are the signals I check before I decide whether to push or let it run: - Signals that the team does NOT need more from you: - People are finishing what they started before picking up new work - 1-on-1 conversations are about the actual work, not about managing your expectations - The team is asking questions about direction and priority, not asking you to slow down the volume of asks - People are energized after team syncs, not visibly relieved when they end - Signals that something is actually wrong: - Work is cycling without finishing - Your best people are quiet in ways they weren't before - The team stops raising problems, because they expect you to add a new task in response - You are getting more status reports and fewer conversations about the work itself Pace is a symptom. These are the causes. A team moving slowly but finishing things and talking openly about the work does not need more pressure from you. A team that has gone quiet and is cycling through half-done tasks needs something different. More urgency will not fix what is actually broken. ### When the Answer IS Yes: How to Push Effectively When You Really Need To This framework is not about never applying pressure. There are real moments when the business needs the team to move faster and the leader's job is to communicate that clearly and create the conditions for it. Here is what effective urgency looks like when the business need question has a real answer. **Name the consequence specifically.** Not "we need to move faster." Instead: "If we do not close this gap by \[specific date\], \[specific business consequence\] happens." The team needs to understand what is actually at stake, not just that you are unhappy with the pace. **Have a conversation about the work, not the urgency.** Ask the team directly: "What would need to be different for us to move this faster?" You often discover that one or two things are creating the friction. Naming the obstacle is more useful than adding pressure to the outcome. **Remove something to create capacity.** If the business need is real and the team is genuinely at capacity, adding a new priority without removing an old one is just adding noise. Explicitly retire or defer something. Say it out loud. The team needs to know what they are allowed to stop doing. **Set an end point.** "We need to accelerate through \[milestone or date\], then we re-evaluate." Sustained urgency with no end point is exhausting. Defined urgency with a clear horizon is manageable. Teams can run hard when they know how long the sprint is. The goal is not to never ask for more. The goal is to ask for more only when the business actually needs it, and to make that ask specific, scoped, and clear. ### Monday Action Before your next team meeting, write down three specific business commitments your team is currently working against. Not general goals. Specific commitments with dates or consequences attached. If you cannot name three, that is the work to do before you add any urgency to anyone's plate. You cannot effectively push toward something you cannot describe. <hr /> What business need is your team actually working against right now, and could you describe it in one sentence? <hr /> You're great at the work. Let's make you impossible to ignore. If you are looking for help building a team that runs at a sustainable pace without losing momentum, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/agentic-workflow-fatigue-team-ships-morehttps://jessestaffordcoaching.com/blog/agentic-workflow-fatigue-team-ships-moreOne of my strongest engineers asked if she could go back to writing a chunk of our test coverage by hand. Not all of it.Sun, 20 Sep 2026 00:00:00 GMTOne of my strongest engineers asked if she could go back to writing a chunk of our test coverage by hand. Not all of it. Just the part she used to like. She had been running three or four AI agents at once for a couple of months, shipping more than she ever had, and she told me the days felt like air traffic control. It was all watching and deciding, with nothing at the end she could hold up and say she made. I did not have a good answer for her in the moment. The velocity chart said she was having her best quarter. She was asking to be slower on purpose. ## Why Agentic Work Feels Like a New Kind of Engineering Burnout Making something gives you a finish line you can see. A test that was red goes green. A design problem you have been circling for an hour finally gives way. You point at the thing and know you built it. Before the tools arrived, the day was paced by a steady supply of those, one every hour or two, and they added up to more than they looked like. Steering a set of agents removes most of them. What is left is a mode the brain is not built to run for long. You hold three or four tasks in your head at once. You judge whether output you did not write is good enough. You trace which inputs produced it. You keep track of what is actually done against what only looks done. Then you assemble a shippable whole out of the parts. None of that produces the small hit of completion that building does. It produces vigilance, which is tiring in a specific way. Watching a stream of mostly-fine output for the one costly error is one of the hardest things to keep doing well, and attention slides off it fast. Your engineer is not imagining the drain. **The work changed shape, and the part that used to pay her back is mostly gone.** ## The Cause Is Not AI Output Quality. It Is the Operating Model. The common explanation is that the model is not good enough yet, and people just need to prompt better or wait for the next version. Set that aside. Even when the output is solid, two things wear people down. The first is the switching. Running several agent sessions at once means starting one, tabbing away while it works, picking up the next, and coming back to the first one half finished. Every switch leaves part of your attention stuck on the thing you just left, and it is worst when that thing was unfinished. With parallel agent tasks, all of them are. The second is the management work nobody named. Running a set of agent tasks is a project-management job in everything but title. You break the work down, hand each piece to the right tool, decide whether what comes back clears the bar, trace what produced it, and track real progress against the look of progress. Then you pull it together into something you can ship. That used to belong to managers and project managers. Now it sits on every engineer, and nobody scheduled the training for it or the recovery time around it. Underneath both is the same catch. You are handing work to something you do not fully trust, so you follow up on everything it returns. That is the load of running a team without the earned trust that lets a manager stop checking every line. **You get the oversight cost and none of the relief.** I felt it myself recently. I spent an afternoon steering an AI through an analysis of employee survey data. It locked onto my first reaction to one bad number and kept circling how to avoid that outcome, and I had to keep redirecting it with sharper questions until it was useful. That loop, prompt and watch it drift and pull it back, took more out of me than doing the analysis by hand would have. ## The Research: Progress, Not Hours, Is What Protects People There is research under this, and it matches what I notice in myself. Teresa Amabile and Steven Kramer ran a multi-year study of daily work diaries, published in the Harvard Business Review article "The Power of Small Wins" (2011). They collected roughly 12,000 daily entries from 238 professionals across 26 project teams and seven companies. Their central finding: of everything that shapes how people feel and perform at work, the single most important factor is making progress in meaningful work. Small wins counted for far more than their size. The part that matters for a leader is what came next. In a survey they ran alongside the study, 669 managers asked to rank what motivates employees put "support for making progress" last. **The thing that most protects a team from burning out is the thing managers most reliably overlook.** Agentic work runs almost entirely on half-finished parallel threads with very few clean completions, which is exactly the condition that drains people. Sources and further reading: Teresa Amabile and Steven Kramer, ["The Power of Small Wins," Harvard Business Review, May 2011](https://hbr.org/2011/05/the-power-of-small-wins). Annie Vella's longitudinal study, ["The Productivity-Experience Paradox"](https://annievella.com/posts/the-productivity-experience-paradox/), which found productivity perception steady at 84% while the share of engineers reporting worse developer experience nearly doubled, and the correlation between flow-state change and productivity change fell to 0.02. Harvard Business Review, ["When Using AI Leads to 'Brain Fry'"](https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry), a survey of 1,488 workers in which supervising multiple AI outputs was associated with about 33% more decision fatigue and hit high performers hardest. ## What Technology Leaders Can Do About Agentic Workflow Fatigue This is individual work, not a structural program. The workday redesign is a separate piece. Here the job is helping each person carry the new mode, and it looks different for different people. **Give the recovery gap back, and say so out loud.** The time while an agent runs, or the ten minutes after a hard call, is recovery doing real work. People will not take it if they expect to be asked why they were away from the keyboard. That question is most of what people are actually resisting about return-to-office. Tell your team plainly that time between tasks is expected and does not need to be accounted for. **Protect one piece of owned work per person.** When the coordinating work drains me, I go build something end to end and it resets me. Make sure everyone on your team still has a piece of work that is recognizably theirs, start to finish, even a small one. If someone steers all day and finishes nothing with their name on it, that is the thing to fix first. **Coach the recovery skill instead of mandating it.** Left alone, people fill the gap between tasks with another agent run or a scroll, and neither one restores anything. The skill worth coaching is noticing what you actually need in the moment, whether that is a walk, a hard problem worked by hand, or ten quiet minutes. You cannot require it. You can model it and talk about it in one-on-ones. **Try single-threading as an experiment.** The switching is the core of the drain, so fewer live agent tasks at once is the change that most directly addresses it. Offer it as something to try for a week, not a rule. People land at different numbers. ## The Fixes That Make Agentic Workflow Fatigue Worse Some responses feel like action and quietly make it worse. **Declaring a company-wide no-AI day.** It reads as taking away the tool people are measured on, and it does nothing about the switching or the missing sense of ownership on the other four days. **Standing up a wellness channel and calling it support.** The drain lives in the shape of the work. A new Slack channel is motion, not a change to the work. **Telling people to prompt better.** That turns a work-design problem into a personal skill gap. It adds a little shame and no relief, and the vigilance cost does not move. **Turning the ownership question into a metric.** The minute "do you still feel like the work is yours" has a number attached and a target next to it, the honest answer goes away. **Cutting headcount because the tools made everyone faster.** The oversight and integration work is real work. Removing the people who do it concentrates it on whoever is left, which is how the fatigue spreads. ## On Monday, Start Here In your next one-on-one, ask each person what they built this week that felt like theirs. Push past the list of what shipped to the thing they made and can point at. Treat a blank answer as a load signal, not a performance problem, and spend the rest of the hour working out where the building went. Then look at your two fastest people. Count how many agent tasks each is running at once, and check whether either has finished and owned something in the last two weeks. If the answer is a lot and nothing, you have found the work worth doing this month. **If your team got faster with AI and flatter at the same time, what has each person actually finished and owned in the last two weeks?** You're great at the work. Let's make you impossible to ignore. If you are working out how to keep your best people attached to work that feels like theirs while the tools do more of the building, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/build-promotion-case-decision-already-madehttps://jessestaffordcoaching.com/blog/build-promotion-case-decision-already-madeMost promotion conversations go like this. The employee walks in prepared.Wed, 16 Sep 2026 00:00:00 GMTMost promotion conversations go like this. The employee walks in prepared. They have gathered their wins. They know what they want and why they deserve it. They make their case clearly. Then they hear "not yet." What they almost never know is that the real decision about their promotion happened weeks or months earlier. In a calibration meeting. With managers comparing peers against each other and against limited budget. Among people who may not know their name. This is the part nobody tells you about. ## Why Promotion Decisions Don't Happen in Promotion Conversations Most people assume the promotion conversation is when the decision happens. It is not. Calibration meetings happen before annual reviews are finalized. In those sessions, managers argue for their reports against other managers arguing for theirs. Budget constraints mean the discussion is comparative, not absolute. By the time any manager sits down with an employee to deliver news, the outcome is typically already set. Here is what I know to be true: if you think your performance review is when your promotion gets decided, you are already too late. By the time your manager writes your review, the real decision has already been made. Technical leaders are especially exposed to this dynamic. Their best work lives in systems, codebases, and architecture decisions that are invisible to non-technical stakeholders. If the people in the calibration room cannot independently describe what you built and why it mattered, your manager is asking them to trust an unverifiable claim. That is a harder position to advocate from. ## The Technical Visibility Gap That's Stalling Promotions Research from Russell Reynolds Associates confirms what most senior technical leaders eventually learn the hard way: cross-functional visibility, strong working relationships with peer teams, and endorsements from leaders outside your direct chain all directly influence promotion outcomes. Technical excellence alone does not get you promoted. Not at the senior level. Most technical leaders are known to a narrow group of people. Their direct manager knows what they do. Their immediate team knows. But the skip-level executives, the peers of their manager, and the leaders in adjacent functions who will be in that calibration room may have no idea who they are or what they have delivered. This gap has real consequences. When only one person can speak to your work and your goals, the case depends entirely on that person's motivation and positioning. If that manager advocates well, it works. If they cannot or do not, the case does not get made. See: [Rethinking Visibility: The Common Misconceptions Emerging Leaders Have About Being Seen, Russell Reynolds Associates](https://www.russellreynolds.com/en/insights/your-leadership-journey/leadership-progression-by-design/rethinking-visibility-the-common-misconceptions-emerging-leaders-have-about-being-seen) ## The Sponsorship Gap Nobody Admits To Research by the Center for Talent Innovation found that of employees who believe they have sponsors, only 27 percent actually have someone who advocates for their promotion within the organization. Most so-called sponsors are actually mentors: they give advice and guidance, but they do not use their influence on someone's behalf in decision-making rooms. This is the sponsorship gap. A mentor gives you a feedback loop. A sponsor changes what gets said about you in the calibration room. Most people building promotion cases are relying on the former while needing the latter. Getting a real sponsor means doing different work than just finding a mentor. It means working on things that matter to senior leaders across the organization. It means giving those leaders enough visibility into your work to form a genuine opinion. It means being known to people with influence, not just liked by people who do not. Source: [Center for Talent Innovation, Senior Leaders are Misunderstanding the Role of Sponsorship](https://www.prnewswire.com/news-releases/senior-leaders-are-misunderstanding-the-role-of-sponsorshipand-missing-out-on-its-rewards-according-to-new-research-by-the-center-for-talent-innovation-300774196.html) ## What Technical Leaders Actually Do to Build the Promotion Case The leaders who consistently advance in technical organizations are not always the most technically excellent people in the room. They are the ones who are known to the right people, have a track record the decision-makers have actually seen, and have someone in the calibration room genuinely willing to advocate. Building toward that starts well before any formal ask. **Map the real decision-makers.** Your manager is only one of them. Write down the five to seven people who will have a voice, then ask how well each of them could describe what you do and what you want next in your career. **Share your goals with more people.** Your manager knowing is not sufficient. Their peers, their boss, and other senior leaders you have real relationships with should know too. If the only person who knows you want a promotion is the person with a reason to keep you where you are, you have left your career in exactly one person's hands. **Build the evidence trail before review season.** When something significant ships, make sure the right people know. Not as self-promotion, but as the evidence the calibration room runs on. The form this takes matters less than the consistency: a project post-mortem shared upward, a brief note to a skip-level when a major deliverable lands. **Develop sponsors, not just mentors.** Look for senior leaders whose priorities your work has genuinely served. Build working relationships through shared projects and business problems. Make it easy for them to tell a story about you when your name comes up, because they already have one. See also: [The Engineer's Guide to Getting Promoted (2026 Edition), developereq.com](https://developereq.com/blog/engineers-guide-to-getting-promoted-2026) ## Three Mistakes Technical Leaders Make Before Promotion Conversations **Mistake 1: Starting too late.** Most technical leaders begin making their promotion case in the weeks before a review. But calibration meetings may already be scheduled or completed by then. The twelve months before a promotion ask matter far more than the two weeks before it. Relying on a single advocate is the second mistake. If your direct manager is the only person who knows your goals and your record, you have left your career in one person's hands. Managers have their own incentives, and they are not always aligned with yours. A single point of advocacy is a fragile position. **Mistake 3: Keeping wins private.** Technical leaders often believe excellent work speaks for itself. In a calibration room with limited budget and competing claims, it does not. Work that the decision-makers cannot speak to does not exist in that conversation. ## Before Your Next Review This week, pick one senior leader outside your direct manager who will likely have a voice in your next promotion conversation. Send them a brief update on something significant you delivered recently. Not a pitch. Just a direct update on what it was and why it mattered to the business. One relationship. One genuine touchpoint. That is the work. <hr /> Have you ever figured out, after the fact, that your promotion decision had already been made before you walked into the conversation? What changed your approach? <hr /> You're great at the work. Let's make you impossible to ignore. If you are looking for help building the visibility that gets you considered before you ever have to ask, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/engineering-team-feels-more-burned-afterhttps://jessestaffordcoaching.com/blog/engineering-team-feels-more-burned-afterOne of my teams finished its sprint work by Wednesday. That had not happened before.Thu, 03 Sep 2026 00:00:00 GMTOne of my teams finished its sprint work by Wednesday. That had not happened before. The team had been using AI coding tools for about two months. Features that used to fill the full two weeks were landing in a few days. And then the team sat. Not because anyone was slacking. The spec for the next big piece was still in review, the security sign-off had not come back, and the group that approves architecture changes meets once a week. **The building had gotten faster. Nothing around the building had.** By Friday, two of the strongest engineers on that team looked worn down. Not from long hours in the usual sense. From a week of hard calls with nothing easy in between, and then a wall of waiting they could not do anything about. That is the pattern worth naming. **AI did not make the week lighter. It changed the shape of it.** ### Why Your Team Feels Busier After Adopting AI Tools Think about what the routine work actually was before the tools arrived. Clearing small tickets. Wiring up a basic test. Formatting a document. Writing the same boilerplate for the hundredth time. None of it was satisfying and none of it was hard. Those stretches were where a brain got to run at low power for a while between the decisions that actually took something out of you. AI is very good at exactly that work. It clears it out fast. What it leaves behind is the part nobody could hand off: deciding what to build, judging whether the output is right, and holding the whole system in your head because you own the result even though you did not type it. Take that away and the day does not get shorter, it gets denser. You are making more decisions per hour, hitting more new problems back to back, and carrying a job that did not exist in the same form before: checking work you did not write and only half trust. Engineers have a phrase for AI code, "almost right, but not quite." Almost-right is the most expensive kind to catch, because it passes a quick read and then fails in production. This is also why the split inside a team can be so wide. Experienced engineers often feel energized, because the part of the job they already liked, making the call, now turns into working software faster. Newer engineers often feel heavier, because they are being asked to judge and steer output before they have built the mental models for what good software looks like. The same rollout reads as a win in one conversation and a strain in the next. ### AI Removes the Low-Stakes Work That Used to Be Recovery Time There is a name for this, and it is more than forty years old. In 1983, the researcher Lisanne Bainbridge published a paper called "Ironies of Automation." Her argument was straightforward. When you automate a process, you automate the parts you understand well enough to automate. What is left for the human is everything that was too hard or too unpredictable to hand off, plus a new job: watching the automation and being ready to take over when it slips. People are poor at that kind of passive monitoring. And the moment they are asked to step in is, by definition, the moment something has already gone wrong. Skills that go unused also fade, so the person expected to catch the hard case is often less sharp on it than they used to be. Swap "automation" for "AI coding assistant" and the paper reads like it was written last year. There is a second effect that shows up at the team level, and it is the one leaders feel personally. When execution speeds up, the team reaches its decision points and its approval gates faster than the organization can clear them. Questions that used to come up once a month come up once a week: approvals, cross-team alignment, whether the team is even allowed to build it the way it wants to. The leader becomes the person spending their days getting projects unstuck, because the pace of building moved and the pace of deciding did not. It is an old idea from operations: speed up a step that was never the bottleneck, and the work just stacks up in front of the step that is. ### The Data: AI Speeds Up Individuals and Slows Down Delivery Google's DORA research team studied this directly in its 2024 Accelerate State of DevOps Report, drawn from more than 39,000 professionals. They found that a 25% increase in AI adoption on a team was associated with an estimated 1.5% decrease in delivery throughput and an estimated 7.2% decrease in delivery stability, even as roughly three out of four individuals reported personal productivity gains. The stated mechanism: AI makes it easy to write more code, change sets get bigger, and larger changes carry more risk. That is the paradox in one dataset. **The people feel faster. The system delivers a little less and breaks a little more.** If you only listen to how individuals describe the rollout, you will miss it. Sources and further reading: Google Cloud / DORA, [2024 Accelerate State of DevOps Report](https://dora.dev/research/2024/dora-report/). The [2025 Stack Overflow Developer Survey](https://stackoverflow.blog/2025/10/23/what-leaders-need-to-know-from-the-2025-stack-overflow-developer-survey/) of about 49,000 developers, in which 66% named "AI solutions that are almost right, but not quite" as their single biggest frustration. Background on the Bainbridge paper: ["Ironies of Automation" overview](https://en.wikipedia.org/wiki/Ironies_of_Automation). ### How Technology Leaders Can Redesign the Workday Around AI The fixes are structural, and they are the leader's to make. None of them are "tell people to push through." **Budget the deep-thinking hours, not the clock hours.** The high-judgment part of the day was always a smaller number than eight. A focused-work study I ran with a team years ago, well before we used AI widely, put the ceiling around four and a half hours a day before burnout signs showed up, and the team was happiest closer to three and a half. The rest of the day went to helping each other, learning, and meetings. Plan around that number now, and fill the rest of the day with the review, pairing, and lighter work that used to happen on its own. **Shorten the wait on decisions.** If the team can build faster than the organization can decide, closing that distance is the job. Look at the sprint ahead, find the decisions and approvals the team is going to hit, and get them lined up before the code is ready instead of after it is blocked. Track how many open decisions sit on any one person, and bring that number down the way you would bring down an overloaded ticket count. **Make "good" explicit and teach it.** The review load is really a standards problem underneath. When people who are still learning to drive AI to a quality result are shipping work, "I will check it myself" stops scaling quickly. Put the definition of done in writing. Put the bar for good in writing. Coach to it in code review and in one-on-ones instead of catching the same miss ten times. **Watch the team-level signals, not the individual mood.** After a rollout, almost every individual signal points the same way. People say they are faster, and they mean it. Watch rework rate, churn, review-time trend, and whether people are quieter going into the week. **Put recovery back on the calendar.** The small breaks between hard problems are gone. No-meeting blocks, and lighter loading during heavy decision stretches, are not perks now. They are what keeps the focused hours usable. ### Four Moves That Backfire After an AI Rollout This part is the one worth reading twice. **Reading the rollout as a clean win because the demo was fast.** A pull request drafted in fifteen minutes is not a finished feature. The testing, hardening, and review are hours of real work that do not show up in the demo. A leader who sets expectations off the demo speed creates a deadline nobody can actually hit, and then wonders why the team is stressed. **Treating "fewer focused hours" as lower output.** It is capacity planning, not slacking. The deep-work budget was always smaller than the workday. AI just spends it faster, so the budget has to be named and protected instead of assumed. **Keeping busywork around on purpose so people have something easy to do.** This is nostalgia. The routine work is not coming back, and you would not want it back. The job is to design the day around its absence, not to fake the old rhythm. **Bolting on an AI-output review step and calling it a process.** Review is not a stage you add at the end. If the people generating the work cannot yet drive it to quality, the fix is teaching the standard, not stacking another checkpoint onto the senior engineer who is already the bottleneck. ### Monday Try This At your next planning session, count the decisions and judgment calls each person is carrying into the week, not just the tickets. Then bring that number down the way you would bring down an overloaded backlog. If one person is holding six calls only they can make, that is the overload, even if their task list looks ordinary. Move two of those calls earlier in the week, hand two to someone who is ready for them, and see what the week feels like by Friday. <hr /> If your team got faster with AI and more tired at the same time, which of the three is doing it: the number of decisions, the review load, or the wait on approvals? <hr /> You're great at the work. Let's make you impossible to ignore. If you are working out how to rebuild your team's week after an AI rollout that left everyone faster and more tired, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/technical-visibility-gap-between-multiplier-workhttps://jessestaffordcoaching.com/blog/technical-visibility-gap-between-multiplier-workI once spent the better part of a year in meetings that had nothing to do with my own team's roadmap. My job that stretch was to learn how localization...Thu, 03 Sep 2026 00:00:00 GMTI once spent the better part of a year in meetings that had nothing to do with my own team's roadmap. My job that stretch was to learn how localization worked at my company from beginning to end, then negotiate a completely different process with every internal team and outside vendor that touched it. I did not write the software that ultimately automated most of the steps. My own team did that part. My job was defining the new process, negotiating it across departments that had never had to agree on anything before, and evaluating what the savings would actually be once it worked. We reduced localization costs by 90 percent, company-wide. And if you had looked at my calendar that year, you would have seen almost nothing that looked like output. Meetings. Negotiations. A lot of listening. ## What "Technical Leader Promotion" Rubrics Actually Ask For Now That kind of work has a name in 2026 leveling frameworks, and it is not a soft one anymore. Engineering ladders at Google, Meta, Amazon, and Intuit all name some version of "multiplier" as an explicit, scored criterion, separate from individual execution. Staff and above, the expectation flips from doing the work yourself to increasing what everyone around you can do. That should have made my localization year easier to defend at review time. It also would have, if I had ever narrated it as it happened instead of letting the 90 percent number speak for itself two years later. Here is the trap in the new rubric language. Naming "multiplier" as a criterion does not change how the work looks day to day. It still produces no pull request, no launch, no line in a sprint report. The industry gave the invisible work a name before it gave anyone a way to make it visible. ## Why Calibration Committees Can't See Multiplier Work Multiplier work leaves no pull request, no launch, no line in a sprint report. It shows up in someone else's output. When calibration time comes, the reviewer sees the launch and the person who shipped it. The person who cleared the path three weeks earlier has no artifact to point to. This is not a fairness problem. It is what happens when a rubric names an outcome but never names how to make it visible. The rubric changed. The habit of narrating the work did not catch up. ## The Sourced Fact The research backs up why individual output metrics were always the wrong lens for this kind of contribution. The SPACE framework, published in ACM Queue by Nicole Forsgren and colleagues, explicitly warns that activity metrics like commit counts or ticket closures are a poor standalone proxy for productivity. Activity shows that work happened. It does not show whether the work mattered, and it says nothing about work that shows up in someone else's output instead of your own. [Source: Forsgren, Storey, et al., "The SPACE of Developer Productivity," ACM Queue, 2021.](https://queue.acm.org/detail.cfm?id=3454124) That finding matters here because most calibration conversations still default to individual output as the easiest thing to measure, even when the criterion on the page says "multiplier." If the metric people reach for by habit cannot capture multiplier work, the only fix is narrating it directly, in language a calibration committee can repeat without you in the room. [Levels.fyi's standard engineering ladder framework](https://www.levels.fyi/blog/swe-level-framework.html) shows this pattern across companies: the further up the ladder, the more the scoring shifts toward influence you cannot point to with a single deliverable. ## How to Show Your Work When the Work Isn't Yours to Point At This is where the Show Your Work method earns its keep, applied to a problem it was not originally built for. The framework has always been about proactive communication before someone has to ask "what are you working on?" Multiplier work needs the same proactive habit, aimed one level further out, because there is no artifact to point a manager toward later. **Say what you removed, not what you did.** "I helped the payments team" is not a sentence a manager can repeat in a room. "I removed the schema dependency that was costing the payments team two days a sprint" is. Name the specific obstacle and the specific thing its removal made possible. **Narrate before the credit gets assigned.** If you know a launch is coming that your earlier work enabled, say so before the launch happens, not after someone else's announcement has already claimed the moment. "I intend to spend this sprint on the deploy pipeline that has been slowing the mobile team down" puts your name on the record while it is still true. **Log it weekly, not from memory.** A one-line note, once a week, of who you helped and what changed for them turns into an entire calibration case by review season. I cannot reconstruct a quarter of unblocking work from memory. Almost nobody can. **Translate the mechanism into what the business sees.** My localization project only became a story people remembered once it had a dollar figure attached to it. If your multiplier work has a number behind it, whether that is hours saved, cycle time reduced, or people who no longer need you, say the number early and often, not only when someone finally asks. ## Why "Avoid Glue Work" Advice Doesn't Work Anymore The most cited advice on this exact topic goes the opposite direction. Tanya Reilly's essay ["Being Glue"](https://www.noidea.dog/glue) argues that coordination and mentorship work, what she calls glue work, is a trap before you have the title to protect you. Her advice, in short: do less of it until you are senior enough that avoiding it will not tank your career. That advice made complete sense in a world where multiplier contribution was invisible to the scoring system, not just invisible to the naked eye. In 2026, it is not invisible to the scoring system anymore. Multiplier is a named line on the rubric at the companies most likely to employ the readers of this post. Avoiding the work does not avoid the scrutiny. It just means you are being scored against a criterion you deliberately did less of. The real fix was never avoidance. It is narration, done consistently enough that the work stops disappearing the moment someone else ships. [LeadDev's coverage of getting credit for invisible work at the staff-plus level](https://leaddev.com/staffplus/getting-credit-invisible-work-staff-level) makes the same case from a different angle: the engineers who get credit are not doing less of the invisible work, they are the ones who found a way to keep it visible to the people deciding. One caution worth naming directly. Not everyone who talks in every meeting and leaves an opinion everywhere is a multiplier. Real multiplier work leaves something behind: a doc someone still references, a process that does not need you the second time, a person who can now do what only you could do before. If a quarter of "helping" left nothing durable behind, narrating it will not fix that. There was nothing there to narrate. ## Monday Action Open your calendar from the last two weeks. Find one meeting, one code review, one conversation where you removed something blocking someone outside your immediate team. Write two sentences: what you removed, and what it made possible. Send those two sentences to your manager today, before whatever it unblocked gets credited somewhere else. What is the last thing you did that made someone else's work possible, and did anyone besides you know it happened? You're great at the work. Let's make you impossible to ignore. If you are looking for help narrating the work that keeps your team moving but never shows up in your own deliverables, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/didnt-get-considered-management-role-wantedhttps://jessestaffordcoaching.com/blog/didnt-get-considered-management-role-wantedI was a senior individual contributor when I decided I wanted to move into management. Every one-on-one, I told my manager where I wanted to go and...Sat, 29 Aug 2026 00:00:00 GMTI was a senior individual contributor when I decided I wanted to move into management. Every one-on-one, I told my manager where I wanted to go and what I could take on to get there. Eventually I interviewed for two management roles outside the company, at the same time I was quietly building toward one inside it. I was offered both. I wasn't fully sold on either one, so I brought all three options back to my manager. He asked me to talk to his boss, and their boss, before I made a decision. That is when I found out my manager's boss had no idea I wanted to move into leadership at all. That conversation shifted something for me. I had spent a year building visibility with exactly the wrong people. My manager liked having me as an individual contributor and had quietly put me in for a different promotion instead. Nobody above him even knew there was a decision to make. I had done everything the advice columns tell you to do, and it still almost went nowhere, because I was only telling one person. ## The Technical Leader Promotion Decision Happens Before the Posting I watch engineers wait for a management role to show up on the internal careers page, then apply and hope their resume speaks for itself. That approach assumes the posting is the start of the decision. It almost never is. A management seat gets created exactly three ways. The team grows and needs a new layer of leadership. Someone leaves the current seat through promotion, transfer, or exit. Or a reorg draws a new line and a gap opens where a leader has to sit. Nothing else creates the seat. Not a budget review, not a wish, not a resume sitting in a talent pool. By the time a req actually gets posted, one of those three things has usually already happened, weeks or months earlier. The leaders closest to that decision typically already know who they want. The posting is a formality that lets HR run a process. It is not where the real decision gets made. ## The Technology Leader Communication Gap That Actually Blocks You Most advice on this topic tells you to pick a lane. Get better at leading people, or get better at being visible. That framing is wrong, because the two compound instead of competing. Project leadership and people leadership are genuinely different skills. You can be excellent at running a project and never build the second skill at all. Most people who eventually lead teams proved themselves in a project role first, and used the relationships built there to grow the people side once they had a reason to. That is the part most engineers miss. Positioning without a real proof point behind it gets you a friendly conversation and nothing else. People skills without positioning means the team that would eventually trust you with a leadership seat has never heard your name in the first place. You need both, and they have to build on each other, not sit in separate boxes. ## Why Internal Promotions Outperform External Hires Wharton professor Matthew Bidwell tracked seven years of employee data across financial services, investment banking, and publishing. External hires scored significantly lower on performance evaluations for their first two years on the job than employees promoted internally into the same kind of role, and were 61 percent more likely to be fired. External hires were also paid 18 percent more than the internal promotes doing the same work (Knowledge at Wharton, ["Why External Hires Get Paid More, and Perform Worse, than Internal Staff"](https://knowledge.wharton.upenn.edu/article/why-external-hires-get-paid-more-and-perform-worse-than-internal-staff/)). Companies already know this. It is exactly why an internal candidate who is a known quantity has such an advantage over an external one, and exactly why an internal candidate nobody knows is treated like an external hire anyway. You do not get the benefit of being internal just by having a badge. You get it by being known. ## What to Do Before There Is Anything to Apply For Talk to the team before the role exists. If you want to lead a specific team, go learn what they actually do and why it matters to the business, before there is a posting to respond to. Waiting until the role opens means you are starting the relationship at the exact moment you need it to already exist. Share the goal with more than your direct manager. I only found out my manager's boss didn't know about my goals because I happened to get three offers at once and forced the conversation. Do not wait for that kind of pressure. Tell the people above your manager, and your manager's peers, what you are working toward. If your manager is the only one who knows, you are betting your entire case on a single advocate. If you are the only person who can do your current job well, you are not a candidate for the next one. You are a retention risk the organization cannot afford to move. Mentor someone into the parts of your role that matter most, on purpose, well before you need that argument to hold up in a promotion conversation. Name which of the three mechanisms is actually closest. Growth, departure, or reorg. If you can identify which one is nearest on the team you want, **you know exactly where to spend your time and exactly whose radar you need to be on before it happens.** ## The Org Chart Math Is Working Against Anyone Who Waits This isn't just advice, it's math. Companies like Bayer, Amazon, and Meta have all made public commitments to flattening their management layers, and the data reflects it: the average manager's span of control climbed from 8.2 direct reports in 2013 to 12.1 in 2025 ([Forbes, "Management Cuts Today Are Shaping A Leadership Shortage"](https://www.forbes.com/sites/cindyrodriguezconstable/2026/06/30/management-cuts-today-are-shaping-a-leadership-shortage/)). Fewer seats are opening every year, and the ones that do open get filled faster, by whoever the team already trusts. Waiting for a posting used to be a slow strategy. Now it is closer to no strategy at all. The math means the identification window before a role posts is shrinking, not growing, which makes being the known quantity more valuable every year this trend continues. None of this guarantees the seat opens when and how you want it to. But it changes what the decision looks like when it does. ## On Monday, Look For This Pick one team you would want to lead someday. Find one person on it you don't currently talk to. Set up fifteen minutes this week, not to ask for anything, just to understand what they actually do and why it matters. That conversation will do more for your case than any application you submit later. What would you find out if you asked your manager's boss what they know about your goals right now? Related reading: [Talking to Your Manager About Your Goals Is Not Enough](/blog/talking-manager-goals-enough-else-need) and [Why Being Too Good at Your Job Blocks Your Promotion](/blog/being-too-good-job-blocks-promotion) cover two pieces of this same problem in more depth. You're great at the work. Let's make you impossible to ignore. If you are looking for help positioning yourself for the leadership role you actually want, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/qa-engineers-arent-slowing-downhttps://jessestaffordcoaching.com/blog/qa-engineers-arent-slowing-downThe complaint I hear about QA is never that the engineers are bad at their jobs. It is that the conversations never get to the right level.Sat, 29 Aug 2026 00:00:00 GMTThe complaint I hear about QA is never that the engineers are bad at their jobs. It is that the conversations never get to the right level. You ask for status. You get counts. You ask what the risk is. Nobody can answer. That gap is not accidental. It is structural. And most of the industry is living inside it. According to the Capgemini/Sogeti World Quality Report 2025-26, only 37% of organizations report strong cross-functional collaboration between QA and engineering teams. That means more than six in ten organizations are running release cycles with a fractured relationship between the people building the product and the people responsible for testing it. The leaders in those organizations are not doing anything uniquely wrong. They are caught inside a systemic problem that nobody built intentionally and almost nobody has named. This post is about naming it. ## Why Managers Find QA Communication So Frustrating The frustration has a recognizable shape. You can find it in three specific behaviors. The first is that QA communicates in test cases, not risk. Status updates arrive as counts: test cases complete, bugs filed, bugs resolved. What never arrives is an answer to the question that actually drives decisions: if we ship tomorrow, what is the customer risk? The second is that QA accepts timeline compression without pushing back on what that compression costs. Development runs long. QA inherits whatever time is left. They work through it and sign off, sprint after sprint, without surfacing what they did not test or what that means. The third is the architecture gap. QA knows the test suite and what failed last time. They do not always know which components are fragile right now, which integrations are new, or which code paths changed in this sprint. Without that context, they test broadly and equally instead of where the actual risk is concentrated. These behaviors frustrate leaders. They are also symptoms, not causes. ## The Technical Visibility Gap Inside Your QA Team QA teams are almost always measured on defect metrics: bugs found, bugs closed, test cycle completed on time. When your measurement is defects, you become very good at finding and documenting what can be tracked and closed. You become less practiced at the harder question: of all the things that could go wrong in this release, which ones actually matter to the customer? That is a risk judgment. It requires knowing the product deeply, understanding the customer's experience, and having enough architectural context to assess where the real exposure is. QA is not measured on risk. It is measured on what can be documented and closed. There is a structural layer underneath this. QA is almost always last in line. Development runs long, scope does not shrink, and QA inherits whatever time is left. Every sprint. Pushing back on a compressed timeline requires explaining what the compression costs in terms the business cares about. Without the risk language to make that case, accepting the squeeze is the only available move. **According to the World Quality Report 2025-26 (Capgemini/Sogeti), 56% of organizations do not view quality engineering as a strategic function, and 53% report misalignment between QE processes and agile delivery methods.** The report's core finding: progress depends less on technology choices and more on how organizations assign ownership, support learning, and integrate QE into delivery models. The problem is leadership and structure, not the people in QA roles. [\[World Quality Report 2025-26, Capgemini/Sogeti\]](https://www.capgemini.com/insights/research-library/world-quality-report-2025-26/) The pattern has a name in the testing community: fear-driven testing. The Ministry of Testing defines it as "an accidental approach to software testing that results from conducting tasks mainly out of fear that defects will escape and reach production." The behaviors it produces are exactly what frustrates engineering leaders: excessive end-to-end testing, redundant documentation, and raising bugs as the primary communication channel instead of having risk conversations. [\[Is Fear-Driven Testing Holding Your Software Quality Back?, Ministry of Testing\]](https://www.ministryoftesting.com/articles/is-fear-driven-testing-holding-your-software-quality-back) This is not a QA personality problem. It is a measurement problem and a context problem. Leaders built those measurements. They often do not build the context around them. ## Three Engineering Management Conversations That Change This You do not need to restructure QA to shift the relationship. You need to change three specific conversations. Tell QA what matters most before the sprint starts. Not the feature list. The specific thing that would hurt customers if it shipped broken. The payment flow nobody has touched in six months. Give QA the context that makes prioritization possible. Equal coverage is what happens when there is none. **Ask for risk instead of status.** Change "how many test cases are left?" to "what concerns you most about this release?" It takes a few sprints for QA to trust that you actually want the honest answer. When they do, you get judgment instead of metrics. You get information you cannot get from a dashboard. Surface the tradeoffs when QA gets compressed. When development runs long and QA inherits a shortened window, make the tradeoffs explicit rather than absorbing them quietly. If we run the full suite, we need two more days. If we ship on Thursday, here are the areas we skip and here is what that means. Let the business decide with full information. QA cannot advocate for what they need without the language to explain why it matters to you. You can help them build it. Or you can stay frustrated that they are not providing it on their own. For more on the principle behind this: [Context Beats Process Every Time](https://medium.com/@stafford.jesse). Giving people context enables judgment. Giving them process requires them to stay in their lane. ## What Happens When You Change the Goals The conversations above will shift how QA communicates sprint-to-sprint. The deeper shift happens when you change what QA is measured on. When I led a QA team directly in game development, their goals were entirely individual: how many defects they documented, whether the test cycle finished within the window they were given. Those goals measured what QA could control in isolation. They had no connection to what customers actually experienced. I changed the goals to team-level outcomes: defects reaching customers, and whether the entire game team delivered on time together. This required QA to change how they worked with the rest of the team. They had to get into conversations earlier in the sprint. They had to understand what was being built and why. The team resisted. That was expected. Any goal change disrupts the comfortable way of working, and resistance is normal. The change that made the difference was not the goals themselves. It was that the goals required QA to have a different kind of relationship with the engineering team. They had to learn the context that would let them make better risk judgments. And I had to give it to them. Here is what that looked like in practice. Before the goal change, the QA report for a sprint arrived as counts: 143 test cases complete, 22 bugs filed, 19 resolved. After the goal change, the conversation started differently. QA came into sprint planning with questions about what had changed in the authentication flow and what the payment processing team had modified. They left with a prioritized list of what they were most concerned about and why. The shift was not a restructuring. It was a measurement change that forced a relationship change. If your QA team is giving you counts when you need risk assessments, the measurement system is almost certainly pointing them in the wrong direction. [\[Top Software QA Challenges in 2026, QA Source\]](https://www.qasource.com/blog/top-software-qa-challanges) covers the squeeze problem in detail: why QA teams accept timeline compression without pushback and what that pattern costs the business. ## Monday Action Before your next sprint, tell your QA lead what matters most to the customer in this release. Not the feature list. The one thing that would generate a support escalation if it shipped broken. Then ask QA what they are prioritizing differently because of that. That conversation is the beginning of the relationship change. **Have you ever changed how your organization thinks about QA? What actually moved the needle?** You're great at the work. Let's make you impossible to ignore. If you are looking for help improving how your engineering team works with QA and other technical partners, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/software-engineers-so-hard-leadhttps://jessestaffordcoaching.com/blog/software-engineers-so-hard-leadThere is a conversation I have had more times than I can count. An engineer on my team is doing genuinely good work.Sat, 29 Aug 2026 00:00:00 GMTThere is a conversation I have had more times than I can count. An engineer on my team is doing genuinely good work. By any technical measure, they are one of the stronger contributors. Their promotion has been stalled for two years. When I ask them what they think is getting in the way, they describe the features they built, the problems they solved, the systems they improved. They do not mention that the people who make promotion decisions have almost no visibility into any of it. That gap, between what an engineer knows about their own work and what the organization can actually see, is one of the most consistent problems in engineering management. And it is only one of three. ### The Engineering Manager Communication Gap That's Stalling Your Team's Careers Most management advice about engineers focuses on process: how to run better sprint reviews, how to set clearer expectations, how to structure 1-on-1s. That advice is useful. What it does not cover is the set of behavioral patterns that engineers bring to the table before any of those structures are in place. These are not failure modes. They are default behaviors that engineering training and culture produce. Understanding where they come from is the first step to doing something useful about them. After more than twenty years managing software engineers, I have narrowed the hardest ones down to three. ### Three Engineering Management Challenges You Have Probably Stopped Naming Out Loud **Overconfidence about their own work. Skepticism about everyone else's.** The engineer who dismisses a colleague's design as poorly thought through is often the same engineer who is completely confident their own estimate will hold. Both positions are usually wrong by a similar margin. This pattern shows up in code reviews that turn into status contests. In estimates that get defended rather than questioned. In planning meetings where every engineer is convinced the other engineers are the problem. I have watched this long enough to recognize it as a pattern, not a personality flaw. It turns out there is actually a name for it: Dunning-Kruger. Engineers overestimate their own work while underestimating the people around them. Even the genuinely skilled ones. You cannot accurately evaluate someone else's problem from the outside. **Precision at the wrong moment.** Engineering culture selects for precision. That is not a weakness. The ability to think in exact terms, to notice when two people are using the same word to mean different things, to catch definitional errors before they become bugs. This is real and valuable. The problem is when that same precision instinct shows up in a planning meeting where the goal is a decision. I have sat in rooms where the first thirty minutes went to debating what "done" means for a feature no one has started building yet. The instinct is right. The context is the problem. **Principled resistance to visibility work.** This is the one that costs people careers most directly. Engineers take an idealistic stance against the behaviors that would actually help them advance. Not ethical objections. Principled resistance to things like talking in cross-functional meetings, building relationships outside their immediate team, or framing their work in language their senior leaders can understand. "I should not have to talk in meetings. They should pay attention to me and know what I am doing." "I should not need to work with that other team to get the right result." I watched an engineer spend three years doing excellent work that almost no one outside their immediate team could see. When the promotion stalled, they were genuinely confused. They had built things that worked. They had not made those things visible to the people making career decisions about them. According to research from PostHog, searches for "product engineer" grew 89% between 2021 and 2024. These are engineers who actively engage with customers and understand what the product does for real people. The market is recognizing what engineering managers have known for years: customer and organizational awareness is not a default engineering skill. It has to be developed. [(PostHog: Product Engineer vs. Software Engineer)](https://posthog.com/blog/product-engineer-vs-software-engineer) ### Why Engineers Are Trained to Struggle With This Here is the root cause that took me years to see clearly. These patterns are not personality defects. They are the predictable output of how engineers are trained, hired, and rewarded. Engineers spend their entire education focused on one thing: find the best solution. The person who does that fastest and cleanest wins. You build confidence by being right. You advance by knowing more than the people around you. **The overconfidence pattern and the semantic precision instinct are not accidents. They are what the system selected for.** The visibility problem has the same root. Engineers are also taught, early in their career and mostly by example, that if you build good things, people will notice. That was true when the team was small enough for everyone to see the work directly. It stops being true somewhere around the time the organization grows past twenty or thirty people, and nobody tells the engineer that the rules have changed. This is not an engineering problem. It is an information problem. The behaviors make complete sense given what engineers have been taught about how success works. The Pragmatic Engineer's research on software engineering promotions confirms what I have seen: the engineers who advance are not just technically stronger than their peers. They are also visible to the people making career decisions. That is a skill most engineers have never been coached on. [(Pragmatic Engineer: Software Developer Promotions)](https://blog.pragmaticengineer.com/software-engineering-promotions/) ### Three Conversations That Actually Change Things Here is what to actually say. **For the overconfidence pattern:** Do not challenge the engineer's technical assessment directly. That triggers defensiveness. Try this instead: "I want to talk through how your read on \[colleague's work / this estimate\] is landing in the team. Can we spend ten minutes on it?" You are making it a conversation about perception, not a debate about facts. The engineer can engage with "how it is landing" without having to defend their position. **For the semantics pattern:** When a meeting goes into definitional territory, name it without judgment: "I want to make sure we get a decision out of this meeting. Can we agree on a working definition for today, even if it is imperfect, and revisit the language after we have tested it?" You are not telling them precision is wrong. You are giving the instinct a better outlet: define it, test it, refine it. Engineers can work with that. **For the visibility pattern:** This is the conversation most managers skip entirely because it feels uncomfortable to say. "I want to talk about something that is affecting your career. The work you are doing is strong. The problem is that the people who influence your next move cannot see it." "That is not about your work quality. It is about the gap between what you know you are doing and what is visible outside this team. I want to help you close that gap." Then ask: "Who in senior leadership do you think has a clear picture of what you have built in the last year?" The answer to that question usually opens the conversation on its own. ### What Changes When Engineers Get This Information I have managed engineers who were all three of these things. Skeptical of everyone's work but their own. Precise to a fault in planning meetings. Principled in ways that were quietly limiting their career. Some of them are now directors and senior managers. What changed was not their technical skill. What changed was that someone told them the truth about how their behavior was landing. Not as a performance issue. As information they did not have about how the organization actually worked. When engineers understand what is actually required at the level they want to reach, most of them adjust. They are problem-solvers by nature. Give them an accurate problem and they will work on it. For a related read: [Engineers love solving problems. That's the problem.](/blog/engineers-love-solving-problems-thats-problem) **This week:** Choose the one conversation from the three above that fits the engineer on your team who needs it most. Not all three conversations at once. One engineer. One conversation. Frame it as information, not feedback. See what opens up. <hr /> What is the one engineer behavior that frustrates you most as a manager? Have you ever had the conversation that actually changed it? <hr /> You're great at the work. Let's make you impossible to ignore. If you are looking for help having the conversations with your engineers that shift how they see the path ahead, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/technical-leaders-lead-have-titlehttps://jessestaffordcoaching.com/blog/technical-leaders-lead-have-titleThere is a number that should change how you see every meeting you walk into. Only 6% of Gen Z and millennial professionals say achieving a leadership...Thu, 27 Aug 2026 00:00:00 GMT## The Leadership Vacuum in Every Meeting Room There is a number that should change how you see every meeting you walk into. Only 6% of Gen Z and millennial professionals say achieving a leadership position is their primary career goal, according to the 2026 Deloitte Global Gen Z and Millennial Survey. Separately, DDI research found that 71% of people report that taking on a leadership role contributed to their stress levels. Read those two numbers together. In most rooms, in most meetings, in most project teams, the overwhelming majority of people are quietly hoping someone else will step up and own the decision. That is not a weakness of the people around you. That is the real landscape of every room you walk into as a technical leader. I spent the first six months of my first management role treating authority like something I had to earn before I could use it. I held consensus meetings that did not need consensus. I waited for more certainty before making calls. I softened every decision. My team followed me. Dutifully. Nowhere. The shift was not about earning more authority. It was about seeing the room differently. Very few people actually want to lead. The ones who choose to decide are almost always the ones who get followed. ## Why Technical Leaders Are Well-Positioned to Step Up Technical leaders have a skill set that translates directly into informal leadership: the ability to see a problem clearly, name it accurately, and have a point of view about what should happen next. The gap is rarely capability. The gap is permission. Most technical leaders are waiting for someone to officially hand them the authority to lead. They are doing this in rooms where the majority of the people around them would be genuinely relieved if someone just stepped up and decided. Research on emergent leadership confirms that this gap is real and fillable. NC State's Poole School of Management defines emergent leadership as "the degree to which an individual with no formal status or authority is perceived by one or more team members as exhibiting leaderlike influence." Their research shows that emergent leaders who step up without formal authority improve team cohesion, morale, and performance across the board. **The mechanism is more straightforward than most people expect: the person who takes the burden of the decision off the room's plate becomes the leader of that problem.** Not the most senior person in the room. Not the most experienced. The one willing to do the thing everyone else is grateful someone else is doing. When you step into that role, the room does not resist. It exhales. ## Four Moves That Create Peer Leadership Without Formal Authority Peer leadership does not require a title. It requires specific behaviors that most people in the room are avoiding. These four moves work whether you are the most junior person in the meeting or a mid-level contributor in a room full of senior leaders. ### Move 1: Name the decision nobody is naming Most meetings circle because the decision at the center has not been made explicit. The person who names it becomes the person the room looks to for resolution. "It sounds like we are trying to decide between X and Y. What do we need to make that call?" That sentence is not asserting authority. It is doing the work of noticing what the meeting actually needs. ### Move 2: Have a point of view on someone else's problem When someone brings you a problem with no direction and you respond with "let me think about it," you miss the leadership moment. When you respond with "Here is my recommendation. Tell me what I am missing," you create one. You do not need authority to have an opinion worth hearing. You need the willingness to have one. ### Move 3: Volunteer for the gap Every team has work that does not clearly belong to anyone. Projects that span departments, decisions that fall between roles, problems that require someone to stand up and be accountable for the outcome. Technical leaders who get promoted faster than anyone expected are usually the ones who step into those gaps. Not to claim territory. Because someone needs to own it and they are willing to be that person. ### Move 4: Put a stake in the ground when nobody is moving When the decision is hard, the room stops moving. The longer it sits unresolved, the more relieved everyone will be when someone moves. "Here is where I land on this. Push back if I am missing something." That sentence creates a starting point. It is not final. It is a direction. And direction is what everyone in that room was waiting for. ## The Technical Visibility and Career Acceleration Pattern Here is the career pattern most technical leaders do not see clearly until years later. The people who get promoted faster than anyone expected are usually the ones who stopped waiting for permission to do the work the title was supposed to authorize. They found the gaps, filled them, and let the formal recognition catch up. I built most of my career this way. I found the gaps between departments, the work that did not clearly belong to anyone, the problems that mattered and that everyone was hoping someone else would own. I bridged those gaps without a title for any of it. Eventually my company built a leadership role around my skill set because I had already been doing the work. This is a technical visibility pattern as much as a leadership pattern. When you lead without a title, you become visible to the people who matter. When you make the call, you become associated with the outcome. When you take the gap work, you demonstrate the judgment and initiative that formal leadership roles require. The formal title almost always follows the informal leadership, not the other way around. A 2024 literature review on emergent leadership published through ResearchGate found that informal leaders "compensate for weak formal authority by fostering initiative, trust, and collaboration within teams, leading to more dynamic problem-solving and innovation." The research is catching up to what experienced leaders already understand from watching rooms. One thing worth naming plainly: many people who hold formal leadership titles are not actually doing this. They wanted the compensation, the status, the org chart position. They are still waiting for certainty before making the call. The rooms they run keep circling. The decisions keep getting pushed until the deadline makes them. You do not need a title to lead better than that. ## The Hardest Part Is Not the Skill. It Is the Permission You Give Yourself. Most technical leaders do not have a skill gap when it comes to leadership. They have a permission gap. We are taught to wait. Wait for the promotion. Wait for the right moment. Wait until we feel ready. Readiness almost never comes before the moment. The rooms keep circling while you wait. The moment I stopped asking permission to do what the business needed done was the moment my career shifted. Not the day I got a promotion. The day I stopped waiting for one. If you are in a room where no one is leading, that room needs someone. The question is not whether you have the authority. The question is whether you have the willingness. ## Monday Action Pick one meeting this week where no one is making the call. Name the decision out loud before it ends. "It sounds like we need to decide X before we can move forward. What is missing for us to make that call today?" You do not need to be the most senior person in the room. You need to be the most willing. **Have you ever stepped up in a room where you were not the most senior person? What changed?** You're great at the work. Let's make you impossible to ignore. If you are looking for help building leadership presence before the title catches up, consider reaching out. [Jesse Stafford Coaching](/) **Sources:** - Deloitte Global Gen Z and Millennial Survey 2026: [deloitte.com](https://www.deloitte.com/global/en/issues/work/genz-millennial-survey.html) - DDI leadership research: [exec.com](https://www.exec.com/learn/28-eye-opening-leadership-development-statistics-that-will-transform-your) - NC State Poole School, Emergent Leadership: [poole.ncsu.edu](https://poole.ncsu.edu/thought-leadership/article/making-sense-of-emergent-leadership/) - ResearchGate, Emergent Leadership Literature Review (2024): [researchgate.net](https://www.researchgate.net/publication/392402777_Literature_review_of_the_relationship_between_emergent_leadership_and_changing_effectiveness)https://jessestaffordcoaching.com/blog/engineering-leaders-actually-need-get-promotedhttps://jessestaffordcoaching.com/blog/engineering-leaders-actually-need-get-promotedThe engineering team structure most of us grew up in is actively inverting. For decades, the standard ratio in software companies was roughly six...Sun, 23 Aug 2026 00:00:00 GMTThe engineering team structure most of us grew up in is actively inverting. For decades, the standard ratio in software companies was roughly six engineers for every one product manager. In early 2026, Andrew Ng publicly described teams proposing a ratio of one product manager to every 0.5 engineers. He called it the product management bottleneck. \[1\] AI has made coding approximately 10x faster. The constraint is no longer how to build. It is deciding what to build. For engineering leaders, that shift is not abstract. It is a direct career signal. ## The Technical Leader Promotion Gap AI Is Widening Most engineering leaders were promoted because they were the best technical contributors on their teams. They solved hard problems fast, debugged what others could not, built things people relied on. That is the foundation of most engineering careers above senior engineer. That same foundation is what AI is compressing. When execution gets dramatically faster, the value of being fast at execution shrinks. The leaders who are building toward the next level need something different. They need to be the person who knows what to build and why, not just the person who builds it well. This distinction has always mattered at the senior level. What has changed is the urgency. Before AI, a technically excellent leader could stay in execution mode for years and still advance slowly through technical depth. That path is narrowing. The compression of execution is not a future risk. It is a current one. ## Why Engineering Manager Skills Are Shifting Faster Than Most Leaders Realize A 2026 analysis by CIO described what the engineering role is becoming: "The engineer of 2026 will spend less time writing foundational code and more time orchestrating a dynamic portfolio of AI agents... Their value will lie in designing the overarching system architecture, defining the precise objectives and guardrails for their AI counterparts, and rigorously validating the final output." \[2\] That is a description of judgment, not execution. Defining objectives, validating output, and designing architecture against organizational constraints are all judgment work. None of it requires faster coding. All of it requires understanding the business well enough to know what the right outcome looks like. The leaders advancing fastest right now are not the ones who write the most code. They are the ones who know which code should be written. And behind that question is a much harder one: which organizational problems are worth solving, for whom, and at what cost? **The work AI consistently cannot do is synthesis.** Synthesizing technical constraints, business priorities, user needs, and organizational politics into a decision that people can trust. That requires years of context, relationships, and judgment. It cannot be prompted. The traditional six-to-one engineer-to-PM ratio is inverting at AI-native teams. Some teams are now running two product managers for every one engineer. \[1\] The bottleneck is no longer building. It is knowing what to build. ## What Engineering Directors Actually Do That AI Cannot Replace The most valuable thing I learned when I moved into a director role had nothing to do with engineering. It was learning how other parts of the business worked and building relationships across departments. The leaders who understand the business beginning to end are best positioned to make an impact. They bring realistic solutions to the table because they understand the constraints those solutions have to fit. They know when a technically correct answer is organizationally wrong. They know when urgency is real and when it is manufactured. They know which stakeholders will block an initiative and which ones will champion it, and why. That knowledge takes years to build. It also cannot be downloaded. Every organization is different. The context that makes someone a trusted voice at the senior level is specific to where they have invested their time. **Getting things done at the senior level is about relationships across the company.** The leaders who have built those relationships make things happen. The leaders who have not are still waiting to be asked. ## The Execution Trap: Four Signs You Are Stuck Most engineering leaders who are in the execution trap do not know it. The work gets done, the team performs, and things look fine from the outside. The trap is in what is not happening: the conversations, the relationships, the decisions. Here are four questions that reveal whether you are building your career on a foundation AI is shrinking. **Do people ask you for "how" but rarely for "what" or "why"?** If your default contribution in meetings is to explain how something would be built, not whether it should be, you are in execution mode. That is the right mode at the individual contributor level. At the senior level, it is a signal that you have not been invited into the decisions yet. Or you have not been offering one. **Are you the person who gets pulled in when things break, but not when things are being planned?** Being the person everyone calls when production is down is valuable. It is also a trap if that is the only reason you get called. If you are not in the room when the decisions that create the problems are made, you are implementing someone else's judgment. You are executing someone else's plan. That is not senior leadership. That is senior execution. **Could someone with your exact skill set be hired off the street to do your current job?** This is not a comfortable question, but it is a useful one. If the answer is yes, your value is based on what you know, not who you are in the organization. The leaders who are hard to replace carry organizational context, relationship networks, and business judgment that take years to build in a specific environment. That combination is not on any resume. **When you imagine your role 12 months from now, does it look like a faster version of what you do today?** If the primary difference between your role now and your role in a year is speed, you are not building toward anything. You are just executing faster. The leaders who advance are the ones doing genuinely different work at each level. Less execution, more direction. If most of these describe you, that is not a failure. It is information. The transition from execution to judgment is available to any leader willing to make it. It starts with investing time differently. ## How to Start Building Toward Judgment The four moves below are not a complete playbook. They are the ones most engineering leaders skip. Get curious about adjacent problems. Start asking how other departments make money, lose money, and decide what to build. Sit in on a product planning meeting. Ask your finance partner what keeps them up at night. You are not trying to become a generalist. You are building context you cannot get from inside your own team. Take a position on what should be built, not just how to build it. Engineering leaders who only answer the "how" question are easy to replace. The ones who develop a point of view on "what" and "why" become part of the decisions. That is the price of having an opinion worth asking for. Train your replacement at the execution level. Once you can do something quickly, delegate it. The leaders who hold execution close because they are good at it are blocking their own path. What you can do in your sleep is exactly what you should be teaching someone else. Build relationships before you need them, especially outside your team. Getting things done at the senior level is about relationships across the company. You build that understanding deliberately, one conversation at a time. ## This Week Ask yourself which meetings you are invited to because of your technical knowledge, and which meetings you are invited to because of your organizational perspective and relationships. The ratio between those two tells you where you stand in this transition. If the technical ones outnumber the strategic ones significantly, you know where to invest. What is one organizational decision being made right now that you have a perspective on but have not been asked for input? You're great at the work. Let's make you impossible to ignore. If you are looking for help developing the judgment and visibility that senior technical leadership actually requires, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/engineering-manager-job-description-lefthttps://jessestaffordcoaching.com/blog/engineering-manager-job-description-leftMy boss's boss called me into his office two months after I became a first-level manager. My manager was there too.Sun, 23 Aug 2026 00:00:00 GMTMy boss's boss called me into his office two months after I became a first-level manager. My manager was there too. He walked me through it cleanly: which projects my team would own, who would be assigned to each, how often they would report status directly to him. When he finished, he asked for my input. I said: "If that is how you are going to manage me, you hired the wrong person for this job." The room went quiet. My manager looked at the floor. What came next was better than I expected. We actually talked about what I was there to do, what visibility he needed and was not getting, and whether I was there to make real decisions or serve as a human relay between my team and senior leadership. I asked to be fired or demoted if it was the latter. It was not. What came out of that conversation was simple. He needed information flow. I had been hoarding it instead of creating it. Once we named the real problem, we fixed it fast. But what surprised me was how close I had come to building exactly the management career he had described. Assigning tickets. Running status. Acting as a scheduling system with a performance review attached. I had been about to call that leadership. That conversation happened years before AI could run your standup for you. Now that future is here. And what it is exposing is not a gap in your skill set. It is a gap in how the job was defined. ## What Engineering Manager Job Descriptions Were Actually Measuring There is a persistent gap between what gets written in a job description and what actually builds a management career. The written version captures scaffolding: run standups, facilitate sprint reviews, communicate status upward, manage stakeholder expectations, complete performance reviews. That work is real. It has to happen. But it is not leadership. It is infrastructure. And for decades, organizations have been treating the two as the same thing. McKinsey research found that managers spend 18% of their time on pure administrative tasks and another 31% doing individual contributor work instead of managing. Nearly half the workweek, every week, on work that was never the actual job. Only 9% of managers say they are satisfied with how they allocate their time. The other 91% are not confused about the reason. Scaffolding expands to fill the role because someone has to run the standup, and you are the manager, so it becomes yours. The job description fills the calendar. The actual job gets whatever is left. Tools like Spinach AI, which generates standup summaries automatically, and Geekbot, which surfaces blockers in Slack without a meeting, are starting to absorb that scaffolding layer. The question now is what happens to the time. ## Engineering Manager Burnout and the Hidden Cost of Scaffolding Work Most conversations about manager burnout focus on volume. Too many reports. Too many stakeholders. Not enough support. That is real. But there is a layer underneath it that rarely gets named: managers burning out not from too much work, but from the wrong work. You know the feeling. The standup that requires zero judgment. The status update you could write with your eyes closed. The project tracker refresh before the Monday meeting because someone above you will check it and you need it current. That work is exhausting in a specific way. Not because it is hard. Because it is hollow. Somewhere in the back of your mind you know you are capable of more, and you are not sure when you stopped having time to show it. The leadership work does not exhaust you the same way. The conversation you were not expecting where someone finally told you what was wrong. The judgment call nobody asked for that changed an outcome. The moment you noticed a team dynamic about to break before anyone said it out loud. That work is tiring differently. The kind of tired that comes from having actually done something. AI is clearing the first category. Whether that creates room for the second depends on whether you can tell them apart. ## How to Measure Your Leadership ROI in 20 Minutes Pull up your calendar from the last two weeks. Go through it block by block. For each item, ask one question: Could an AI tool have run this? Standup facilitation where you aggregated updates and passed them up the chain. Sprint reviews where you ran the agenda and captured notes. Status reports requiring numbers pulled from three dashboards. Progress tracking. Admin reviews. Write down that number. Now count the other blocks. The conversation where someone came to you with a problem not in any agenda. The moment you noticed something was off with a direct report before they said anything. The performance conversation you had been putting off and finally ran. The time you pushed back on a timeline because you understood what your team could actually absorb right now. Those required you specifically. Your judgment. Your relationships. Your read on the room. The ratio between those two categories is your Leadership ROI. Not what is in your job description. Not what is in your performance review. What is in your calendar. For most engineering managers, that ratio runs 80/20 in the wrong direction. Not because they lack leadership capability. Because the scaffolding has taken over. ## Four Leadership Behaviors That Never Appear in a Status Update The work that actually builds a management career is invisible in almost every organizational system. It does not show up in sprint metrics. It does not surface in a performance review until long after the impact has compounded. It is not in any job description I have read. **Building relationships before they are needed.** The managers who navigate cross-team problems fastest are not more politically skilled. They already know the people on the other side. They put in time when nothing was at stake. When a problem crossed an org boundary, they had a person to call instead of an escalation to write. **Coaching through the unscheduled moments.** A high performer goes quiet for two weeks. A junior engineer starts making errors they used to catch. Someone stops advocating for themselves in meetings. These patterns are visible if you are paying attention. Acting on them early is leadership. Waiting until they show up in a metric is management. **Making judgment calls nobody asked for.** Context beats process in situations where a checklist has outlived its original reason. Knowing when the timeline needs to bend because you understand what your team can absorb. Recognizing when a policy applies and when the original problem it was solving has already been fixed. **Naming things before they become incidents.** Friction between two engineers that has not yet become visible to the team. A miscommunication that is about to become a pattern. A meeting where nobody is asking questions, which almost always means something is wrong. The leaders who catch these early do not have better data. They have been more present. None of this requires a new tool. None of it needs a formal process. Most of it happens in the ten minutes before a conversation goes somewhere else. ## Monday Action Take your two numbers from the audit: scaffolding blocks and leadership blocks. Pick one behavior from the list above. Not all four. One. The one where you know the gap is biggest. Block thirty minutes this week. Not for a meeting. For one conversation you have been putting off because the scaffolding ran over. It does not need to be long. It needs to happen. What does your calendar ratio tell you about where your leadership is actually showing up? You are great at the work. Let us make you impossible to ignore. If you are looking for help identifying your real leadership work and finding time to protect it, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/managing-someone-was-once-above-orghttps://jessestaffordcoaching.com/blog/managing-someone-was-once-above-orgSomething happens to feedback when the hierarchy inverts. You cannot always name it.Sun, 23 Aug 2026 00:00:00 GMTSomething happens to feedback when the hierarchy inverts. You cannot always name it. The feedback arrives on time. The words are professional. But something about it does not quite fit the work. It lands softer than the situation called for, or harder than the output warranted. And the person receiving it cannot explain why their manager is not quite giving them what they need. Most of the time, the manager cannot explain it either. I have been on both sides of this. I know what it feels like to receive feedback from someone whose sense of who I am was formed when they were above me in the org chart. And I know what it is like to be the manager giving feedback I believed was honest, that was actually being quietly shaped by a history I had not yet named. The second situation is the one worth examining. ## Why Manager Feedback Gets Complicated After a Seniority Reversal When someone who was once your organizational superior ends up reporting to you, the history does not disappear at the moment of the org chart change. It goes quiet. Then it shows up where you are least likely to notice it: in the feedback. Not in the relationship. Not in the day-to-day working dynamic. Specifically in the feedback. The relationship may feel entirely solid. Any initial tension may be long past. You may have a professional rapport with this person that functions well on most days. None of that protects your feedback from the distortion that is still operating underneath. The reason is documented in how performance management actually works. According to the Society for Human Resource Management, managers unconsciously seek out information that confirms their pre-existing impressions of an employee and discount information that contradicts those impressions. ([SHRM: Breaking the Cycle of Confirmation Bias in the Workplace](https://www.shrm.org/enterprise-solutions/insights/breaking-cycle-of-confirmation-bias-workplace)) A seniority history is exactly the kind of pre-existing impression that drives this bias. This person was once above you in the hierarchy. They had experience, authority, or organizational standing that you did not have at the time. That impression does not vanish at promotion time. It goes underground. And it shapes how you read their work. ## Two Feedback Failure Modes That Look Like Leadership Communication Once the seniority history is operating below the surface, it produces one of two feedback patterns. Sometimes both at different points in time. **The deference failure mode.** Your feedback softens below what the work actually deserves. You frame observations more generously than you would for anyone else. You let things slide that you would address with the rest of your team. What is driving it: somewhere underneath, it still feels uncomfortable to hold this person fully accountable. They were once above you in the org chart. Giving them hard feedback feels strange in a way you cannot quite name. So you soften. **The compensation failure mode.** Your standard for "good enough" shifts upward specifically for this person. You look harder for what needs fixing in their work. You hold their output to scrutiny that does not apply to anyone else on your team. What is driving it: somewhere underneath, you need the org chart change to make sense. If this person is not clearly performing at a level that justifies the inversion, the inversion seems wrong. So you compensate. Both look exactly like real management from the outside. Soft feedback looks like patience and trust. Hard feedback looks like high standards and rigor. The resistance is in your own perception of the situation. The behavior is indistinguishable from competent management at its best. The only way to catch it is to look at the pattern across all your conversations with this person. Not any individual moment. Is your feedback with them consistently less specific than what you give everyone else? Are your notes thinner after their 1-on-1s? Do you delay difficult conversations with this person in ways you would not with the rest of the team? Or in the other direction: do you hold their work to a standard that does not apply to anyone else? Do you look for what is wrong before you look for what is working? Those are the signals. ## The Leadership Communication Gap the Other Person Feels The person on the receiving end of this feedback often senses something is off, even without being able to name what it is. They usually know the history between you. They just do not see it as a particularly big deal. What they do not recognize is the impact that history is having on how you read their work. Feedback that is consistently softer than the work deserves stops feeling meaningful. Feedback that is consistently harder starts to feel like it is about something other than the work. Over time, the person on the receiving end begins to discount what you say. Not because they have decided you are wrong. Because something in the feedback does not add up. This is how the feedback relationship erodes. Not in one bad conversation. In many conversations where something was slightly off and neither person could say exactly what. For a broader look at how pre-formed impressions distort ongoing performance evaluation, AIHR's guide to interviewer bias is worth reading. The patterns it describes in initial hiring evaluations apply directly to how seniority history continues to operate in an ongoing management relationship. ([AIHR: 11 Ways to Avoid Interviewer Bias](https://www.aihr.com/blog/interviewer-bias/)) ## How to Give Feedback That Is Actually About the Work You do not need to surface the history with them directly. You do not need to name it in a 1-on-1. The work happens in your head before you walk into the room. **Name the history to yourself.** Before the conversation. Out loud. In private. Say it directly: this person was once above me in the org chart. That dynamic existed. It ended. What does this person actually need from me today? You cannot set something aside that you have not first picked up and named. Trying to manage this well without doing that step is like trying to drive without acknowledging you are looking at the rearview mirror. The history is always just on the edge of your peripheral vision. **Anchor every piece of feedback in a specific behavior.** A specific situation, what they did, the impact it had, and what a better response would have looked like. Not a general impression. "In Thursday's team meeting, you redirected a question from your engineer before they had finished asking it. Two people stopped contributing for the rest of the session. Next time, let them finish before you decide how to respond." When feedback is anchored to what actually happened, the history has less surface area to distort it. The work is specific. Your response should be too. **Run the equity test before any significant conversation.** Ask yourself one question before you walk in: would I give this same feedback, at this level of directness, to someone with no shared history? If the answer is no, stop and find out why. That gap is where the old dynamic is still running. ## When the History Includes a Formal Evaluation The most charged version of this situation is when the seniority history includes a moment when this person formally evaluated you. They interviewed you. They reviewed your work. They held, at some point, a position of documented judgment over your career path. I have been in this situation. I was promoted to manage a manager who had originally interviewed me as a candidate and decided not to hire me. I knew the history before I took the role. I thought it would not matter. I was wrong. It took me a long time to catch what that history was doing to my feedback. I thought I had processed it. The feedback told a different story. When the history includes a formal evaluation, the confirmation bias SHRM describes becomes harder to neutralize. You are not working against a vague general impression. You are working against a recorded conclusion that was once attached to your name. That conclusion does not evaporate at promotion time. The same three steps apply: name it specifically, anchor feedback in behavior, run the equity test. But in this version, the naming step matters more. You have to say not just "they used to outrank me" but "they formally evaluated me, and they reached a conclusion about me." That is the specific thing you are setting aside before you walk in. For more on navigating the complexities of working with people after formal evaluation processes have run their course, Ask a Manager has written directly about what this dynamic looks like from the other side. ([Ask a Manager: I need to partner with a team that rejected me for a job](https://www.askamanager.org/2026/01/i-need-to-partner-with-a-team-that-rejected-me-for-a-job.html)) ## Monday Action Before your next 1-on-1 with this person, take five minutes and write down two or three pieces of feedback you plan to share. For each one, ask yourself: would I give this same feedback, at the same level of directness, to someone with no shared history between us? The gap between what you wrote and what you would give someone else is where the work is. Have you managed someone who was once above you in the org chart? What did you have to work through to make the feedback relationship clean? You're great at the work. Let's make you impossible to ignore. If you are looking for help giving feedback that builds trust across complicated team dynamics, consider reaching out. [Jesse Stafford Coaching](/) - External references: - [SHRM: Breaking the Cycle of Confirmation Bias in the Workplace](https://www.shrm.org/enterprise-solutions/insights/breaking-cycle-of-confirmation-bias-workplace) - [AIHR: 11 Ways to Avoid Interviewer Bias in Your Selection Process](https://www.aihr.com/blog/interviewer-bias/) - [Ask a Manager: I need to partner with a team that rejected me for a job](https://www.askamanager.org/2026/01/i-need-to-partner-with-a-team-that-rejected-me-for-a-job.html)https://jessestaffordcoaching.com/blog/megamanager-trap-doubling-team-size-hollowshttps://jessestaffordcoaching.com/blog/megamanager-trap-doubling-team-size-hollowsThe average American manager now oversees 12.1 direct reports, up from 8.2 in 2013, a 47% increase in twelve years, according to Gallup's latest...Sun, 23 Aug 2026 00:00:00 GMTThe average American manager now oversees 12.1 direct reports, up from 8.2 in 2013, a 47% increase in twelve years, according to Gallup's latest workplace research. Fortune's coverage this spring called it the "megamanager era," tracing it to a deliberate corporate strategy: three years of middle-management flattening, accelerated by AI cost-cutting and a relentless push to rationalize headcount. The result is that managers who once had eight reports now have fifteen or twenty. Coaches and consultants are pitching better systems: smarter templates, structured agendas, batched skip-levels. And some of that is useful. What it misses is the part of the problem that does not have a system. ## When Your Team Doubles: What Research Says Happens First Gartner's 2026 research found that 75% of HR leaders believe managers are already overwhelmed by expanding responsibilities. Fortune's reporting named it directly: coaching, mentorship, and hands-on development are "the first casualties when a single boss is stretched thin." Not the meeting. The work inside it. Most managers who absorb a doubling of their span do not consciously decide to stop coaching their people. They decide to make their 1-on-1s more efficient. They build better agendas. They move from bi-weekly to monthly. They prioritize the people with the most urgent issues. At some point they look up and realize they have not had a real career conversation with three people on their team in four months. They have not heard from the quiet ones. They are tracking tasks, not people. The research and the anecdote land on the same thing: the real conversation is the first casualty. Not because managers stop caring. Because the philosophy underneath the calendar was never examined. ## The Leadership Decision Nobody Names There are two things a manager can believe about a 1-on-1. The first: it is a scheduled obligation. A container for important topics. A recurring meeting that needs to be filled efficiently and protected from being too long. The second: it is the primary mechanism by which you actually lead the person in front of you. These beliefs produce identical calendars in the early days. Both have 1-on-1s on the schedule. Both have some kind of agenda. The difference becomes visible when the team doubles. If the 1-on-1 is a scheduled obligation, the first thing to cut when time is scarce is the time spent on it. Monthly starts to feel fine. The agenda gets shorter. Quarterly starts to feel like enough. If the 1-on-1 is the mechanism by which you lead, something else has to go when time is scarce. You look at your calendar for what is not load-bearing. The meetings you attend as a stakeholder but don't drive. The recurring syncs nobody would miss if they stopped. Start cutting those. The 1-on-1 frequency should be the last thing to change, because you know the relationship is inside the frequency. The managers who come through a span doubling with their teams intact are rarely the ones who found a better scheduling system. They're the ones who made this decision early, at the philosophy level, before their calendar got out of hand. ## What Happens at Large Span: The Inner Group Model There is a span above which even the second type of manager runs out of runway. At some point, for many leaders around 15 to 20 direct reports, holding bi-weekly 1-on-1s with everyone becomes genuinely impossible alongside the rest of the role. The managers I have watched navigate this well do not try to solve it with shorter 1-on-1s. They solve it with structure. Here is what that looks like in practice: identify three to five people who each track a different area of the team's work. Hold those relationships at higher frequency and depth. They become your eyes on the organization. They surface problems before those problems reach your 1-on-1 calendar at all. You still hold 1-on-1s with the full team. But this smaller group gets more of your time and attention. They become the depth layer. The rest of the team gets your consistency. The side effect, if you do this well: those three to five people grow into the leaders who come next. The inner group model is not a workaround. It is succession planning happening in real time. ## How to Protect 1-on-1 Quality When Headcount Grows The question is not how to make 1-on-1s more efficient. It is how to protect the part of them that cannot be made efficient: the real conversation. Here is what that protection looks like in practice. **Name what the 1-on-1 is for.** If yours are carrying status updates, you have already lost. Status has other channels: standup, Slack, the written update. The 1-on-1 is for career goals, the relationship, the feedback the person will not raise in any other setting. If you can replace it with a message, it was not a real 1-on-1. **Set a floor and hold it.** Monthly with everyone. Bi-weekly with your most important people. The floor is not about time management. It is about relationship maintenance. A dropped 1-on-1 is a missed commitment. Reschedule it that week. **Find what else can go.** Something has to give when headcount grows. Make sure it is not your 1-on-1s. Look at your calendar for the meetings that are not load-bearing and cut those first. **Ask the right question in the first five minutes.** Not "what are you working on?" Not "where are you on X?" The question that only a 1-on-1 can answer: "What is making this hard right now?" That question surfaces the conversation no agenda captures. ## What Good Looks Like at Scale The managers who lead well at large span share one thing: they are honest with themselves about what they actually know about each person on their team. Not what projects they are on. Not their current task status. The deeper question: Do you know what this person wants from their career this year? Do you know what is making their work hard this week? Do you know what would make them leave? If you cannot answer those questions for half your team, the 1-on-1s are doing something. They are not doing leadership. That is the measurement worth tracking as headcount grows. Not 1-on-1 frequency. The quality of what you know. The megamanager era is a structural problem. But the gap between managers who come through it with their teams intact and those who do not is not structural. It is a decision made at the philosophy level, before the calendar gets touched. What do you believe the 1-on-1 is actually for? That answer determines everything that follows. ## Monday Action Open your 1-on-1 calendar. If your team grew in the last six months, count how many 1-on-1s moved from bi-weekly to monthly, or quietly disappeared from the schedule altogether. That is your measurement. Then ask one question about each one: was that a scheduling decision or a philosophy decision? Most of the time it was a philosophy decision made by default, without noticing it was being made. That is the one worth revisiting before anything else. You're great at the work. Let's make you impossible to ignore. If you are looking for help building a leadership practice that actually scales, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/team-keeps-waiting-fixhttps://jessestaffordcoaching.com/blog/team-keeps-waiting-fixThere is a difference between telling someone they own something and actually giving them ownership. Most managers do the first and wonder why the...Sun, 23 Aug 2026 00:00:00 GMT## The Delegation Trap Most Managers Fall Into There is a difference between telling someone they own something and actually giving them ownership. Most managers do the first and wonder why the second never happens. Here is the pattern: a leader feels overwhelmed. They decide to delegate more. They hand off responsibilities, announce new accountabilities, maybe even set up a new meeting structure. Two months later, they are back at the center of every decision, fielding the same escalations, doing the same work. The team did not fail to step up. The system failed to exist. Distributed leadership requires more than good intentions. The version that actually works, where people act independently and make calls within their scope without waiting to be told, does not happen by default. It requires three specific conditions. Leaders who have those conditions in place find their teams running well even when they are unavailable. Leaders who skip them find themselves re-centralizing within months. ## What the Research Actually Shows MIT Sloan's Leadership Center conducted a four-year study comparing organizations using distributed leadership models against those using command-and-control structures. The result: distributed organizations fared better. Employees spread ideas faster, innovated more quickly, and were more engaged under shared mission. The model that worked was not "leaderless." It identified three types of leaders working in concert: entrepreneurial (idea generators), enabling (connectors who remove obstacles), and architecting (those who design the system itself). The architects are where most organizations fail. Handing off work is not architecture. Building the conditions for independent action is. Source: [Why distributed leadership is the future of management, MIT Sloan](https://mitsloan.mit.edu/ideas-made-to-matter/why-distributed-leadership-future-management) ## Condition 1: Scope, Not Just Responsibility "You own quality" is not ownership. It is a statement of aspiration. It gives someone a category without a boundary, and boundaries are what make ownership real. Scope means: these are the decisions you make. These are the things you track. When something in this area needs attention, you are the one who notices and acts. Not after asking me. Not after I bring it up. The test is simple: if your team member is not sure whether a decision is theirs to make, the scope is not clear enough. If they are escalating things you think they should handle, the boundary of their ownership was never drawn. Most leaders skip this step because it requires specificity that feels premature. You cannot predict every situation. True. But you can define the operating envelope: what falls inside this person's scope, what falls outside, and how to handle the gray areas. That conversation is the architecture. The guardrail needs to run in both directions too. Not just what they own but what they do not own. Without both sides of that boundary, people either over-escalate out of caution or make calls they should not because nobody told them where the line was. ## Condition 2: Context, Not Just Process ### Why Process Fails When Judgment Is Required The second condition is the one that most often breaks down after handoffs happen. Someone technically owns a thing, but they do not know why it matters. So when circumstances change, they follow the process even when it is wrong for the situation. Context is what enables judgment. It is the difference between someone who executes a checklist and someone who knows what the checklist is protecting against. When they have context, they can adapt. When they only have process, they stay in their lane even when the lane is going the wrong direction. Here is a practical example. A leader I know grew their team from five people to twenty over the course of a year. During that growth, they continued doing all the internal relationship work themselves. Tracking priorities, meeting with customers, managing visibility for the whole group. The team executed well. But nobody ever learned why the relationship work mattered or how to do it. When that leader's responsibilities expanded and they could no longer do it themselves, the work stopped. Nobody stepped in. Nobody even knew it was missing until months of organizational drift had already happened. It took years to rebuild. Not because the team lacked capability. Because they lacked context. Context transfer sounds simple: tell people why their work matters. Tell them what outcome it protects. Tell them what a good judgment call looks like in a situation you cannot anticipate. The leaders who do this find their teams extending that context into situations they were never briefed on. The leaders who skip it find themselves needed everywhere. ## Condition 3: Repeated Goals, Not One-Time Briefs There is an old principle about how many times someone needs to hear something before it actually shapes their behavior. The number is usually cited as seven. The important part that gets dropped: it is seven times per person. If you have ten people on your team and you state a goal once in a team meeting, you have communicated it once. For it to land, you need to say it seven times to each of them. Different contexts, different moments, different conversations. Seventy touchpoints for one goal. This is not inefficiency. This is how people internalize what matters. Goals stated once at the beginning of a quarter and never mentioned again do not guide behavior. They become wallpaper. The leader's job is not to announce goals. It is to keep them alive. In every 1-on-1. In every team meeting. In the moments when something unexpected happens and someone has to decide without you. When the goal is alive, people make decisions that serve it. When it is dormant, they make decisions based on what they can see in front of them. ## The Architecture Mindset Shift Distributed leadership is not a trust exercise. It is a design exercise. The leaders who build teams that run well when they are unavailable are not the ones who trust most. They are the ones who: - Named specific scope before handing off ownership - Transferred context before expecting independent action - Kept goals alive through repeated, intentional communication These are buildable things. None of them require special talent or perfect timing. They require deliberate choices made before you need them to pay off. If you are the only person who can do something your team depends on, the problem is not your team's initiative. The problem is architecture. Something was not built. ## Start Here Pick one area of your work that currently requires your involvement for a decision to get made. Not because the decision is above your team's capability. Just because the system was never designed otherwise. Ask yourself three things before handing it over: Does the person who will own this know exactly what falls inside their scope? Do they know why this work matters and what outcome it protects? Have you said what the team is working toward often enough that they could make a good call without you? If the answer to any of these is no, that is your starting point. Have you handed off ownership to someone and found yourself back in the center six months later? What was the piece that was missing? You're great at the work. Let's make you impossible to ignore. If you are looking for help building a team that operates without you at the center, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/teams-fall-behind-leaders-scale-uphttps://jessestaffordcoaching.com/blog/teams-fall-behind-leaders-scale-upThe Pattern No One Talks About Leaders get promoted. Teams get bigger.Sun, 23 Aug 2026 00:00:00 GMTThe Pattern No One Talks About Leaders get promoted. Teams get bigger. And somewhere in the transition, a quiet kind of failure starts. It does not show up in performance reviews. It does not show up in the first quarterly report. But over time, something shifts. The team that was humming before the change starts losing ground. Visibility fades. Internal relationships that used to matter stop getting attention. The work that kept the team on the map slowly goes dark. The reason is almost never the quality of the work. The reason is what the departing or scaling leader was carrying in their head that never made it into anyone else's. Most leaders delegate tasks. Almost nobody delegates context. And it is the context that teams lose ground over. ## What Gallup's Research Actually Shows About Manager Transitions According to [Gallup's research on team engagement](https://news.gallup.com/businessjournal/182792/managers-account-variance-employee-engagement.aspx), managers account for 70% of the variance in team engagement. That finding gets cited constantly to argue that managers matter. But it also tells us something about what happens when a manager's institutional knowledge does not transfer. If one person holds 70% of the context that shapes how a team operates, and that person scales up, steps back, or burns out from covering too much, the team does not just have a leadership gap. It has a context gap. And context gaps do not close themselves. Gallup's [research on span of control](https://www.gallup.com/workplace/700718/span-control-optimal-team-size-managers.aspx) also shows that managers with large teams and heavy individual contributor workloads consistently show worse outcomes unless they have exceptional management talent. The leaders who survive large teams are not the ones with the most personal capacity. They are the ones who built a system where others could function without them covering every gap. Most leaders do not build that system. They accumulate the gap instead. ## The Invisible Work That Keeps Teams Visible Here is what leaders actually do beyond their official job description. They translate the team's work into language the business understands. They tend the relationships with the internal stakeholders who determine whether the team's budget stays intact. They show up in meetings where the team's interests need a voice. They make sure the right people know what the team is building and why it matters. None of this is in the job description. None of it gets written down. And almost none of it gets transferred when a leader steps up. I experienced this directly when my team grew from five people to twenty overnight. Suddenly I was not able to do the things for my team that I used to do, and nobody was behind me to pick up the pieces. My original team ended up losing a lot of ground because it took years to convince people that those pieces of work were important and to do it in a way that made the right impact. The team was not failing. The surrounding infrastructure was gone and nobody knew it had been there. ## Why "Just Delegate More" Is the Wrong Fix The leadership development industry has been telling people to delegate more for decades. More tasks. More ownership. More autonomy. That advice is not wrong, but it is incomplete. Delegation of tasks without transfer of context is like giving someone a car without telling them where they are going. They can operate the vehicle. They do not know the destination. When I look back at that period of team growth, the failure was not that I kept too many tasks to myself. The failure was that I had never helped my team understand why the surrounding work existed in the first place. Why did the internal customer relationship matter? Why was showing the team's work to the business not self-promotion but survival? Why was the backlog prioritized the way it was? When those answers lived only in my head, the work lived only in my hands. And when I could not do it anymore, it just stopped. ## The Context Transfer Framework Fixing this does not require a complicated handoff process. It requires asking different questions before the transition happens. **What does only you do?** Not the official responsibilities. The informal ones. The things you do because you have been around long enough to know they matter, but that nobody has put in any documentation. List them. These are your context gaps. **Who depends on this work?** For each piece of informal critical work, name who benefits from it. Not just "the team." Who specifically? The business unit leader who reads the status update? The internal customer whose project gets unblocked? Being specific makes the work transferable. **Why does this work exist?** Before handing off any piece of work, start with the problem it solves. Not the tasks involved. The business or team need that the work addresses. A person who understands the problem will find a way to address it even when the old approach stops working. A person who only knows the steps is helpless when the situation changes. **Who is your backup?** Not for you, for the work. The test is not "can someone do my job?" The test is "if I disappeared tomorrow, would anyone know why this critical work exists?" If the answer is no, you do not have a backup. You have a gap you have not named yet. ## What Leadership Looks Like When You Build the System Right Leaders who get this right do not delegate less. They delegate differently. They share context before they share tasks. They explain the why before they show the how. They treat institutional knowledge not as personal advantage but as team infrastructure that needs to be maintained by more than one person. The result is not just resilience when the leader steps up or steps away. It is a team that generates its own visibility, tends its own relationships, and does not lose ground when circumstances change. Several people from my team over the years have since become managers and directors. The ones who grew fastest were not the ones I gave the most tasks to. They were the ones I spent the most time with on the why. ## The Question to Ask This Week If you stepped away from your role tomorrow, what would your team lose that is not in any document? That question is worth sitting with. Not as an exercise in paranoia, but as a leadership diagnostic. Every answer you come up with is a transfer conversation waiting to happen. The delegation you should have had is not "here, take this task." It is "let me show you why this work exists, who depends on it, and what happens if it stops." Most of those conversations are overdue. None of them are too late to start. *Have you ever watched a team lose ground after a key person stepped up? What was the first thing to disappear?* You're great at the work. Let's make you impossible to ignore. If you are looking for help building a team that runs well when you are not in the room, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/brain-wont-let-stop-thinking-workhttps://jessestaffordcoaching.com/blog/brain-wont-let-stop-thinking-workI used to think the 2am brain was just part of the job. The things that surfaced in the middle of the night were never the big projects.Wed, 12 Aug 2026 00:00:00 GMTI used to think the 2am brain was just part of the job. The things that surfaced in the middle of the night were never the big projects. They were the small unresolved items. A message I had not replied to. A conversation I had been putting off. A decision I had not fully made. Small things. But they would surface because my brain had been trying to surface them all day, and I had not been writing them down. When I started capturing open items before closing the laptop, the 2am wake-ups stopped within two weeks. Not because I was getting more organized. Because I had finally given my brain somewhere to put what it was holding. ## The Neuroscience Behind Why Your Brain Won't Let You Clock Out I have noticed this pattern in my own practice for years. The moment I write something down somewhere I trust, I can actually stop circling back to it. It felt almost too simple to be the whole answer. There is a name for what happens. Bluma Zeigarnik, a Soviet psychologist, first documented the mechanism in 1927. Her finding: we remember unfinished tasks far better than completed ones. The brain treats open items differently than closed ones. It keeps the open ones running. In practice, this is what happens at work: when you leave a task unfinished without capturing it anywhere, your brain does not file it away. It keeps a background process running so you do not forget it. The more open items you have, the more processes run simultaneously. The more processes running, the more mental energy gets burned keeping score. Research by Christine Syrek and colleagues found that unfinished tasks at the end of the workweek led to rumination, making it significantly harder for managers to stop thinking about work. The items did not disappear at 5pm. They just went underground. Neuroscientist Daniel Levitin described the solution in [*The Organized Mind*](https://www.penguinrandomhouse.com/books/313653/the-organized-mind-by-daniel-j-levitin/): when you write something down somewhere you trust, your brain treats the item as stored and stops actively monitoring it. The act of capturing is the signal. You are not forgetting the item. You are telling your brain it is safe to release it for now. That is the mechanism. Not productivity. Not system optimization. Permission to stop. ## Why "Write Everything Down" Advice Does Not Stick: Technology Leader Burnout vs. Productivity Here is why most advice on this topic does not land. Almost everything written about capturing open items frames it as a productivity strategy. Write things down and you will accomplish more, stay organized, and get more done. If you are already overwhelmed, that framing asks you to optimize a system that is already breaking you. Productivity advice sounds like more work to someone who cannot get through dinner without the list surfacing. This practice is not about productivity. It is about decompression. When you write down an open item, you are not creating a task management system. You are telling your brain that this thing has not been forgotten, that it is safe, that you can come back to it. The pressure releases because the item now lives somewhere outside your head. Managers who hold everything in their head often believe they are being responsible. They believe carrying the mental weight demonstrates commitment to the work. The opposite is closer to the truth. Holding it in your head does not make you a better manager. It makes you less available for the things that require your full attention. > **When you keep twelve open items running in working memory, you are not being more responsible. You are creating your own burnout.** ## The Capture Practice: What Actually Reduces Manager Burnout The practice itself is simple. Once a week, I set aside an hour to quietly plan my schedule and capture what is still open. Not a productivity sprint. Not a system review. Just the practice of moving what is floating in my head somewhere I trust, so I can put it down. I also protect time during the workday to think and capture. Not to work. Just to sit with what is still unresolved and make sure it is written somewhere. If you do not create that time deliberately, your brain will create it for you. It just will not wait for a convenient moment. The rule for the tool: use whatever takes the least friction. A notes app. A notebook on your desk. A voice memo on the way home. Whatever you actually trust. The point is not the system. The point is a place where you can put something down and trust it will still be there tomorrow. Before you close the laptop each day, spend five minutes asking: what is my brain still holding? Not your full to-do list. Just the specific items that have been circling. Write them down. Then close the laptop and see what happens. ## The Capture Trap: When Your System Becomes the Problem There is a version of this practice that makes things worse. Some leaders build elaborate capture systems. Color-coded. Tagged. Multiple views. They spend the first hour of every morning maintaining the system. They spend evenings reorganizing it. The system that was supposed to give them relief has become the work itself. A capture system has one job: hold the open items so your brain does not have to. If maintaining your system takes longer than the work itself, you have traded one stressor for another. - Signs the system has become the problem: - You spend more than 10-15 minutes per day managing the tool rather than using it - You feel guilty when items sit in the wrong place or category - You have tags, categories, or views you have not used in weeks - Reviewing the system takes longer than completing the tasks inside it The fix is almost always simplification. A thing is open in your head, you write it down, you trust the place where you wrote it. The whole practice takes five minutes before you close the laptop. Sophistication is not the goal. Decompression is. ## Monday Action Tonight, before you close the laptop, spend five minutes capturing what your brain is currently holding. Not your to-do list. Not a project plan. Just the open items that have been surfacing during the day: the things circling in the background, the decisions not yet made, the conversations you have been putting off. Write them somewhere you actually trust. Then close the laptop. Tomorrow morning, check: did the list follow you to dinner? Did you wake up at 2am? If your brain let go, you found the practice. If it did not, something is still not captured. Go back and write it down. **Further reading:** - [The Zeigarnik Effect: Why Unfinished Tasks Stay in Mind](https://memoryos.com/article/the-zeigarnik-effect) - [The Organized Mind by Daniel J. Levitin](https://www.penguinrandomhouse.com/books/313653/the-organized-mind-by-daniel-j-levitin/) - [Productivity and Interruption: The Potential of the Zeigarnik Effect](https://hubstaff.com/blog/zeigarnik-effect/) What is the one item that follows you home most often? You're great at the work. Let's make you impossible to ignore. If you are looking for help managing your workload so you can actually step away from work without it following you, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/train-cognitive-reframing-leadership-skill-attitudehttps://jessestaffordcoaching.com/blog/train-cognitive-reframing-leadership-skill-attitudeThe project just got cancelled. You are sitting in the meeting where it happened.Wed, 12 Aug 2026 00:00:00 GMTThe project just got cancelled. You are sitting in the meeting where it happened. The budget is gone. The timeline is wiped. Three months of your team's work is on the table and nobody is making eye contact. Your brain has already drawn a conclusion. It happened in seconds. "This is because they do not take our work seriously." "I should have pushed back harder six weeks ago." "Nothing I do here ever matters." You did not choose that conclusion. It arrived. And now everything you do for the next two hours, two days, two weeks runs downstream of that conclusion you did not choose. Your tone in the debrief. The question you ask your team. Whether you advocate for the work or quietly bury it. This is the problem that cognitive reframing is built to solve. Not how you feel about the situation. The conclusion your brain hands you about it. ## Why Leaders Stay Stuck After a Leadership Setback The standard leadership advice around setbacks is to "stay positive" or "maintain resilience." Both are accurate and almost completely useless because neither tells you what to actually do in the forty-five seconds between a hard event and your first response. What happens in those seconds is a framing event. Your brain, working fast, assigns meaning to what just occurred. That meaning is what drives every decision that follows. Not the event itself. The leader who frames a missed deadline as "my team is unreliable" will make different decisions in the next standup than the leader who frames it as "we did not have the right information in time." Same deadline. Same miss. Different conclusion. The decisions branch immediately. This is not about being optimistic. It is about noticing that a conclusion arrived and asking whether it is the right one. ## Cognitive Reframing in Leadership: What the Research Actually Shows Sports psychologists have documented this for decades. The athletes who perform best under competitive pressure are not the ones who feel less. They have practiced what to do with what they feel: specifically, noticing the frame before acting on it. That same approach now has large-scale workplace evidence behind it. A Harvard Kennedy School field experiment followed over 4,000 workers through mindset reappraisal training. Six months later, participants showed measurable improvements in job performance, lower quit intentions, and better decision quality. What distinguished this study from earlier lab work: the effects persisted. This was not a temporary mood lift. It was a durable change in how people processed workplace situations. The study's conclusion aligns with what sports psychology has long shown. **Reappraising the situation, not just the emotion, produces real and lasting performance change.** You are not managing how you feel. You are questioning what the situation means before that meaning hardens into a decision. [Source: Harvard Kennedy School, Enhancing Workplace Well-Being Through Reappraisal](https://www.hks.harvard.edu/centers/mrcbg/programs/growthpolicy/enhancing-workplace-well-being-through-reappraisal-nationwide) For additional reading on cognitive reframing in competitive performance contexts: [Dr. Paul McCarthy, What Is Cognitive Reframing in Sport and Why Athletes Need It](https://www.drpaulmccarthy.com/post/what-is-cognitive-reframing-in-sport-and-why-athletes-need-it) ## The Learner/Judger Framework for Technical Leaders Marilee Adams developed a model called the Choice Map in her book *Change Your Questions, Change Your Life*. The core idea is simple: in any situation, you are operating from either a Learner frame or a Judger frame. **Learner frame:** open, curious. Asking what happened and what you can do about it. **Judger frame:** closed, critical. Asking who is to blame and what is wrong. The Judger frame is not irrational or weak. It shows up because something real went wrong. The problem is that it closes off the options you can see. You cannot solve a problem from inside the frame that makes the problem feel permanent. Here is what this looks like for a technical leader. The team misses a deadline. Judger question: "What is wrong with this team?" Learner question: "What did we not see coming, and what do we need to change?" You get passed over for a promotion. Judger question: "Why does this always happen to me?" Learner question: "What do the people who made this decision not know about my work, and what can I do about that?" The second question does not minimize what happened. It puts you in a position where action is possible. [Source: Inquiry Institute, Change Your Questions, Change Your Life](https://inquiryinstitute.com/books) ## The Line Between Reframing and Avoiding This is the distinction that most mindset content never makes, and it is the reason "think positively" advice fails. Reframing is not pretending the bad thing did not happen. It is not telling yourself the cancelled project was actually fine. It is not suppressing the frustration you felt in that meeting. The Judger frame is often accurate. Something did go wrong. Someone may genuinely be accountable. Your frustration is real and may be warranted. The question is what you do next. Staying in the Judger frame, without examining it, means the conclusion your brain handed you in forty-five seconds is running your decisions indefinitely. Most of the time, that first conclusion was incomplete. It was missing context. It assigned cause without information. The reframe is not about deciding everything is fine. It is about asking: is this the only conclusion available? And choosing deliberately, rather than acting on the one that arrived automatically. If the conclusion holds up under examination, you act on it. If it does not, you now have better information. Either way, you are making a deliberate choice rather than running on an automatic frame. This is the difference between resilience as a practice and resilience as a personality trait. You are not born with it. You build it by doing this, repeatedly, in small moments, until it is available in the large ones. I started with language. Years ago, I stopped telling people I was busy. Not because I was not busy. Because I noticed what that word was doing to my own frame. I convinced people I had no time for them, and I increased my own stress by framing my situation in a way that made it worse. I replaced it with: "I have not gotten as much done as I expected today." More accurate. Less closed. That small discipline built the habit that made larger reframes available later. ## How to Practice Leadership Mindset Development Daily The reframe becomes available under pressure only if you have practiced it when the stakes are low. Start here: this week, when you feel certain about something negative, write the certainty down. Then ask one question: what would have to be true for a different conclusion to be available? You do not have to take the different conclusion. You are not trying to talk yourself out of reality. You are practicing noticing that a conclusion arrived before you examined it. Do this three times in low-stakes situations: a minor miscommunication, a meeting that ran over, a request that came back with changes. By the time a real setback arrives, the habit of examining the first conclusion will already be in place. The McKinsey analysis of next-generation CEOs identified "calmly analyzing the root cause of a situation, depersonalizing, and bouncing forward" as a distinguishing leadership trait. That description, without calling it by name, is cognitive reappraisal. It is learnable. It is a skill, not a personality. [Source: McKinsey, The Leadership Traits of Next Generation CEOs](https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/scaling-the-21st-century-leadership-factory) ## Monday Action When something goes wrong this week, catch the first conclusion your brain hands you. Write it down in one sentence. Then write one alternative conclusion. Not a better one. Just a different one. Notice whether the alternative opens any options that the first conclusion closed. You are not looking for the correct answer. You are practicing the habit of seeing that more than one conclusion is available. That practice, built in small moments, is what composure under pressure actually looks like. What is one conclusion your brain handed you recently at work that turned out to be incomplete? What changed when you looked at it differently? You're great at the work. Let's make you impossible to ignore. If you are looking for help developing your leadership mindset and decision-making under pressure, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/communication-gap-thats-killing-teams-sensehttps://jessestaffordcoaching.com/blog/communication-gap-thats-killing-teams-senseAn individual contributor was blocking a launch over a documentation policy. Not maliciously.Tue, 11 Aug 2026 00:00:00 GMTAn individual contributor was blocking a launch over a documentation policy. Not maliciously. He genuinely believed the policy mattered more than the date. I could have escalated it as a compliance problem. Instead, I went to his manager and said something simple: "Help me understand what you need to make this work. Here is the goal I need to achieve and why it matters." The resistance did not go away because I pulled rank. It went away because, for the first time, someone had actually explained the goal instead of just enforcing the rule. That conversation is the whole argument of this post, compressed into one exchange. Most of the friction leaders experience with "urgency" is not a motivation problem. It is a communication gap between what the leader knows and what the team was actually told. ## Why Your Team Doesn't Share Your Sense of Urgency Here is the pattern I see over and over, in my own leadership and in the leaders I coach: something gets labeled urgent, and the team treats it like everything else on the board. The leader reads that as a character problem. Low ownership. Not enough drive. It is almost never that. The leader was in the room where the priority got decided. They know the customer commitment behind it, the domino it knocks over if it slips, the conversation they will have to have with their own boss if the date passes. The team was handed the deadline with none of that. Urgency is not a trait some people have and others do not. It is a piece of information, and if you only hand someone half of it, half of it is exactly what you get back. ## The Leadership Mindset Shift That Actually Works The shift that changed how I assign anything: if my team is not treating something with the weight I think it deserves, that is not a read on their character. It is a read on how much of the actual stakes I gave them. That reframe is uncomfortable the first few times you make it, because it means owning that the slow pace was something you built. Not something they chose. Once you see it that way, the fix stops being "how do I motivate this team" and starts being "what did I actually tell them." **This is a leadership admission, not a team diagnosis.** The team is not broken. The information handoff is. ## What the Research Says About Priority Communication This is not a rare failure limited to one bad team. A 2023 Slingshot Digital Work Trends survey found that 34% of workers say they regularly have to guess their real priorities at work, a gap wide enough that [HRO Today covered it as its own story](https://www.hrotoday.com/news/survey-34-of-workers-have-to-guess-their-priorities-at-work/). Separate research from Kaplan and Norton, referenced in the same coverage, found that more than 90% of employees do not fully understand their company's strategy or what is expected of them to help achieve it. That second number is the scaled-up version of the exact failure this post is about. If most employees do not understand the strategy behind their daily work, they cannot be expected to independently feel the urgency behind a single task inside it. [Let's Grow Leaders makes a related point](https://letsgrowleaders.com/2021/10/11/how-to-lead-when-your-team-lacks-a-sense-of-urgency/): urgency is not established the moment a priority gets communicated. It is established when the reasoning behind the priority gets shared, not just the priority itself. ## How to Explain Priorities So They Actually Land Four things I do differently now, in order: **1\. Say the why out loud to yourself first.** If you cannot answer "why does this date matter" in one sentence, you are not ready to hand it to your team yet. **2\. Replace the label with the consequence.** Not "this needs to happen by Friday." Try: "If this slips past Friday, the customer walks into the renewal conversation with the wrong numbers, and that call is one I am having, not you." Specific stakes travel. A label does not. **3\. Use the direct version of the ask.** Something close to: "Here is the goal I need to achieve, and here is why it matters." Say it plainly, without softening it into a suggestion. **4\. Save the full explanation for what is actually time-sensitive.** If three tasks are all "critical" this week, none of them are, and your team will learn to discount the next one too. ## The Difference Between Urgency and Micromanagement There is a real risk on the other side of this advice, and it is worth naming directly. Explaining the why on every task is not the same as explaining the why on the tasks that actually need it. Do that for everything and you have stopped leading and started narrating, which reads to a team as a manager who does not trust them to prioritize on their own. [The Business Growth Blueprint argues something similar](https://www.tbgbp.com/p/sense-of-urgency-why-most-leaders): urgency is not created by top-down pressure. It is created by clarity, trust, and decisiveness at every level. The goal of sharing the why is not to control every decision. It is to give your team enough context to make good judgment calls without you in the room. There is also a limit to what this fixes. Sharing the why is not a repair for a deadline that was never realistic. If the plan itself was wrong, no amount of explaining the stakes will make the math work. This is specifically for priorities that are legitimate but under-explained, not a patch for bad planning. ## Your Next Move Before you follow up again on the thing you have already called urgent once, pull up the actual consequence of it slipping. Write it in one sentence. Say that sentence to the person doing the work instead of repeating the deadline, and watch what changes. What is one thing on your team's plate right now where you have said "urgent" but never said why? You're great at the work. Let's make you impossible to ignore. If you are looking for help getting your team to move at the pace the work actually requires, consider reaching out. https://www.jessestaffordcoaching.comhttps://jessestaffordcoaching.com/blog/engineering-managers-change-team-listens-changinghttps://jessestaffordcoaching.com/blog/engineering-managers-change-team-listens-changingYou have probably been in a meeting where someone's word choice deflated the whole room. They said "we need to deal with the fallout from this...Tue, 11 Aug 2026 00:00:00 GMTYou have probably been in a meeting where someone's word choice deflated the whole room. They said "we need to deal with the fallout from this decision," and suddenly everyone's shoulders went up. The conversation moved from problem-solving to damage control before a single idea was shared. You may also have been on the other side of that without realizing it. ## The Vocabulary Gap That's Shaping How Your Team Responds Most engineering managers and technical leaders do not think much about word choice. They think about what they are communicating, not how they are saying it. The message is accurate, the information is correct. Why would the exact words matter? Because before your team processes the content of what you said, they process the connotation. The emotional signal arrives first. When you say you are going to "argue" with another department, your team hears conflict, not problem-solving. When you say you are going to "have a conversation," they hear collaboration, not confrontation. Same action. Completely different emotional frame. That frame sets how they show up to help you. And it sets how they talk about that interaction when you are not in the room. Research backs this up. Salesforce's "State of the Connected Customer" report found that employees who feel heard are 4.6 times more likely to feel empowered to do their best work. Word choice is a large part of whether people feel heard or dismissed, energized or deflated, included or shut out. ## Why Technical Leaders Fall Into Negative Language Patterns The problem is not intent. Most leaders who use negative language are not pessimists. They are problem-solvers. And problem-solvers are trained to identify what is wrong, what is broken, what needs to be fixed. That lens is valuable. But it leaks into vocabulary in ways that can undermine team morale and engagement without anyone realizing it. A few common patterns: **Conflict framing:** "I need to argue with," "fight for," "push back against," "deal with", all accurate descriptions of difficult interactions, but all primed for conflict before the interaction starts. **Tentative framing:** "We'll try to," "hopefully we can," "I'm not sure if we'll be able to", language that signals low confidence to the team even when the speaker feels fine about the outcome. **Problem focus:** "The issue is," "the problem with," "what's broken is", useful diagnostic language that can crowd out solutions-oriented thinking when it becomes the default opener. None of these are wrong. They are just automatic. And automatic patterns rarely serve you as well as chosen ones. ## The Listening Audit: How to Catch Your Own Patterns First Before changing anything, listen. This sounds obvious. It is harder than it sounds because you are not listening to understand. You are listening to classify. You are training yourself to notice a specific signal you have been filtering out your entire career: the emotional connotation of the words people around you are choosing. Spend three days in passive observation mode. Do not try to change how you talk. Do not coach anyone. Just listen. In your team meetings: which words are creating energy? Which are flattening it? When someone says "I intend to ship this by Friday," what is the different feeling in the room compared to "I'll try to get it done"? In your 1-on-1s: listen to how your team describes their work and challenges. Does their language mirror yours? Teams adopt their manager's vocabulary patterns more often than either party realizes. Then listen to yourself. Replay a conversation from memory. What words did you reach for automatically? Write the ones that carry negative or tentative connotations. Some common ones to look for: "argue," "deal with," "try to," "hopefully," "unfortunately," "problem," "broken," "failed." Write them down. Do not judge them. This is data collection. ## How to Change Your Leadership Vocabulary Without Sounding Fake The biggest concern leaders have when they hear "choose your words more carefully" is that they'll sound inauthentic. Managed. Coached to within an inch of their personality. That concern is understandable. It is also not what happens. What actually happens is this: when you consciously choose a word with a different connotation, you do not feel fake. You feel more accurate. "I'm going to have a conversation with the helpdesk" is not a spin on "I'm going to argue with the helpdesk." It is a more precise description of what you actually intend to do. The shift is not about hiding frustration or pretending problems do not exist. It is about choosing the word that reflects what you want the situation to become, not what you fear it might be. To make the shift practical: **Week 1:** Pick one phrase you use that carries the wrong connotation. Just one. Identify the replacement. "Argue" becomes "have a conversation" or "work through." "Deal with" becomes "work through" or "resolve." **Every 2 weeks after that:** Add one more phrase. The same process. Notice it. Pause before speaking. Choose the replacement. Speak it. After two weeks, one phrase will start feeling automatic. After two months, five phrases will be different. After six months, your default vocabulary has shifted in ways your team will notice even if they cannot articulate why. **The mechanism:** "I intend to complete this by Friday" vs. "I will try to complete this by Friday" are two signals about the same future action. One signals commitment. One signals doubt. Your team is reading both signals constantly. The words you choose automatically are teaching them how to read you. ## The Result Is Not Positivity. It Is Precision. The goal of this practice is not to become an optimist. It is to become someone whose language reflects their actual intent, not their worst-case fears or their habitual patterns. When you tell your team "I need to argue with another department," you are not describing your intent. You are predicting a failure mode. "I'm going to have a conversation with another department" describes what you are actually going to do. That distinction matters. And it compounds over hundreds of interactions a year. Your team will not be able to name what changed. They will just notice you are calmer. More intentional. More precise. The room feels different when you walk in. ## Start With Three Days of Listening Spend the next three days listening. In your meetings, your 1-on-1s, your Slack threads, your email. Notice three phrases you use regularly that carry negative or tentative connotations. Write them down. Do not change anything yet. Just notice. What is one word you use constantly that is probably setting the wrong tone before the conversation starts? You're great at the work. Let's make you impossible to ignore. If you are looking for help communicating more intentionally as a leader, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/internal-candidates-lose-outside-hires-makehttps://jessestaffordcoaching.com/blog/internal-candidates-lose-outside-hires-makeMost people know the hidden job market exists. Research consistently shows that 70 to 80 percent of job openings are never publicly advertised.Sat, 13 Jun 2026 00:00:00 GMTMost people know the hidden job market exists. Research consistently shows that 70 to 80 percent of job openings are never publicly advertised. Lou Adler surveyed more than 3,000 LinkedIn members and found that [85 percent of all jobs are filled via networking](https://www.linkedin.com/pulse/new-survey-reveals-85-all-jobs-filled-via-networking-lou-adler), before they are ever posted, before most candidates know to look. Most people file this away as an external job search problem. They assume it does not apply inside their own company. It does. And the people who understand that are the ones who get tapped. When a leadership role opens internally, most of the time the leaders responsible for filling it already know who they want. The posting is a process requirement. The decision happens in the months and years before it. The interview did not start when the role was posted. It started years ago, in every conversation, every cross-team collaboration, every moment someone showed up when they did not have to. ## The Internal Promotion Gap Nobody Talks About LinkedIn's 2024 Workplace Learning Report found that only [1 in 5 employees has confidence in their ability to move internally](https://learning.linkedin.com/resources/workplace-learning-report-2024) within their company. That is not primarily a skills gap. It is a visibility gap. Internal candidates assume the system is merit-based. They believe that tenure plus strong performance reviews will move them forward. Sometimes that is true. More often, the person who gets tapped is the one leadership already knew and trusted before the role was posted. The frustrating part is that most internal candidates do not find out until after the fact. They came in with the technical background, the company history, the institutional knowledge an outside hire would spend a year building. They did not get it. The answer is rarely the interview. The answer is who knew them outside their own team, and how well. ## Why Being Internal Does Not Make You a Known Quantity Here is the misread that costs most internal candidates. They apply for a role in another department and assume that "internal candidate" means "known quantity." You work there. You understand the culture. You have context that no external hire could have on day one. That is all true. And it only counts inside your own team. I have worked with people who wanted to transfer into a management role in another department and had never spoken to anyone who worked there. Had never tried to understand what that team actually did. Had never built a relationship with that team's leader or any of its members. And then could not understand why they did not get the role. At that point, they are not really an internal candidate. They are an unknown quantity in a familiar building. The hiring leader does not know how they think under pressure. Does not know how they handle ambiguity or communicate across teams. They know this person by reputation, and that reputation exists in exactly one corner of the organization. An external hire is a known risk. The gap is visible on paper and you can plan for it. An internal candidate nobody knows outside their own department is a hidden risk. Given a choice, most leaders will go with the person they already trust. Being internal does not make you a known quantity. Building relationships across the organization makes you a known quantity. ## How Technical Leaders Build Cross-Functional Reputation The leaders who get tapped do not usually know they are being evaluated. They are not running a visibility campaign. They are doing their jobs in a way that naturally crosses team lines. The pattern is consistent in people who advance without chasing it: they get curious about how other parts of the organization work before they need those relationships. They show up for other teams' problems the way they would want their own team to be shown up for. They step into the problems that nobody owns because those problems do not fit cleanly on any one team's roadmap. My own career moved forward not when I got good at my job, but when I got curious about how other teams' work connected to mine. I started following my own interest in how things fit together across the organization. I looked for the problems that sat between departments, the ones that fell through the cracks because they did not belong to anyone. Eventually my company built a leadership role around the skill set I had developed. I did not chase that role. I showed up in the right way long enough that the role found me. This is not a strategy. It is a habit of engaging with the broader organization before you need anything from it. There are three behaviors that build this kind of reputation: Get curious about adjacent teams before you need them. Ask someone you rarely work with to walk you through what their team is focused on this quarter. Do not pitch yourself. Do not try to solve their problems in the first conversation. Just listen and ask follow-up questions. Show up for their work the way you would want them to show up for yours. Do the work that crosses boundaries. Every organization has important problems that sit between teams. The ones nobody owns because they do not fit cleanly on any one roadmap. The leaders who become known across the organization are the ones who step into those gaps before anyone asks them to. Not to get credit, to solve something that needs solving. Show up as a leader in the moments that do not seem to count. How you handle a disagreement between two teams. How you treat people who have nothing to offer you right now. These are the moments that build the reputation that travels across an organization. Your manager sees your work every day. The people who will have input on your next role see these moments. ## The Technical Visibility Mistakes That Cost Internal Candidates Most career advice focuses on what to add. Update your profile. Attend more events. Ask for coffee chats. None of that is wrong, but none of it addresses the actual problem. The visibility mistakes that cost internal candidates are quieter than they appear. Staying in your lane too cleanly. Excellent work inside your team is not enough if the people outside your team do not know it exists. Organizations are large. The rest of the organization is not watching unless you give them a reason to. Waiting to build relationships until you need them. The worst time to start building credibility with another team is when you have applied for a role on that team. The relationships that count in hiring decisions were built months or years before any role opened. Building visibility with the wrong people. You are visible to your direct manager. Your direct manager is not always the person who controls the next role you want. The people who will have input on your next move are often two or three degrees away from your current reporting line. Treating cross-functional work as overhead. Participating when required, disengaging when optional. The optional moments are exactly where reputation is built or lost. The leaders who advance are the ones who show up as leaders in the rooms where nobody is formally evaluating them. The internal candidates who get tapped are not doing something elaborate. They have been having real conversations with people across the organization, long before any role was posted. That is the whole thing. ## Monday: One Conversation That Does Not Have a Pitch Attached Identify one team or function you would want to work near eventually. Find one person on that team and ask to understand what they work on. Not to position yourself. Not to start a visibility campaign. Just to learn how another part of the organization works. That conversation will not get you the next role. But the habit of having it regularly, long before you need anything, is exactly how you become a known quantity somewhere new. The interview is always happening. Not as pressure. As context. **Related reading:** - [Professional Relationships Drive Career Growth](/blog/professional-relationships-drive-career-growth) - [Your Peers Control Your Success. Here's How to Build Those Relationships.](/blog/peers-control-success-build-those-relationships) When did you realize the internal promotion decision had already been made before the posting went up? You're great at the work. Let's make you impossible to ignore. If you are looking for help building visibility and influence across your organization, consider reaching out. jessestaffordcoaching.comhttps://jessestaffordcoaching.com/blog/talking-manager-goals-enough-else-needhttps://jessestaffordcoaching.com/blog/talking-manager-goals-enough-else-needOften people who get passed over for leadership roles were not under-performing. They were invisible to the wrong people.Sat, 13 Jun 2026 00:00:00 GMTOften people who get passed over for leadership roles were not under-performing. They were invisible to the wrong people. This is a pattern that shows up in coaching conversations constantly. A high performer who has been clear with their manager about wanting to lead. One-on-ones every week. Goals stated plainly. Years of building toward the next step. And then a role opens up and goes to someone from another team, someone the skip-level already knew, someone whose name was already in the room. The person who got passed over was not less qualified. They were just unknown to the people making the decision. ## The Career Visibility Gap That Stalls Technical Leaders The advice most people get is straightforward: tell your manager what you want. Be clear about your goals. Show up, do good work, and your manager will advocate for you when the time comes. That advice is not wrong. It is just incomplete. Your manager is one voice in the promotion conversation, not the final word. At most organizations, promotion to a leadership role requires sign-off from the hiring manager's boss, input from peers at that level, and sometimes approval from a skip-level leader who has broader organizational authority. If any of those people do not know you, or do not know your goals, they are not in a position to advocate for you. A leadership promotion is not a performance review. It is a conversation about fit, readiness, and organizational need, happening in a room you are not in. The people in that room are making decisions based on who they know, who they have seen lead, and who they believe is ready. If the only person who knows your goals is your direct manager, you have one advocate in that room. One advocate who may not even be there if the role is outside their department. ## How Promotion Decisions Are Actually Made According to [research on skip-level management](https://blog.peakperf.co/skip-level-manager/), skip-level bosses control the budget, organizational structure, and the big promotion decisions. For advancement to higher leadership levels, your skip-level boss must know you and what you are capable of. The research goes further: "Your boss and their peers are the actual decision-makers for promotions. A five-minute phone call from an esteemed colleague of your skip-level on your behalf will accomplish more than any volume of reports, presentations, or interviews." This is not cynical. It is structural. Leadership promotion decisions require alignment across multiple stakeholders. Your direct manager has one vote. Their peers, their boss, and the broader leadership team fill in the rest. When you talk only to your manager, you are handing off the entire communication responsibility to a single person. And that person has their own priorities, their own relationship with their boss, and their own read on what the organization needs. ## Why Your Manager May Not Be Advocating for You Here is the part most leadership content leaves out: your manager's incentives may not align with your advancement. Your manager needs a functioning team. They need their projects staffed. They need someone reliable in the role you are currently in. Moving their best individual contributor into a management role creates a gap they have to fill, on a timeline that usually does not work in your favor. None of this means your manager is acting in bad faith. Most managers who stall promotions are doing it from a place of team management, not malice. [Research from Fast Company](https://www.fastcompany.com/91470056/what-to-do-when-your-boss-is-blocking-your-promotion) identifies this as one of the most common reasons promotions get delayed: managers who cannot imagine losing their top performer become the single gatekeepers who decide who advances and who stalls. The problem is not intent. The problem is that you have handed your entire career advancement to one person who has a structural reason to keep you where you are. That is a fragile position. If your manager does not talk to their boss about your goals, or frames the conversation in terms of "we need to find a backfill first," the skip-level leader goes into the promotion discussion without context. They do not have a reason to advocate for you. They may not even know you want the role. This is exactly what happened to me. I had talked about my goal in every one-on-one for months. My manager knew. His boss had no idea. When I finally sat down with the skip-level boss, he was learning about my goals for the first time. My manager had been quietly pushing me toward a principal IC promotion instead, because that kept me on his team. I was not angry. He was doing his job. But I had been relying on one person to carry my goals into rooms I never entered. That person had good reasons not to. ## Building Career Visibility at the Skip-Level This is not about going around your manager or creating awkward political dynamics. It is about understanding that promotion decisions are multi-stakeholder events and choosing to show up accordingly. Have a direct conversation with your skip-level. You do not need a performance crisis or a formal agenda to request 30 minutes with your manager's boss. Most skip-level leaders are glad to connect with high performers two levels down. Keep it simple: you want to share where you are heading and hear their perspective on the team's direction. Say something direct: "I have been building toward a leadership role and I wanted to make sure you had a sense of where I am headed." That one sentence gives them context they can carry into future conversations. Build visibility through cross-functional work. Every project that touches another department is a chance to be known by leaders who are not your manager. The skip-level boss's peers, the leaders of adjacent teams, and senior stakeholders who see you operate in collaborative settings become informal references. You do not have to perform. You have to show up and do good work in rooms where your manager is not the only person watching. State your goals plainly when a senior leader asks. When a skip-level leader or senior stakeholder asks what you are working on or where you see yourself going, answer directly. "I am interested in moving into a management role over the next year or two" is not a demand. It is information. Leaders who think you are ready will do something with it. Consider a [skip-level meeting](https://www.fastcompany.com/90777051/what-is-a-skip-level-meeting-and-why-its-key-to-building-your-career) a career tool, not just an organizational ritual. Many companies have skip-level conversations as a standard practice. If yours does, use them intentionally. Come with more than a status update. Share where you want to grow. Ask about what the organization needs from future leaders. These conversations create impressions that outlast the meeting. ## One Conversation Most Leaders Never Have There is a specific conversation that almost no one thinks to have: sitting down with a senior leader and saying plainly, "I want to move into a leadership role. I wanted you to know that, and I wanted to hear your perspective on what that path looks like here." That conversation feels awkward because it is direct. But directness is exactly what makes it work. You are giving a decision-maker specific information they can act on. You are making it easy for them to carry your name into the right discussions. You are removing the ambiguity about whether you are ready or whether you want it. Your manager already knows. Now make sure the right people know too. ## The Action Next Monday Write down the names of the people above your manager who have any say in your career advancement. Their boss. Their peers. The skip-level leader. Now ask yourself: how many of them know that you want to lead? If the number is less than two, that is the gap. One conversation this week is enough to start. Ask your manager's boss for 30 minutes, come with something direct to share, and let the conversation begin. The people making decisions about your future cannot advocate for you if they do not know what you want. Who in your organization, above your direct manager, knows exactly what you want from your career? You're great at the work. Let's make you impossible to ignore. If you are looking for help building visibility in your organization and advancing your career intentionally, consider reaching out. jessestaffordcoaching.comhttps://jessestaffordcoaching.com/blog/being-too-good-job-blocks-promotionhttps://jessestaffordcoaching.com/blog/being-too-good-job-blocks-promotionMost high performers believe the path to promotion looks like this: work harder, master your role completely, become the person no one can do without....Thu, 11 Jun 2026 00:00:00 GMTMost high performers believe the path to promotion looks like this: work harder, master your role completely, become the person no one can do without. That last part is where the career stalls. Being the person no one can do without is not a career asset. It is a ceiling. ## The Technical Leader Promotion Blocker Nobody Tells You About Promotion decisions are organizational decisions, not performance decisions. The question an organization asks before moving someone up is not "Is this person good enough?" The question is: "Can we afford to lose them where they are?" If the honest answer is no, the promotion does not happen. Not because the person is not ready. Because the organization is not. This distinction matters. Most high performers who get passed over for promotion spend years thinking the problem is their performance, their visibility, or their political capital. They work on the wrong problem. The actual blocker is structural. When you are the only person who knows how a critical system works, or the only person holding a key relationship, or the only person who can make a specific call, you have created a dependency problem for your organization. They cannot move you up without creating an operational risk. So they wait. And while they wait, you stop moving. A client I worked with had been in her role for three years. Her performance reviews were exceptional. Her manager had mentioned twice that she was ready for the next level. Then the role she had been building toward opened. She applied. She did not get it. The explanation, when it finally came: "We can't move you right now. There's no one who can do what you do." She thought that was a compliment. It was not. It was the reason she did not get the job. The trap is not about performance. It is about dependency. If you are irreplaceable to your team, you are also not promotable. ## What "Irreplaceable" Actually Means for Your Career Irreplaceable sounds like a compliment. In practice, it functions like a lock. Organizations operate on risk tolerance. When they consider moving a high performer into a new role, they are also calculating the cost of the gap that person leaves behind. A replacement who is 80% as effective creates a real operational risk. If that gap is in a customer-facing system, a key account, or a foundational process, the cost is not theoretical. This is not bad management. It is how systems work. Organizations need stability more than they need to develop any individual person. That is the honest version of how these decisions get made. Here is what the data confirms: according to a CareerBuilder survey, more than 43% of companies say they hire externally more often than they develop internal successors. That means the majority of organizations are not running active succession pipelines for most roles. If no one is developing your replacement, it is not because they forgot. It is because the business cost of your absence has not been solved yet. The [Pragmatic Engineer newsletter](https://newsletter.pragmaticengineer.com/p/ways-staff-engineers-get-stuck) has documented the same pattern at the Staff and Principal Engineer level: engineers who have built institutional knowledge and deep system ownership are frequently stuck not because they lack leadership skills, but because the organization cannot figure out how to safely move them. ## The Succession Planning Gap Most Technical Leaders Ignore The conventional advice for promotion is to build relationships, increase visibility, and signal readiness. All of that is correct. None of it addresses the actual constraint. The constraint is: who does your job when you leave? Most technical leaders do not have an answer to that question. Not because the answer does not matter, but because nobody ever told them it was their job to create one. This is the succession planning gap. Organizations assume succession planning is something leaders do for their teams. It is also something individuals need to do for themselves, inside their own role, before the organization will let them move. Harvard Business Review noted in [a January 2026 piece](https://hbr.org/2026/01/when-theres-nowhere-to-promote-a-star-employee) that even organizations that want to promote star performers often get blocked by an inability to transition that person out of their current role without significant disruption. The person's talent becomes the organization's bottleneck. The result: high performers wait for a promotion conversation that the organization keeps deferring, while the organization waits for a replacement plan that the individual never created. ## How to Build Your Way Out of the Irreplaceability Trap The move is counterintuitive. You have to make yourself replaceable in your current role before you can become promotable to the next one. Here is what that looks like in practice. Document the knowledge that only lives with you. Run a simple audit: if you were out for two weeks with no access to email, what would stop or slow down? Write the list. Each item on it is a knowledge transfer that needs to happen before you can be moved. This is your actual development roadmap as a leader. Teach what you do while you do it. The most common version of this I see is "I will document this when things slow down." Things do not slow down. The window for transferring knowledge is while the work is live. Every process you run, every decision you make: someone should be learning it alongside you right now. Move your team's relationships out of your calendar. If you are the relationship hub between your team and the rest of the organization, that is a single point of failure. Start putting team members in rooms where those relationships get built. Introduce them to your counterparts. Bring someone along to the meeting you would normally handle alone. When you leave this role, those relationships should belong to the team, not to you personally. Stop being the first answer. When someone brings you a question, the fastest path to building their capacity is to ask: who on this team should own this kind of question? Then involve that person. You answer it together. Then they answer it and you observe. Then they own it. None of this is about working less. It is about redirecting a portion of your expertise from doing to teaching. The return on that investment is the next level of your career. ## The Question Nobody Asks Until It Is Too Late Most leaders wait for a promotion conversation before they start thinking about succession. By then, the organization has already made its calculation. The gap is too visible, the risk is too real, and the conversation gets deferred. The better path is to make the succession problem disappear before it becomes the reason you cannot move. The leaders who advance fastest are not the ones with the most institutional knowledge. They are the ones whose absence would create the least disruption, because they spent years making sure their expertise lived in the team, not just in their heads. This week, write down three things that would stop or slow down if you were not there for two weeks. Pick one. Have one conversation with the person on your team closest to being able to own it, and explain what you do and why you do it that way. That is the work. It is also the beginning of your next promotion. Are you stuck in a role you have mastered, watching others move up while your organization tells you they cannot lose you? Tell me what that looks like in the comments. You're great at the work. Let's make you impossible to ignore. If you are looking for help figuring out what is actually blocking your next promotion, consider reaching out. https://www.jessestaffordcoaching.comhttps://jessestaffordcoaching.com/blog/give-trust-freely-teams-productivity-dependshttps://jessestaffordcoaching.com/blog/give-trust-freely-teams-productivity-dependsMost teams operate on a trust-as-currency model. You watch.Thu, 11 Jun 2026 00:00:00 GMT## The True Cost of "Earned Trust" Most teams operate on a trust-as-currency model. You watch. You wait. You see if people follow through on small things first. Gradually, over months, you give them more responsibility. It feels safe. You are not surprised. People have to prove themselves first. The cost is invisible until you see it. When people feel they are not trusted yet, everything slows down. They ask permission instead of taking initiative. They do not bring you early-stage problems because they assume it will hurt their standing. They wait for instructions instead of making decisions. Feedback stays bottled up. Skip-level meetings fall apart because no one trusts that raising a concern will not damage their relationship with their direct manager. The people you hired to think independently start asking "is this okay?" for decisions they should own. And here is the irony: when you eventually do grant them trust, it does not feel like trust. It feels like a reward they had to earn. So when they eventually fail, it feels like betrayal from both sides. ## Why This Model Persists (Even When It Costs Money) The earned-trust model persists because it feels protective. If you wait to see performance before trusting, you cannot be surprised. You are in control. But control is not the same as leadership. Korn Ferry research found that 22% of organizational financial performance is directly tied to trust in senior leadership. High-trust companies show 50% more productivity, 106% more energy, and 76% more engagement from their teams. That is not correlation. That is causation. Trust is not nice. It is business. - Yet we keep running teams as if trust is something people have to earn through months of observation. And then we wonder why: - Burnout is epidemic among leaders (who are managing everyone as if they cannot be trusted) - Technical talent leaves (they get tired of being monitored) - Initiatives take twice as long (because people are waiting for permission) - Skip-level concerns explode (because the direct report is afraid to bring problems to their manager) The model was never about safety. It was about the leader's fear. ## The Inversion: What Happens When You Give Trust First What if you flipped it? What if the starting position was trust? Not blind trust. Not trust in every dimension. Just a baseline assumption that people are capable and well-intentioned. Then, when specific behaviors do not align, you withdraw trust in that specific area. You do not withdraw trust from the person. You redirect the behavior. This changes everything. When I gave my direct report information early, I was saying: I trust you with this information. I trust that you can handle uncertainty. I trust that you want the team to succeed. What I was managing was the specific behavior of how they communicated that uncertainty to others. I did that management by changing when and how they got the information. Not by shutting them out. Not by treating them as untrustworthy. By giving them a structure that helped them succeed. It sounds backwards. But the outcomes are different immediately. People step into ownership. They bring you problems earlier because you already showed them you will not shoot the messenger. They are honest in your 1-on-1s because they are not defending a position. They are sharing a reality. ## The Mechanics: How Trust Actually Works at Scale Trust is not all-or-nothing. It is granular. You can trust someone with technical decisions while you are still building trust in their customer communication. You can trust their project ownership while you are developing their hiring judgment. This is where most leaders get it wrong. They think trust is a single currency. It is not. Start by being explicit about what you are actually trusting them with. Say it out loud. Not "I trust you" in the abstract. Specific: "I trust you to make technical decisions on this project. I trust you to own the customer relationship. I trust you to escalate blockers when you see them." Then, when a behavior shows that withdrawal is needed, name the behavior, not the person. Do not say: "I can't trust you with this." Instead: "This situation requires a different approach than what you chose. Here is what I need to see going forward." One attacks their judgment. The other redirects their action. Both create accountability. Only one makes people want to keep trying. ## The Information Gap: Why Sharing Early Matters More Than You Think Teams that operate on high trust share information earlier. Not after official announcements. Not after decisions are locked. Before. This solves a problem you do not see until you fix it: the information gap between what you know and what your team knows creates three separate realities. In your reality, you are thinking through a decision. In your team's reality, you disappeared into meetings and came back with conclusions that feel arbitrary. And in your skip-level's reality, your direct report is scrambling to interpret what is happening. When you share early, you collapse those gaps. Your team sees the thinking. Not the finished answer. The actual thinking. Do this with skip-level meetings. Bring them context before it is official. Share the problem you are trying to solve. Share what you are uncertain about. Let them process it while you are there. If they overreact in private, that is processing. That is healthy. That is what trust looks like in action. ## What This Unlocks Here is what happens when you operate this way. People take more ownership. They are not waiting for permission that feels like it is never coming. They escalate problems earlier. They make decisions they should be making. They bring you early-stage thinking instead of waiting until it is polished or broken. Feedback stops getting bottled up. Skip-level conversations become real. People tell you what is actually happening instead of what they think you want to hear. And when you do need to hold someone accountable, it does not feel like betrayal. It feels like a course correction. Because the trust was real. You gave it. You are just redirecting where behavior needs to shift. This is the difference between a team that works for you and a team that works with you. ## The Monday Action Identify one person on your team you have been cautious about. One specific area where you could give them more trust. Not their whole role. One piece. Share that explicitly with them this week: "I want to give you more trust with X. This is important to us. I am going to start including you in earlier conversations so you have full context." Then let them prove what you already believe. ## One More Thing The leaders who struggle most with this are the ones running scared. They have been burned before. They have managed someone who broke their trust. And now they carry that story into every relationship. But that is the trap. One person's failure does not mean everyone is broken. And treating everyone like they might break your trust is what actually breaks teams. Give trust. Withdraw it specifically when needed. But give it. ## Your Turn Think about the last person who gave you trust before you had to earn it. How did that change how you showed up? You're great at the work. Let's make you impossible to ignore. If you are looking for help building a team culture where people step into trust rather than waiting for permission, consider reaching out. jessestaffordcoaching.comhttps://jessestaffordcoaching.com/blog/i-did-all-visibility-work-myhttps://jessestaffordcoaching.com/blog/i-did-all-visibility-work-myYou have probably seen it happen to someone else's team. A strong manager moves on: promotion, transfer, departure.Wed, 03 Jun 2026 00:00:00 GMTYou have probably seen it happen to someone else's team. A strong manager moves on: promotion, transfer, departure. The team was performing well. Visibility was good. Projects were prioritized. And then, slowly, they lose ground. Resources thin out. Projects drift down the priority list. Career conversations become harder to navigate. The team is still doing good work. They just seem to have become... less visible. It can take months before anyone names what actually happened. The team did not lose capability. They lost the person who had been translating their capability into language the rest of the organization could see. That is not a people problem. It is a structural one. And the leader who moved on built it. ## Why Technical Leaders Create Invisible Teams There is a specific failure mode that shows up in high-performing technical managers, and it almost always starts as a strength. You become a manager and discover that good output is not enough. The work needs advocates. The relationships need to be built. Decision-makers need to understand what your team is doing before they have to decide whether to fund it or prioritize it. And because you already know how to do that translation work, you have been navigating organizational dynamics for years, you do it yourself. The team produces. You make sure the right people notice the production. This works. It works well. Your team gains visibility, gets prioritized, and performs. The problem is that you are now the only link between your team's work and the organization's awareness of it. Your team has never had to build that link themselves. They have never been in the stakeholder meetings. They have never seen how you frame their work in a room where technical language does not land. They have never learned which relationships matter or why. Gallup's State of the Global Workplace research consistently finds that managers account for up to 70% of the variance in team engagement. What that usually means in practice: the leader is holding more of the team's success than the team itself is. That is not sustainable. ## The Technical Visibility Gap That Stalls Teams After Leader Transitions When a leader who has been carrying the team's visibility work moves on, two things usually happen. First, the team does not immediately notice anything has changed. They are still doing the work. They are still shipping. Day-to-day operations look the same. Second, the organizational awareness starts to decay. Nobody is taking the stakeholder meetings anymore. Nobody is translating outcomes into business language for the people who control priorities. Nobody is maintaining the relationships that got the team resourced. By the time the team realizes something is wrong, they are already several months behind. The visibility gap does not announce itself. It builds quietly. This is what I did to my first team. I had a small team that produced real value and had real visibility inside the company. I did the relationship-building, the internal marketing, the stakeholder meetings. I made sure the right people knew what we were shipping and why it mattered. And I never brought my team into any of it. When I got promoted, all of that stopped. My schedule no longer had room for it. Nobody picked it up. Nobody even knew it needed to be picked up. And the team spent years in what I can only describe as mild obscurity, while I worked to rebuild a culture where visibility was the team's job, not just mine. If you are irreplaceable to your team, you are also not promotable. That is true. But the harder version of that insight is this: if you are irreplaceable to your team, you have also made them dependent on you in a way that will outlast you. ## How Engineering Managers Can Rebuild Team Visibility Skills The goal is not to step back from stakeholder work. You still take those meetings. The shift is that you stop taking them alone, and you stop keeping what you learn to yourself. Bring someone into the room. Pick a team member and take them into a meeting where they would normally never go. A stakeholder review, a cross-team planning session, a conversation with a leader whose priorities shape your team's work. Let them see the room. Let them watch how those conversations actually work and what questions come up. The goal is not to have them perform. The goal is to make organizational dynamics visible. Debrief what you learned. After every significant stakeholder conversation, give your team a brief version of what happened. What did you tell them? What did they care about? What are they still worried about? You do not need to share everything. But you should share enough that your team has some sense of the landscape their work lives in. Name work in outcomes. Once a week, in team meetings or your regular update channel, name what shipped and what it means for the business, not just what got done. Not "we closed 14 tickets." More like: "We shipped the new API integration, which means the compliance team can run audit reports in two minutes instead of two hours." Then ask your team to bring that language to the next update. Teach the translation, not just the output. Make the introductions. If you have a peer leader, a business partner, or a stakeholder who matters to your team's priorities, introduce your team to that person explicitly. Not in passing, genuinely: "This is \[name\], they own \[area\], you should know each other." That is how you transfer relational equity instead of hoarding it. ## The Visibility Dependency Audit: Is Your Team Ready to Succeed Without You? If you left your role tomorrow, what would your team lose? Not in terms of technical skills. In terms of organizational capability, the ability to translate their work for decision-makers, maintain the relationships that shape their priorities, and make their success visible to the people who determine what they get to work on next. Run through these questions: Who would take the stakeholder meetings? If you can name someone specific who could step in and run those conversations effectively, good. If the answer is "nobody" or "I would have to set that up first," you have a dependency. Can your team explain what they are building in terms a non-technical executive could understand? Not just once, under pressure. Can they do it naturally, as a habit? If this language only comes from you, you have a dependency. Does your team have relationships with the right peers and cross-functional partners? Or do those relationships exist only in your name, meaning you are the node that everything routes through? Would your team know what to prioritize if you were not there to set the agenda? This is less about tactical decisions and more about organizational awareness. Do they understand the context well enough to make judgment calls without you? If you answered "no" or "I am not sure" to most of these, the work is clear: you need to start transferring visibility skills, not just delegating tasks. One thing to do this week: identify one visibility task you have been carrying alone. One meeting you always take solo. One relationship that exists in your name only. Start building a path to share it, either by bringing someone with you, debriefing afterward, or making an introduction. That is the first step toward a team that does not need you to carry its visibility. **Are there things you have been doing for your team that they would not know how to do without you?** You're great at the work. Let's make you impossible to ignore. If you are looking for help building a team that can advocate for itself and continue to grow when you move on, consider reaching out. jessestaffordcoaching.comhttps://jessestaffordcoaching.com/blog/introverted-leaders-build-charisma-without-fakinghttps://jessestaffordcoaching.com/blog/introverted-leaders-build-charisma-without-fakingMost introverted leaders have the same experience at some point in their career. They walk out of a high-stakes meeting and think: that was not me.Wed, 03 Jun 2026 00:00:00 GMT## The Problem Nobody Names Most introverted leaders have the same experience at some point in their career. They walk out of a high-stakes meeting and think: that was not me. The energy, the presence, the way I held the room. That felt like a performance. Something I put on. And then the guilt sets in. They feel like they were faking it. Here is the thing: they were not faking it. They were doing exactly what every effective leader does. They were choosing how to show up. The problem is nobody told them that was normal. And allowed. Most advice for introverted leaders falls into two categories. Either "lean into your strengths as an introvert" (translation: accept that presence will always cost you more) or "push past your comfort zone" (translation: force yourself to be more extroverted until it sticks). Both miss the actual mechanism. Charisma is a skill. Not a personality type. Not a natural gift. A learnable, practicable skill that improves with repetition and declines without it. That changes everything about how introverted leaders should think about presence. ## What Charisma Actually Is Researchers who study charisma have converged on a consistent finding: the qualities associated with it are behaviors, not traits. Specifically: expressiveness, energy projection, active listening, and controlled vulnerability. All of those are observable behaviors. None of them are fixed. This matters because most introverted leaders who struggle with presence think they are missing something they were never given. They are not. They just have not practiced specific behaviors as long as people who are naturally more extroverted have. The extroverted colleague who seems effortlessly charismatic in every meeting? They have been practicing those behaviors, usually without thinking about it, since they were children. The social situations that drained the introvert were practice reps for the extrovert. That is not a personality advantage. That is a head start. When introverted leaders treat presence as a skill instead of a trait, the head start becomes catchable. Not overnight. But systematically. ## The Authenticity Confusion The reason introverted leaders feel like frauds when they perform well is not because they are being inauthentic. It is because they have confused authenticity with natural comfort. Authenticity does not mean doing only what feels comfortable in the moment. That definition would make almost all skill development inauthentic. A more useful definition: authenticity is about showing up as the version of yourself you have chosen to be. Not hiding who you are. Choosing who you are becoming. Consider this. If you are an introvert who has spent two years practicing energetic presence in meetings, and you walk out of a meeting feeling like your energy landed well, that is not a performance you should feel guilty about. That is a skill you built. It is you. The version you are becoming does not replace the version you started with. It adds to it. You are still the person who needs quiet time to recharge. You are also the person who can hold a room when it matters. Both are true. Both are you. ## Why This Problem Is Getting Worse Remote and hybrid work has made this harder for introverted leaders. In fully in-person environments, introverted leaders built presence over time through repeated low-stakes interactions. The hallway conversation. The coffee before the meeting. The lunch with a new team member. These informal moments accumulated into perception. People got to know you over time, across a variety of settings. In hybrid environments, presence is more concentrated. You have fewer moments and they carry more weight. The flat energy on a video call is more visible than it would have been in passing in the hallway. Introverted leaders who are not deliberately building presence skills are falling behind. Not because of their introversion. Because the environment changed and reduced the informal practice reps they relied on. The answer is the same in either environment: treat charisma as a skill and practice it deliberately. The urgency is just higher now. ## A Framework for Building It Here is the framework I have used personally and have worked through with dozens of leaders since. ! ### Step 1: Define the version of yourself you are choosing to be Not the version your manager wants. Not the version you think "executive presence" looks like. The version you actually want people to experience when you walk into a room. Write it down in three words or three short phrases. Mine were: forthright, not boring to listen to, someone who does not hide what they know. Vague intentions produce nothing. "More charismatic" is not a target. "The person in the room who tells people what he actually thinks before they ask" is a target. Get specific enough that you could describe it to someone else in 30 seconds. ### Step 2: Choose one behavior to practice first Three targets at once will produce zero progress. One behavior, practiced with intention over four to six weeks, produces a habit. Choose whatever is most visible and most relevant to your current role. If you are preparing for a promotion, pick something that matters in the room you are trying to get into. Not the room you are already comfortable in. ### Step 3: Learn the behavior from others before you practice it yourself This is the step most leaders skip. They decide they want to be better at something, then try to do it without studying what it looks like at a high level of skill. Watch people who are excellent at the specific behavior you want to build. Not to copy them. To understand the mechanics. What exactly are they doing? Not the impression. The behavior. Are they making eye contact longer before speaking? Are they slowing down before key points? Are they asking questions that assume the other person has valuable things to say? Find the behavior underneath the impression. Then you have something to practice. ### Step 4: Practice in low-stakes environments first Nobody goes on stage without rehearsal. No one sits down at a piano and plays a difficult piece on the first try. Leadership presence gets practiced in smaller, lower-stakes settings before high-stakes ones. A one-on-one conversation with someone you trust. A smaller team meeting before the executive review. A department update before the all-hands. Build the skill where you can afford to be imperfect. Then bring the improved version to the rooms that matter. I practiced telling better stories with people I knew. People who would not judge me if I stumbled. I practiced being energetic in smaller meetings before large all-hands. I built the skill in places where I had room to mess up. This is not about overnight transformation. This is about incremental practice. Like learning any skill. ### Step 5: Protect your introvert energy while you build This is what most frameworks for introverted leaders miss: the energy cost. Practicing presence is more draining for introverts than for extroverts. This is real. It means you need to build recovery time into your schedule, especially when you are in high-practice periods. I protect at least one hour of quiet per day. On days with back-to-back meetings, I add 30 minutes after the last one before I move on to anything else. This is not weakness. This is resource management. You would not run a marathon without training. You would not train without rest days. Build the skill. Protect the recovery. Both are required. ## What Gets in the Way The most common reason introverted leaders do not build presence deliberately is that they have accepted a story about themselves. The story is: "I am just an introvert. This is how I am." The story is not wrong. You are an introvert. You will always need more recovery time than extroverts. Groups will always cost you something. But "I am an introvert" does not explain why presence is limited. It explains why presence costs energy. Those are two different things. You can be an introvert who leads with presence. The leaders who figure this out stop waiting to feel naturally charismatic and start practicing until it becomes natural. The feeling you are waiting for comes after the practice. Not before it. ## What Actually Happened When I Practiced This I started paying attention to how I presented myself. I worked on becoming a better storyteller. When I talk about something I care about, I present myself as energetic and excited about the topic. This is true even when I do not feel energized in the moment. That is not fake. That is intentional. At first, I could only hold that mode for short bursts. It drained me. But the more I put myself in that situation, the easier it got. The bursts got longer. What took significant energy now takes half as much effort. To the point where I mostly stopped telling people I am introverted. They do not believe me anymore. That is not a personality change. That is a skill at a high level of development. ## The Monday Move This week, write down one specific behavior you want people to notice when you show up to lead. Not "be more confident." Something you could point to if you watched yourself on video. Something specific enough that you could say "I either did this or I did not." Then find one person who does that thing well. Watch them do it. Notice the specific behavior underneath the impression. That is it for week one. Identify the behavior. Find a model. Study the mechanics. Start there. What is one leadership behavior you have been treating as a trait when it might actually be a skill? You are great at the work. Let's make you impossible to ignore. If you are looking for support building intentional leadership presence, consider reaching out: https://www.jessestaffordcoaching.com/lets-talkhttps://jessestaffordcoaching.com/blog/job-changes-tells-director-level-problemhttps://jessestaffordcoaching.com/blog/job-changes-tells-director-level-problemThere is a moment most new directors remember but rarely name. You are handling more than you ever have.Wed, 03 Jun 2026 00:00:00 GMTThere is a moment most new directors remember but rarely name. You are handling more than you ever have. Decisions keep coming. Problems keep arriving. You keep solving them, because solving is what you are good at, and you are still being told you are doing well. Then something starts to feel off. Your managers are not growing. Decisions that should take a day take a week. Your calendar fills with problems that should have been solved without you. You are not failing. You are doing the wrong job. ## Why Technical Leader Promotions Stop Working Research on leadership transitions confirms what many senior leaders feel but cannot articulate. Moving from manager to director is not just a skills upgrade. It is a role identity change. A peer-reviewed framework published in the Journal of Management titled ["From Individual Contributor to Leader: A Role Identity Shift Framework for Leader Development Within Innovative Organizations"](https://journals.sagepub.com/doi/abs/10.1177/0149206315614372?journalCode=joma) found that leadership transitions require individuals to change not just their skills but their self-identity and their understanding of what leadership means. The skills that made someone excellent at the previous level are often the same ones that stall progress at the next one. For technical leaders, the problem is sharper. Engineers and technical managers are trained, rewarded, and promoted specifically for their ability to solve problems quickly and accurately. That signal does not stop when they make director. Nobody hands them a new job description on day one. They keep doing what worked, because it still feels like the job. The MIT Sloan Management Review has documented this pattern in research on [why managers struggle to delegate](https://sloanreview.mit.edu/video/why-managers-struggle-to-delegate/). Many leaders believe removing obstacles requires them to do the work themselves. The real job is to describe what is blocking and get the right person to solve it. Nobody gets that memo clearly enough. Most directors learn it the hard way. ## The Problem-Solver Trap at Director Level Here is what the trap actually looks like in practice. A problem lands on your desk. You understand it immediately. You know the answer, or you can figure it out faster than anyone else in the room. So you solve it. You hand back the answer. Your manager implements. Problem gone. This pattern works. Until it does not. When you keep solving, you become the answer key. Your managers stop developing judgment because every problem routes to you. Decisions that should take a day take a week because nothing moves until you weigh in. You are exhausted doing work that should belong to someone else, while your actual director-level work goes undone. The deeper problem: your team is not learning. Every time you hand back an answer, you remove the situation where they would have had to think it through. Over time, you have built a team that stops when you do. That is not a delegation problem. It is a role definition problem. At director level, your value is not in solving. It is in describing problems clearly enough that the right person can solve them. ## What Problem Description Actually Means at Director Level Describing a problem is not the same as solving a watered-down version of it. It is active, precise work. Here is what it looks like when a director is doing it correctly: Naming what you see before you say anything else. Before you respond to a problem someone brings you, write out what you observe: "Here is the situation as I see it. Here is what is at stake. Here is what I do not know yet." Most problems feel large until they are on paper. The act of writing separates the real issue from the noise around it. Naming who owns the problem before you touch it. "This is yours to solve. Tell me what you see before we decide anything." You may have a strong view. That view is not the point at this stage. The point is whose judgment gets built through this problem. Asking your managers to describe the problem before you respond. "Walk me through what you see." Not because you do not have a view. Because if they cannot describe the problem, they cannot solve it. Their description tells you exactly where they are stuck. That is where your help actually belongs. The test that tells you whether you are operating at director level: if you can describe a problem clearly enough that someone else could act on it without you in the room, you have done director work. If they still need you to solve it, you have not. ## What Director-Level Problem Description Looks Like in Real Conversations This section does not appear in the Medium version of this post. It is a direct companion for people who want to see the shift in the actual words. When a manager brings you a conflict between two teams: Solver response: "Here is how I would handle it. Tell Team A to take X approach. Get Team B to back off on Y. Schedule a meeting and resolve it by Friday." Director response: "Tell me what you see as the core issue. Not the symptoms. What is actually broken?" \[Let them describe it.\] "Here is what I see that you might be missing: both teams are actually optimizing for different metrics. Who do you think needs to own aligning those metrics?" \[Let them answer.\] "I agree. What is your first move?" The difference: in the solver response, the manager walks away with an answer. In the director response, the manager walks away having named the real problem and their own first step. Next time, they do not need you. When your skip-level brings you a problem your direct manager should have handled: Solver response: Take the problem, solve it, loop your manager in after. Director response: "What did \[your manager\] say when you brought this to them?" \[If the skip-level skipped that step\]: "That is a conversation you need to have with them first. Here is the problem as I understand it so you can go in with a clear description." \[You describe it, so they can use that description in the conversation with your manager.\] This is description as a leadership tool. You are not solving the problem. You are naming it clearly enough that the right conversation can happen. When a peer leader brings you something that crosses your org: Solver response: "Let me take a look at my team's side and get back to you." Director response: "Walk me through what you see as the problem from your side. I want to understand the situation before I dig into ours." \[After they describe it:\] "Here is what I see from our side. Here is where I think the real gap is. Who in both our orgs should own solving this?" Each of these responses sounds like you are doing less. You are actually doing more. You are doing the work that only a director can do. ## Why This Shift Is Harder Than It Looks The problem-solver instinct is not just a habit. It is tied to identity. For most technical leaders, being the fastest, clearest, most reliable problem-solver is how they built their career. That identity does not disappear when they get promoted. It has to be deliberately replaced by a different understanding of what value means. [The Thoughtful Leader](https://www.thoughtfulleader.com/why-leaders-dont-delegate/) documents this pattern in research on why managers struggle to delegate: leaders who fear losing control or who believe "my way is better" stay in solving mode long after the role has moved on. The belief that drives the behavior is: solving is how I add value. The belief that replaces it at director level is: describing is how I add value. The transition requires naming that shift explicitly, not just trying to delegate more tasks. You are not becoming a worse problem-solver. You are becoming someone who makes the organization better at solving problems without you. ## Monday Action Pick one problem on your desk right now that you already know the answer to. Do not answer it. Write down what you see as the problem in two sentences. Then bring your manager that description and ask: "How do you see this?" Then ask: "Who do you think should own the solution?" That is one full director-level rep. Do one this week. Notice what your manager does next time a similar problem comes up. When was the last time you described a problem instead of solving it? What changed in how your team responded? You're great at the work. Let's make you impossible to ignore. If you are looking for support making the shift from solver to director-level describer, consider reaching out. jessestaffordcoaching.comhttps://jessestaffordcoaching.com/blog/burnout-keeps-coming-back-after-timehttps://jessestaffordcoaching.com/blog/burnout-keeps-coming-back-after-timeQui ck Bridge: If you have taken time off and returned to the same burnout within weeks, you are not broken and the break did not fail. The problem is...Sat, 30 May 2026 00:00:00 GMTQui ck Bridge: If you have taken time off and returned to the same burnout within weeks, you are not broken and the break did not fail. The problem is structural, not personal. This post explains what actually drives the burnout cycle for leaders, what Gallup's latest workplace data shows about where the real drain comes from, and four moves you can make this week to stop repeating the pattern. Most conversations about burnout start in the wrong place. They start with how much you are working. How many hours you are logging. Whether you took enough time off. These are real questions. But they treat the symptom as if it were the cause. Leaders who burn out and then rest and then burn out again are not bad at recovering. They are returning to an unchanged system. The system is the problem. The rest is just a pause button. ## The Manager Burnout Recovery Pattern That Keeps Failing The standard burnout recovery advice goes like this: disconnect, rest, recover, come back restored. And most leaders follow it. They take the trip. They put the out-of-office on. They genuinely try to decompress. Then they come back. Within two to four weeks, most of them feel the same exhaustion they left with. The same low-grade dread at the start of every week. The same sensation of being behind before the day starts. The reaction is predictable: the break did not work. They did not rest enough. They need to get better at disconnecting. None of that is right. The break worked. The body recovered. The sleep improved. What did not change was the meeting load, the backlog of low-priority requests, the structural drain that had been quietly pulling from them for months. That was all waiting when they came back. Recovery advice focuses almost entirely on the depleted person. Structural advice focuses on the system the person operates inside. Most leaders get a lot of the first and almost none of the second. That is why the cycle repeats. ## What Engineering Burnout Actually Comes From Here is the part that changes the whole conversation. Burnout is not purely a volume problem. Hours matter, but they are not the root cause for most leaders. I have known people carrying 55-hour weeks who were not burned out. I have known people at 40 hours who were in complete collapse. The deeper driver is a missing sense of productivity and accomplishment. When the work you do every day does not connect to any forward movement you can see or feel, you drain faster than rest can refill. The exhaustion is not physical. It is the specific weight of sustained effort that disappears without landing anywhere. This is backed up by what we know about engagement. Gallup's 2025 State of the Global Workplace report found that global employee engagement has fallen to 21 percent, with managers experiencing the steepest decline of any group. The estimated cost of that disengagement: $438 billion in lost productivity annually. ([Gallup 2025 State of the Global Workplace](https://www.gallup.com/topic/employee-wellbeing.aspx)) The engagement crisis is not primarily a hours problem. It is an accomplishment and meaning problem. When leaders report burnout, they are not usually saying "I worked too many hours." They are saying "I spent enormous energy and have nothing to show for it." Those are different problems with different solutions. A sabbatical addresses the first. Only structural change addresses the second. ## How to Rebuild a Work Structure That Stops Draining You Structural change does not require a job change or a negotiated reduction in responsibilities. It requires an honest look at where your energy actually goes and whether the output justifies it. Three moves that reliably shift things: Audit the drains before you touch anything else. Take one hour this week and map every meeting, recurring obligation, and open-ended commitment from the past two weeks. Next to each one, write one word: productive or occupied. Productive means you came out of it with something. A decision made, a problem solved, progress you can point to. Occupied means you spent time and energy and came out even or behind. Do not start canceling things yet. The map comes first. Most leaders who try to cut meetings without the map end up cutting the wrong ones. The audit tells you what is actually happening versus what you assume is happening. Give yourself one completable thing per week. Not your biggest initiative. Not the most visible project. Something you can actually finish. A report that has been sitting half-done. A conversation you have been putting off. A decision you made weeks ago that you never communicated. The reason this matters is neurological, not motivational. Finishing things resets the brain's sense of capacity and momentum. Leaders who are deep in the burnout cycle often stop finishing things because everything feels too large to close. That feeling feeds on itself. One closed loop breaks it. It does not solve everything, but it restores the sense that forward movement is possible. Identify one category of low-impact work and step back from it. One category. Not everything at once. For some leaders it is recurring status meetings where no decisions get made. For others it is answering questions that the asker could solve themselves with thirty seconds of effort. For others it is email threads where responding became an expectation without anyone explicitly asking. Pick one category. Find one legitimate way out of it. Decline the next invite, set a response boundary, or ask whether your presence is actually required. Energy spent on low-impact work is energy you do not have for the work that makes you feel effective. Removing one drain creates room. ## What Your First Two Weeks Back Actually Tell You Most leaders treat the return from time off as a fresh start. They come back with good intentions, cleared inboxes, and a plan to do things differently. By week two, they know whether the structure changed or not. If you came back from time off and already feel the familiar weight again, that two-week window is data. It is telling you something specific about your work structure that rest alone will not fix. Pay attention to which meetings drain you first. Notice which obligations refill within days of being cleared. Watch where your sense of progress disappears fastest. The two-week return is the clearest diagnostic window you have. Most leaders miss it because they are trying to get back up to speed. But if you slow down and observe it, it will show you exactly where the structural problem lives. Ask yourself three questions at the end of week two: What did I spend the most energy on that I have nothing to show for? What did I say yes to out of habit rather than judgment? What one thing, if removed, would make the next month feel different? You do not need to act on all three answers immediately. Writing them down honestly is enough to start. The answers are usually not surprising. They are just things you have been avoiding. Leaders who rebuild from burnout do not rebuild all at once. They find the highest-leverage drain, remove it, notice what changes, and move to the next. It is slow. It is also the only thing that actually works long-term. ## This Week You do not need to overhaul your calendar. Look at the last two weeks. Find the one commitment that cost you the most energy and produced the least. Just one. Then figure out how to step back from it this week. Cancel it, decline the next occurrence, or ask out loud whether your presence is actually required. One structural change. That is enough to start. When you have come back from time off and hit the same wall, what did you change that actually made a difference? You're great at the work. Let's make you impossible to ignore. If you are looking for help rebuilding a work structure that actually sustains you, consider reaching out. https://www.jessestaffordcoaching.comhttps://jessestaffordcoaching.com/blog/yourself-worst-career-advice-leadershttps://jessestaffordcoaching.com/blog/yourself-worst-career-advice-leadersThe Advice Every Leader Gets Wrong Organizations love the phrase "bring your whole self to work." It shows up in culture decks, leadership development...Sat, 30 May 2026 00:00:00 GMTThe Advice Every Leader Gets Wrong Organizations love the phrase "bring your whole self to work." It shows up in culture decks, leadership development programs, and onboarding materials. Leaders are told: be authentic, be vulnerable, be real. The implicit message is clear: being yourself, your natural unguarded self, is what earns trust and builds teams. The problem is the advice is aimed at the wrong thing. Most leaders who struggle with presence, influence, or visibility are not struggling because they are hiding who they are. They are struggling because they have been told their natural mode of operating should be enough. When it is not, they feel like something is wrong with them. The leadership version of themselves feels like a performance. A costume. Something they are relieved to take off. That guilt is the real problem. And it is rooted in a fundamental misunderstanding of what authenticity actually means. ## What Authenticity Research Actually Shows In 2025, researchers and practitioners began pushing back hard on the "be yourself" narrative. A Columbia Business School professor cited in Fortune argued that [workplace authenticity is overrated](https://fortune.com/2025/10/09/why-is-workplace-authenticity-overrated-gen-z/). The research shows that impression management, the deliberate choice of how to present yourself, can actually make you seem more authentic and trustworthy than rigid adherence to your "true self." This is the authenticity paradox: the harder you try to be exactly who you are at all times, the less effective and relatable you become. Leaders who let every thought show, every frustration surface, and every discomfort become visible are not building trust. They are making their teams manage them. What the research does support is this: the four components of effective authentic leadership are self-awareness, relational transparency, an internalized moral perspective, and balanced processing. Notice what is missing from that list. "Being yourself" is not one of them. ## Why "Being Yourself" Stalls Leaders at the Wrong Moment Here is the pattern I see constantly. A strong individual contributor or manager gets promoted. They have been successful by being competent, by solving problems, by being the person who knows things. That version of themselves has worked. The new role requires something different. More presence. More influence in rooms where they are not the technical expert. More energy in meetings they would rather observe. The "natural self" in this scenario is often an introvert, or a processor, or a person who prefers listening to performing. Leaders who were told to "be themselves" hit this moment and either push through with guilt or they pull back. When they push through with guilt, they feel fake every time they show up as a more visible version of themselves. When they pull back, they stay comfortable in their natural mode at the cost of their effectiveness. Both responses have the same root assumption. Their natural self is the right self for the job. What the leaders who succeed at this transition have in common is not a personality type. It is a willingness to choose who they want to be in the role, and then practice being that person deliberately. They do not feel inauthentic. They feel like they are learning a skill. ## The Deliberate Choice Model: Four Moves ### Separate the Person From the Role You have a self. You also have a role. They are not the same thing. Being an introvert does not make you a bad leader. Needing quiet time to recharge does not make you unable to command a room when it matters. The confusion comes from equating natural state with professional identity. The separation is not about performing a character. It is about recognizing that effective leaders show up differently depending on context. This is not a flaw. This is how humans work. ### Get Specific About the Version You Are Choosing to Be Vague intentions do not produce presence. "I want to be a more confident leader" gives you nothing to practice. Get specific. Do you want to be the person in the room who asks the sharpest question? The person who stays calm when everyone else is reacting? The person who credits other people publicly before they think to ask? Choose deliberately. This is not about picking one and being done. These choices compound. You practice one until it becomes automatic, then you take on the next. Start with whatever is most visible right now, and be specific enough that you could describe it to someone else. The more precise the version you are practicing, the faster it sticks. ### Practice the Skill, Not the Feeling Leadership presence is a performance skill, the same as public speaking or conflict resolution. You would not expect to feel natural on a stage without rehearsing. You would not pick up an instrument and expect to sound polished. Why do leaders expect presence to feel natural on the first try? It does not. You practice it. You get feedback. You notice what works. You do it in low-stakes situations before you try it in high-stakes ones. Over time, the gap between "natural self" and "chosen version" closes. Not because you changed who you are, but because you practiced long enough that the choice became automatic. ### Recognize When the Skill Has Integrated This is the part leaders miss. At some point, the version they chose to practice becomes who they are. The choice becomes invisible. The performance becomes natural. That is not when they have finally become authentic. That is when they have practiced long enough that the choice feels real. The skill is integrated. The discomfort is gone. And now, people who knew them before the shift do not believe them when they say they were ever uncomfortable in large groups. ## The Trust Mechanism Organizations push authenticity because they believe it builds trust. They are right. But not for the reason they think. Trust is not built by showing your whole self. Trust is built by being consistent over time. The leaders people trust most are the ones who show up the same way in a difficult conversation as they do in a celebration. Who behave the same when they are being watched as when they are not. Who make choices about who to be and then make those choices repeatedly, predictably, reliably. Consistency is what feels authentic to the people around you. And consistency is a choice. ## How This Applies Tomorrow If you are working with leaders who are stuck in guilt about their "authenticity" at work, the reframe is simple. You are not faking it. You are learning a skill. The version of yourself that performs well in a board meeting is not a lie. It is a version of you that you are practicing until it becomes natural. Every time you show up that way, you get better at it. The discomfort fades. The person who is most naturally introverted can become the leader everyone wants in the room. Not by changing who they are. By choosing how they want to show up and practicing that choice until it sticks. ## Monday Action This week, write down one specific version of yourself you are choosing to be in your role. Not a personality shift. Not a values change. A presence choice. Something you can practice. Then look for where you are already doing this naturally, even in small ways. Where are you already choosing this version. Build from there. You do not have to be yourself at work. You have to be intentional. When you stop waiting to feel "authentically ready" and start choosing the version of yourself that serves your role, what opens up? You're great at the work. Let's make you impossible to ignore. If you are looking for help developing intentional leadership presence, consider reaching out. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/got-decision-boss-cascade-without-creatinghttps://jessestaffordcoaching.com/blog/got-decision-boss-cascade-without-creatingTL;DR: In 8 minutes, you'll learn how to stop being the communication bottleneck between senior leadership and your team, own decisions as "we decided"...Sat, 14 Mar 2026 00:00:00 GMT**TL;DR:** In 8 minutes, you'll learn how to stop being the communication bottleneck between senior leadership and your team, own decisions as "we decided" instead of "they want this," and cascade strategic context that actually reaches your people. You just left your boss's office. Or closed the Zoom. Or finished reading the email. You have a decision to cascade to your team. Maybe it is a new process. Maybe it is a budget cut. Maybe it is a change to how your team does their work. Your boss explained the reasoning. You understand the business case. You might even agree with it. Now you have to tell your team. **Here is where most managers make the fatal mistake.** They think their job is to pass the message. Relay the information. Be the messenger. So they say: "Leadership has decided we need to do X." Or: "They want us to start doing Y." Or: "I know this is frustrating, but this came from above." **Every time you say "they," you just created a "we vs. they" culture.** Not because you are a bad manager. Because you are treating cascade communication like a relay race instead of an ownership transfer. ## The Real Story: When "They Want This" Breaks Trust A senior leader at a mid-size company rolled out a new documentation standard for engineering teams. The regulatory team was hammering them with questions because change documents were missing business context. Every gap triggered hours of follow-up. The senior leader explained this to his managers. Staff meeting. One-on-ones. Full business case. The pattern he was seeing. The time they were wasting. The risk they were creating. The managers heard it. They understood it. Then they went back to their teams and said some version of: "Leadership wants more detailed documentation." **That is it. Tactic. No strategy.** Three weeks later, an engineer was getting detailed feedback on a change document. Frustrated, they asked their skip-level: "Why are they making you dig this deep?" The senior leader had to say: "They is me. Here is why." But here is what surprised him. The engineer was not questioning his authority. They were trying to **protect him** from what they assumed was a bad decision being forced down from above. The engineer's logic: "This leader does not normally ask for bureaucratic detail. He trusts us. He protects us from unnecessary process. Someone above him must be pushing this." **The strategic context never reached them.** Not because the senior leader did not communicate it. He did. To the managers. Not because the managers were incompetent. They were not. Because somewhere in the cascade, the WHY got stripped out. All that reached the team was the WHAT. ## Why Communication Cascades Fail (Even When You Try) Research on organizational communication reveals a harsh truth: cascades fail not because the concept doesn't work, but because they aren't built correctly [Ragan](https://www.ragan.com/ragan-insider-manager-comms-cascade/). Dr. Robert Carroll from the University of Texas explains: "The problem isn't that information moves through hierarchy, the problem is that we don't equip that hierarchy with what it needs to do the work effectively." [Ragan](https://www.ragan.com/ragan-insider-manager-comms-cascade/) **Three structural failures explain most cascade breakdowns:** ### The Translation Gap Senior leaders speak in strategy: "We need to reduce operational risk and improve regulatory compliance." Your team needs to hear operations: "Regulatory questions are eating 10+ hours a week because our docs are missing context. Here is exactly what to add." You are supposed to translate. But nobody taught you how. ### The Telephone Effect Studies show that like the game of telephone, by the time the message returns to you it has changed significantly [Processexcellencenetwork](https://www.processexcellencenetwork.com/lean-six-sigma-business-performance/columns/top-10-ways-communication-cascades-fail). Each layer of management filters, summarizes, or accidentally distorts. You had ten other priorities when your boss explained this. You might have written down the decision but missed the nuance of the reasoning. Then you mentioned it once in your team meeting and moved on. ### The Distance Problem When you say "they want this," you are creating distance between yourself and the decision. Your team hears: "My manager is just the messenger. The real decision-makers are disconnected from our work." Even if you disagree with the decision, saying "they" makes it worse. Because now your team thinks: "Even our manager thinks this is stupid, but they are being forced to make us do it." ## What Good Managers Do Differently (It's Not What You Think) Here is what might surprise you: **There is no such thing as perfect cascade communication.** Even the best managers have to repeat strategic context multiple times. Research shows that messages need to reach people 7 times, 7 ways before they actually stick [Myhubintranet](https://www.myhubintranet.com/information-cascade/). But good managers do two things that bad managers skip: ### 1\. They Ask Enough Questions to Own the Decision When your boss gives you a decision to cascade, you have a responsibility: **Ask questions until you can deliver it as "we decided."** Not "they decided and I am telling you." Not "leadership wants this." ### "We decided. Here is why." If you cannot say "we" with full conviction, you have not asked enough questions yet. Go back to your boss. Get the full context. Understand the business case. Figure out why this matters. Ask: - What problem are we trying to solve? - What happens if we do not do this? - What are the trade-offs? - What did we consider and reject? - How will we measure success? Keep asking until you understand the decision well enough to defend it as if it were yours. Because once you cascade it, **it is yours.** ### 2\. They Deliver It With Full Buy-In (Even If They Disagree) Notice I did not say "only cascade decisions you agree with." You will get decisions you disagree with. That is part of management. But here is the key: Your team does not need to know you disagree. Your team needs strategic context delivered with conviction. Research on manager communication shows that employees can sense when managers don't believe in decisions they're communicating [Emergingrnleader](https://emergingrnleader.com/when-leaders-dont-agree-with-organizational-decisions/). When you hedge, your team hears uncertainty. When you deflect to "they," your team hears distance. **The right way to cascade a decision you disagree with:** "We had a long discussion about this. There were different perspectives. Ultimately, we decided that \[decision\] because \[business case\]. Here is what it means for us and here is how we are going to make it work." Not: "I do not love this, but leadership wants us to do it anyway." That second version makes you feel better in the moment. You get to distance yourself from the unpopular decision. But it destroys trust in leadership and makes you look powerless. ## The Framework: How to Cascade With Ownership Here is the step-by-step for cascading a decision effectively: ### Step 1: Before You Leave Your Boss's Office Do not just nod and leave. Ask questions. - "Help me understand the business case I should give my team." - "I expect my team will be concerned about \[X, Y, Z\]. How should I address those?" - "What am I missing that would help me explain this better?" Take notes. On the reasoning, not just the decision. ### Step 2: Process It Yourself First You cannot cascade conviction if you are still processing your own reaction. Take 24 hours. Think through: - Do I understand why we made this call? - What concerns do I have that I need to raise back up? - How will this impact my team specifically? - What support will they need? If you still have unanswered questions, go back to your boss before you face your team. ### Step 3: Deliver It as "We Decided" **Bad version:** "Leadership has decided we need to change our documentation process. They want more detail upfront." **Good version:** "I want to talk about a change we are making to our documentation process. We have been getting hammered with regulatory follow-up questions, it is eating about 10 hours a week across the team. We looked at the pattern and realized our change docs answer the technical question but miss the regulatory context. So we decided to add more upfront detail in specific areas. Here is what that looks like for us." Notice the difference: - "We" instead of "they" - Business problem stated clearly - Decision tied directly to the problem - Specific impact for this team ### Step 4: Answer Questions With Context, Not Deflection Your team will have questions. Concerns. Pushback. **Bad responses:** - "I do not make the rules, I just enforce them." - "You will have to take that up with leadership." - "I know, but what can we do?" **Good responses:** - "Good question. The trade-off we considered was \[X\]. We went with this because \[Y\]." - "I do not have a great answer for that. Let me find out and get back to you." - "I hear your concern. Here is what I can control and here is what I cannot." ### Step 5: Repeat It 7 Times, 7 Ways This is the part most managers skip. You said it once in a team meeting. You think your job is done. **It is not.** Repeat the decision and the reasoning in: - Team meeting announcement - Follow-up email with written summary - One-on-ones with each person - Team Slack or chat - Visual reminder (posted procedure, updated documentation) - Pre-shift huddles or stand-ups - Monthly recap of changes Different people absorb information differently. Some need to hear it. Some need to read it. Some need to discuss it. Some need to see it in action. **Your job is not to say it once. Your job is to make sure it reaches everyone.** ## What Happens When You Get This Wrong When you say "they want this" instead of "we decided," here is what your team hears: **"My manager is powerless."** If you are just passing messages from above, you are not a leader. You are a messenger. Your team stops bringing you problems because you cannot solve them. **"Leadership is disconnected."** When decisions arrive without context, your team assumes the people making them do not understand the real work. Trust in senior leadership erodes. **"I should ask why."** Your team starts questioning every decision. Not because they are difficult, but because they are trying to fill in the missing context you did not give them. And here is the worst part: When your team does not trust the cascade, they bypass you. They go directly to your boss or your boss's boss to ask "who really wants this and why?" **That is a signal that you failed to cascade with ownership.** ## The Reality: Even When You Do It Right, You Still Repeat Yourself Here is the hard truth: Even the best cascade communication requires repetition. You will explain the decision. Your team will nod. Two days later, someone will ask a question that proves they did not absorb the context. **That is normal.** Do not get frustrated. Do not think "I already said this." Just say it again. Because consistent, repeated messaging is what makes strategic context stick [Myhubintranet](https://www.myhubintranet.com/information-cascade/). Your boss explained this once to you in a staff meeting. You thought you got it. But you did not really internalize it until you had to explain it to your team. **Your team is the same way.** They will not really get it until they have to apply it. Or explain it to someone else. Or make a decision based on it. Your job is to keep reinforcing the context until it becomes part of how they think. ## Technical Visibility: Why This Matters More for Engineering Managers If you manage technical teams, this cascade failure creates a specific problem. Your work is already invisible to non-technical leaders. When you strip out strategic context from decisions, it makes the invisibility worse. Your team hears: "Leadership wants better documentation." What they think: "Leadership does not understand our work. They think we have extra time for bureaucracy." What you should have said: "We are seeing a pattern where regulatory questions are creating rework. Better upfront documentation prevents that rework and protects us from compliance risk." **The difference between those two messages is massive.** One makes your team think leadership is clueless. The other makes your team understand the business value of their technical work. Your job as a technical manager is to **build the bridge** between technical excellence and business impact. That means translating strategy into operations when cascading down, and translating operations into strategy when communicating up. ## Monday Morning Action Plan **Before your next cascade:** - Ask your boss for the full business case, not just the decision - Write down the reasoning in your own words - Identify the top 3 questions your team will ask - Get answers to those questions before you face your team **When you deliver the decision:** - Use "we decided" instead of "they want" - State the business problem before the solution - Tie the decision directly to the problem - Explain what you considered and why you chose this **After you deliver:** - Plan to repeat it 7 times, 7 ways over the next two weeks - Schedule one-on-ones to discuss individual concerns - Put it in writing so people can reference it - Check for understanding by asking "what questions do you have?" **If someone asks "who wants this?":** - Stop and ask yourself: what strategic context did they not get? - Re-explain the business case, not just the decision - Do not get defensive, their question is valid feedback ## The Bottom Line: Cascade Ownership, Not Messages Your job is not to be a messenger. Your job is to translate strategy into action, own decisions as "we," and repeat context until it sticks. When you say "they want this," you create distance. When you say "we decided this because," you create ownership. **The difference between those two phrases is the difference between a "we" culture and a "we vs. they" culture.** Choose wisely. <hr /> **Have you ever had to cascade a decision you disagreed with? How did you handle it? Share your experience in the comments.** **You're great at the work. Let's make you impossible to ignore.** Want help translating your technical work into business impact? Visit [Jesse Stafford Coaching](/) <hr /> **Related Reading:** - [The Message Delivery Audit: Why Sharing Information Isn't Leading](/blog/message-delivery-audit-sharing-information-isnt) - [Why Information Doesn't Reach Employees (And How to Fix It)](/blog/information-doesnt-reach-employees-fix) - [Managing Managers Isn’t About Control, It’s About Clarity](/blog/managing-managers-isnt-control-clarity)https://jessestaffordcoaching.com/blog/peer-leader-keeps-blocking-progress-realhttps://jessestaffordcoaching.com/blog/peer-leader-keeps-blocking-progress-realPoor communication is the number one cause of workplace conflict PR Newswire , according to recent workplace research. But that explanation misses...Thu, 12 Mar 2026 00:00:00 GMT## The Conflict Research Gets Wrong About High Performers Poor communication is the number one cause of workplace conflict [PR Newswire](https://www.prnewswire.com/news-releases/new-research-time-spent-on-workplace-conflict-has-doubled-since-2008-301652771.html), according to recent workplace research. But that explanation misses something critical when the conflict is between two competent, committed leaders. The real issue is not communication quality. It is information asymmetry. Employees in the United States spend an average of 2.8 hours per week dealing with workplace conflict [PubMed Central](https://pmc.ncbi.nlm.nih.gov/articles/PMC3835442/). That translates to roughly 145 hours per year, nearly a full month of productivity, lost to managing friction instead of making progress. But here is what makes peer conflict different from other workplace disputes: higher psychological job demands, higher levels of role ambiguity, and higher levels of job insecurity were among the main risk factors predicting the onset of interpersonal conflicts at work [PubMed Central](https://pmc.ncbi.nlm.nih.gov/articles/PMC9902267/). When two high-performing leaders are both stretched thin, both managing competing priorities, and both operating under pressure, they stop sharing context about their constraints. They each know their own full picture. They see only a sliver of what the other person is juggling. That is information asymmetry. And it destroys collaboration faster than any personality clash. ## What Information Asymmetry Looks Like in Real Time I watched this play out with two of my strongest managers. Both were action-focused leaders. Both had committed teams. Both were working toward the same deadline on a shared project. And both came to me, separately, convinced the other person was the problem. "Their team is not pulling their weight." "We cannot make progress because they are not delivering what they promised." "I do not think they actually care about this project like we do." Same frustration. Different manager. Every week for a month. Here is what I knew that they did not: Both teams were working hard. Both managers were competent. Nobody was sabotaging anything. So why the standoff? ## The Three Questions That Revealed the Real Problem I started asking each manager questions. Not about the project. About their decision-making process. **Question one:** What is your team working on right now? Not just the shared project. Everything. Both managers rattled off long lists. Infrastructure upgrades. Technical debt reduction. Security patches. Feature work for other stakeholders. Training new team members. **Question two:** What have you told the other manager about all of this? Silence. Then defensive explanations about why the other person should already know, or why it should not matter, or why their priorities were obviously more important. **Question three:** What do you think the other team is working on right now? They could describe the shared project work in detail. They could not name a single other thing the other team was managing. That is when I saw it clearly. Each manager had full visibility into their own constraints. They knew every competing priority pulling their team in different directions. They understood why certain deadlines had to slip or why certain requests were unreasonable. They gave themselves grace because they knew the full context. They could not extend that same grace to the other manager because they only saw the part of the picture related to their shared goal. Information asymmetry creates an empathy gap. ## Why Standard Conflict Resolution Would Have Failed Here Most conflict resolution advice would tell you to: - Schedule a meeting to align on priorities - Create a shared project plan with clear ownership - Establish weekly status updates - Escalate to leadership if needed I did none of those things. Why? Because the problem was not lack of coordination. It was lack of connection. If I had told these two managers to meet and share their roadmaps, here is what would have happened: Manager A presents their list of projects. Manager B hears it and thinks, "Yeah, but my work is more important because it affects revenue." Manager B presents their constraints. Manager A hears it and thinks, "Sure, but we agreed the shared project was the priority." They would have left the meeting with more data and the same frustration. Because you cannot solve an empathy gap with a spreadsheet. ## The Counterintuitive Fix: Remove Work From the Conversation I told both managers they needed to have a one-on-one meeting. But they were not allowed to discuss work. Their reactions were immediate and skeptical. "How does that help us hit the deadline?" "We need to coordinate, not socialize." "I do not have time for coffee talk right now." I explained my thinking: They did not see each other as whole people managing competing demands. They saw each other as obstacles to their goal. Until that shifted, no amount of project planning would fix the friction. I did not give them an agenda. I just reminded them that they both had families. Teenagers navigating college decisions. Aging parents. Hobbies outside of work. Lives that existed beyond this deadline. They met. I never asked what they discussed. But within a week, the dynamic changed completely. ## What Changed: From Complaints to Coordination The finger-pointing stopped. The complaints to me disappeared. Instead, I started seeing different behavior: They proactively shared updates about other projects affecting their bandwidth. They coordinated on roadmap timing without me facilitating. They built contingency plans together instead of waiting for the other person to fail. The shared project moved forward faster than it had in weeks. What happened in that meeting? I do not know the specifics. But I know what shifted: They stopped seeing each other as competing priorities and started seeing each other as people under the same pressure. ## The Research on Information Asymmetry Supports This Approach Information asymmetry happens when one party has more or better information than another. It creates what economists call "market failure" in transactions. But in workplace relationships, information asymmetry creates something worse: it breaks trust without anyone realizing why. Research on information sharing in organizations shows that trust may flourish under conditions of information asymmetry in some contexts [ScienceDirect](https://www.sciencedirect.com/science/article/abs/pii/S0019850115300109), but only when both parties recognize the asymmetry exists and choose to extend trust anyway. The problem with peer conflict is that neither party realizes they are operating with incomplete information. They both assume they see the full picture. They both think the other person is making unreasonable choices. The fix is not more information sharing. The fix is building enough relational trust that people want to share context, not just data. ## Why Emotional Connection Solves Information Problems Here is the pattern I see repeatedly in leadership conflict: When you are frustrated with a peer, three conditions are almost always present: **First:** You are both working toward the same goal with equal commitment. The conflict is not about effort or dedication. **Second:** They are frustrated with you too. You think they are being difficult. They think you are being unreasonable. You are both operating from incomplete information. **Third:** One or both of you knows something the other does not. That missing context is driving divergent decisions that look like obstruction from the outside. You cannot fix this with better status updates. You fix it by creating space for people to see each other as allies, not obstacles. ## The Practical Application: What to Do Monday Morning If you are currently in a standoff with a peer leader, here is the diagnostic framework: ### Internal Check: What Do You Know That They Don't? Ask yourself: - What deadlines am I managing that I have not explicitly shared? - What trade-offs have I made that seem obvious to me but might not be visible to them? - What pressures am I under that would explain my decisions if they knew about them? ### Flip the Perspective: What Would Make Their Behavior Reasonable? Then ask: - What would have to be true for them to make the choice they are making? - What constraints might they be managing that I cannot see? - If I trusted their competence and commitment, what information gap would explain our disagreement? ### The Conversation Starter That Actually Works Do not schedule a project alignment meeting. Instead, reach out with this: "I think we are both feeling the pressure on this project. Can we grab coffee and just talk? Not about the work. Just check in." It sounds soft. It sounds unproductive. But information asymmetry does not get solved by sharing more project data. It gets solved by building enough relational trust that people want to share their constraints voluntarily. ## When Work Relationships Beat Work Processes I learned something important from watching those two managers rebuild their working relationship: Relationships are how we make progress at work. Not processes. Not status updates. Not project management tools. When conflict happens between two competent, committed leaders, the problem is never competence or commitment. The problem is invisible context. The fix is not more meetings. It is more connection. Step back from the goal long enough to see the person on the other side. Remember they are managing similar pressure. Give them the same grace you give yourself. Share your constraints so they will share theirs. ## What This Means for Technical and Systems Leaders This pattern shows up constantly in technical leadership because the work is often invisible to people outside your domain. Your infrastructure migrations. Your technical debt reduction. Your security hardening. Your refactoring work. Other leaders cannot see it. They just see you saying "no" or "not yet" or "that will take longer than you think." Without shared context about what you are managing, those reasonable responses sound like excuses. The solution is not explaining your technical work better. The solution is building relationships strong enough that people trust your judgment even when they cannot see your full workload. And that starts with seeing them as whole people, not just stakeholders in your project. ## The Action Step: Pause Before You Escalate If you are frustrated with a peer right now, you have three options: **Option one:** Escalate. Loop in your manager or HR. Make it a formal issue. **Option two:** Power through. Keep sending Slack messages. Keep restating your deadlines. Keep assuming they will eventually get it. **Option three:** Pause. Get curious about what you might be missing. Reach out for connection, not coordination. The first two options might get you short-term compliance. They will not build the relationship you need for long-term collaboration. The third option sounds slower. It is actually faster. Because conflict does not break relationships when there is trust underneath. It makes them stronger. But you cannot build that trust through project plans. You build it by remembering: the person on the other side is not your obstacle. They are your teammate. And they are probably just as frustrated as you are. <hr /> **What's one peer relationship where you're feeling friction right now? What might you know that they don't, or what might they know that you're missing?** You're great at the work. Let's make you impossible to ignore.https://jessestaffordcoaching.com/blog/prepare-team-attrition-happenshttps://jessestaffordcoaching.com/blog/prepare-team-attrition-happensTL;DR: In 5 minutes, you'll learn how to stop treating attrition as a crisis and start preparing for it strategically. One question will change how you...Mon, 02 Mar 2026 00:00:00 GMT**TL;DR:** In 5 minutes, you'll learn how to stop treating attrition as a crisis and start preparing for it strategically. One question will change how you invest in your team: "If my best person quit tomorrow, what would break?" Most leaders wait until someone gives notice to think about attrition. By then, it is too late. You are scrambling. Backfilling. Hoping nothing critical breaks while you hire a replacement. But what if you could see it coming? What if you could prepare for departures before they happen? Not in a paranoid way. In a strategic way. That shift happened for me during the pandemic when I had to do something most leaders never do: forecast my team's attrition for the next 2-3 years. It felt morbid at first. Like planning funerals for people who were still alive. But it changed everything about how I lead. ## The Pattern Nobody Wants to See Late 2021. Post-pandemic chaos. My company was reining in costs, and my team was bleeding talent. Not just any talent. The wrong talent. My boss needed me to staff critical projects and control the budget. To do that, I had to forecast attrition. Model the cost. Figure out who was leaving and when. So I built spreadsheets. Mapped raises, promotions, backfills, new hires. I looked at performance data. Tenure. Flight risk indicators. And I saw something uncomfortable. The people most likely to leave were my high performers. The people most likely to stay? My steady, average performers who valued stability over opportunity. It makes sense. High performers get recruited. They get bored. They outgrow roles. They have options. Steady performers are not looking. They are satisfied with what they have. They are anchored. But seeing it laid out in black and white was clarifying in a way I did not expect. ## Why This Pattern Matters (And What It Costs) Recent research from The Predictive Index found that 47% of high-performing employees left their company in 2022. [Dr John Sullivan](https://drjohnsullivan.com/articles/half-top-performers-quit-last-year/) Nearly half. Not average performers. Not people struggling in their roles. The best people. And the cost is staggering. Replacing an individual employee can cost between one-half to two times their annual salary. [Workinstitute](https://workinstitute.com/blog/employee-attrition-analytics-employee-turnover/) That is before you factor in lost productivity, knowledge walking out the door, and the impact on team morale. When I looked at my forecast, I was not just seeing names and dates. I was seeing hundreds of thousands of dollars walking out the door. Projects at risk. Institutional knowledge disappearing. That is when the shift happened. ## From Reactive to Strategic: The Leadership Shift Before that exercise, I handled attrition the way most leaders do. Someone gives notice. I react. I scramble to backfill. I move on. Attrition was something that happened *to me*. Not something I planned for. But once I forecasted it, I could not go back to that mindset. Because now I could see the gaps before they opened. I could see which departures would hurt and which would not. And that forced a different question: What am I doing *now* to prepare for *later*? ## What Changes When You Plan for Attrition I started making different decisions about my team. **Raises and promotions became strategic, not just merit-based.** If someone was critical and at flight risk, they got more investment. More attention. More reason to stay. Not because they deserved it more than others, but because losing them would cost more. **I built development opportunities I would not have built otherwise.** Stretch projects. Visibility at senior levels. Skills they could not get elsewhere. I needed my high performers to see a future here that beat whatever recruiters were pitching. **I cross-trained deliberately instead of reactively.** I documented processes that lived in one person's head. I built redundancy into projects. I identified single points of failure before they failed. And here is what surprised me. Planning for someone to leave did not make me a worse leader. It made me a better one. Because I was investing in retention *and* preparing for reality at the same time. ## The Uncomfortable Truth About High Performers Your best people are always one recruiter call away from leaving. You cannot prevent that. But you can do two things: 1. Make staying more attractive than leaving 2. Prepare for the reality that some will leave anyway Most leaders only do one or the other. They either invest everything in retention and get blindsided when someone quits. Or they assume everyone will leave and never invest at all. Both approaches fail. Strategic leaders do both. They invest in keeping people *and* prepare for when they go. That is not defeatist. That is realistic. ## Why Attrition Is Not Always Bad Here is something else I learned: attrition creates opportunity. When someone leaves, you can change the dynamic of your team. You can give other people chances to step into bigger roles. You can create skill-building moments. You can fix structural problems that were hard to address when that person was there. But only if you are prepared for it. If you are reactive, attrition is chaos. Projects stall. Knowledge walks out the door. You are firefighting. If you are strategic, attrition is manageable. You have contingency plans. You have cross-trained backups. You know what will break and how to fix it. ## The Question That Changes How You Lead You do not need a budget crisis to think strategically about attrition. You just need to ask one question: **"If my best person quit tomorrow, what would break?"** Not "who would I lose." What would *break*. What projects would stall? What knowledge would disappear? What relationships would we lose? What would I have no backup plan for? Write it down. Then ask the follow-up: **"What do I need to put into place now to mitigate that?"** Maybe it is cross-training someone on a critical system. Maybe it is documenting tribal knowledge. Maybe it is building project redundancy. Maybe it is having the retention conversation you have been avoiding. Do not wait for someone to give notice. Because forecasting attrition taught me this: you cannot prevent your best people from leaving. But you can prepare for it. And preparation makes you a better leader right now, not just later. ## Strategic Attrition Planning Is Not Morbid It felt morbid at first. Looking at my team and thinking "Sarah's probably gone in 18 months." But it was not morbid. It was strategic. Because planning for someone to leave does not mean you want them to leave. It means you are serious about keeping them *and* realistic about the fact that some will go anyway. That mindset shift changes everything. You invest better. You prepare smarter. You lead with clarity instead of hope. And when someone does leave, you are ready. <hr /> **What would break if your best person left tomorrow?** I'd love to hear your thoughts in the comments. You're great at the work. Let's make you impossible to ignore. If you want help building retention strategies and succession plans that actually work, let's talk: [Jesse Stafford Coaching](/) **Sources:** - The Predictive Index: [drjohnsullivan.com](https://drjohnsullivan.com/articles/half-top-performers-quit-last-year/) - Work Institute Employee Attrition Analysis: [workinstitute.com](https://workinstitute.com/blog/employee-attrition-analytics-employee-turnover/)https://jessestaffordcoaching.com/blog/adaptive-project-planning-stop-treating-planshttps://jessestaffordcoaching.com/blog/adaptive-project-planning-stop-treating-plansTL;DR: In 8 minutes, you'll learn how to stop defending outdated plans and start using adaptive project planning checkpoints to measure progress...Sun, 01 Mar 2026 00:00:00 GMT> ***TL;DR:** In 8 minutes, you'll learn how to stop defending outdated plans and start using adaptive project planning checkpoints to measure progress against outcomes instead of schedules, so your team can pivot when reality changes.* Years ago, I worked on a game development team attempting something ambitious. We were integrating 3D assets for a traditionally 2D player base. Our designer constantly requested changes and refinements. The development team grew increasingly frustrated as nothing matched our carefully constructed project plan. Eventually, I sat down with the designer and asked a direct question: "Specifically, what about our current build fails to meet market needs?" The response was devastating: nearly everything. We had invested months following our plan precisely because it was the plan. We avoided deviation. The team remained locked into executing predetermined steps, even as evidence mounted that those steps led nowhere productive. I told the designer: "If that reflects your genuine assessment of this project, we owe it to ourselves to cancel it." This was not a popular opinion. When the designer acted on this recommendation and the project was scrapped, team members were furious about their lost work. But here's the uncomfortable truth nobody wanted to acknowledge: we were attempting to salvage what we had built rather than asking whether it would achieve our desired outcome. Ultimately, we discarded most of the game and started fresh. The result became an excellent game. But it bore no resemblance to our original plan. ## The Hidden Cost of Rigid Planning in Software Development The game team fell into a classic sunk cost fallacy. We continued executing the plan because we had already invested substantial work. Every checkpoint focused on measuring schedule variance, not whether we were approaching something players would value. As Marc Brickley notes in his analysis of [why agile methodologies create psychological discomfort](https://medium.productcoalition.com/agile-feels-impossible-for-some-people-20706d26e910): "Plans are provisional models, not contracts: early estimates and Gantt-style plans are guesses that should be updated as new information appears." Our plan was fundamentally a guess. Yet we treated it as a binding contract. > **Source-able Fact:** "Plans are provisional models, not contracts: early estimates and Gantt-style plans are guesses that should be updated as new information appears.", Marc Brickley, software development researcher When the designer repeatedly requested modifications, we interpreted this as scope creep or indecisiveness. The reality: this was feedback indicating our plan wasn't working. We were constructing something, just not the correct something. ## Understanding Adaptive Project Planning vs Traditional Estimation The #NoEstimates movement in software development challenges traditional estimation practices. Estimation is very difficult, perhaps impossible, and often misused - when requirements are vague, estimates would also be very vague, and accurate estimation becomes essentially impossible. [Ronjeffries](https://ronjeffries.com/xprog/articles/the-noestimates-movement/) If everything proceeded perfectly, we wouldn't require a plan. Plans serve to indicate how far off track we've drifted and provide a framework for determining how to return to our intended trajectory. The game team needed the plan to communicate: "We built what the plan specified, but it isn't functioning. What will it require to achieve the outcome we're pursuing?" Instead, we kept asking: "How far behind schedule are we?" This was the wrong question. The measurement should have been: How distant from our goal are we today? Not how distant from the plan. Bob Ricca, writing about [how agile methodologies don't eliminate the need for strategic planning](https://uxdesign.cc/being-agile-doesnt-replace-the-need-for-planning-65617040af8b), articulates it this way: "The value of planning is in forcing conversations about goals, trade-offs, and priorities, not in producing a document that will predict delivery dates perfectly." That's precisely what we missed. The plan should have forced conversations about whether we were building the appropriate game. Instead, it became a document we defended. ## Technical Visibility Through Adaptive Planning Frameworks Ricca also observes: "Up-front detail does not remove risk; it can create the illusion of control and push teams to defend a bad plan instead of adapting." That's exactly what occurred with the game team. We possessed a detailed plan. It felt secure. It provided something to measure against. But it created an illusion that we understood what we were building. The reality: we were learning what players required as development progressed. The plan couldn't account for that learning. It was supposed to be updated as new information emerged. Instead, we treated deviation from the plan as failure. When teams defend retaining a feature that no longer makes sense because "it's in the plan," or resist changing direction even when they've learned something that invalidates the original plan, they're not being disciplined. They're being rigid. There's a critical difference. ## The #NoEstimates Alternative to Traditional Project Management Research in adaptive project planning reveals important insights. Estimates are always inaccurate, usually wildly so - the only situation where an estimate can be viable is when you're using a team to build something that same team has built in the past using identical technology. [Allen Holub](https://holub.com/noestimates-an-introduction/) The #NoEstimates movement represents "a hashtag for exploring alternatives to estimates for making decisions in software development," focusing on continuous improvement rather than simply refusing to estimate. [Archi](https://www.methodsandtools.com/archive/noestimates.php) The fundamental shift: build regular checkpoints to ask "Does this plan still achieve our destination?" Not "Are we on schedule?" but "Are we closer to the outcome?" When you're off plan, pause and conduct a detailed conversation about what being off plan actually means in this moment: "According to the plan, X work was supposed to be completed by now." "X feature should have been evaluated by users by now." "Based on that, we're behind schedule by Y." Here's the critical component: **Are we moving the date, or adjusting our expectations?** Because sometimes being off plan means you require more time. Sometimes it means the plan was incorrect and you need a different approach. Sometimes it means the outcome itself needs modification. You cannot answer that question if you're merely attempting to return to schedule. ## Engineering Manager Burnout Recovery: Learning Over Waiting The game team story taught me two principles: **Learning is greater than waiting.** We waited months to acknowledge the plan wasn't working because we didn't want to confront the sunk cost. If we had verified sooner, we could have pivoted sooner. **Sharing is greater than assuming.** The designer was attempting to communicate that the plan was broken, but we assumed they were simply being indecisive. We didn't ask the appropriate questions until it was nearly too late. Plans are waypoints. They indicate where you anticipated being at certain points in the journey. When you reach a waypoint and realize you're not where you expected to be, that's not failure. That's information. The question is: What do you do with that information? ## Leading Without Authority: Building Adaptive Planning Checkpoints Here's your implementation framework: ### Technical Visibility Strategy 1: Schedule Regular Plan Evaluation Checkpoints Pick a rhythm matching your work cadence. Monthly for long projects, weekly for fast-moving initiatives. The checkpoint isn't about reporting progress. It's about evaluating whether the plan still achieves the outcome. ### High-Achiever Overwhelm Prevention 2: Ask Three Critical Questions At each checkpoint: - What have we learned since we created this plan? - Does this plan still achieve our destination? - If we're off plan, what does that actually mean right now? ### Engineering Manager Framework 3: Make the Decision Explicit Are we moving the date? Adjusting scope? Changing the outcome? Maintaining the plan because it still makes sense? Don't permit the team to remain in limbo, marching toward a plan that no longer functions. The plan is your measuring tool. Use it to navigate, not to execute blindly. ## Adaptive Planning Resources and Further Reading For more on adaptive planning approaches: - Marc Brickley: [Agile Feels Impossible for Some People](https://medium.productcoalition.com/agile-feels-impossible-for-some-people-20706d26e910) - Bob Ricca: [Being "Agile" Doesn't Replace the Need for Planning](https://uxdesign.cc/being-agile-doesnt-replace-the-need-for-planning-65617040af8b) - Ron Jeffries: [The NoEstimates Movement](https://ronjeffries.com/xprog/articles/the-noestimates-movement/) <hr /> **What question are you asking your team this week to evaluate whether your plan still works?** You're great at the work. Let's make you impossible to ignore. Need help building adaptive planning frameworks that keep your team focused on outcomes? Visit [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/manager-isnt-asking-work-harder-needhttps://jessestaffordcoaching.com/blog/manager-isnt-asking-work-harder-needTL;DR: In 8 minutes, you'll learn how to stop assuming every new request means "work harder" and start asking the three priority questions that turn...Sun, 01 Mar 2026 00:00:00 GMT> ***TL;DR:** In 8 minutes, you'll learn how to stop assuming every new request means "work harder" and start asking the three priority questions that turn overwhelming workloads into focused impact, so you create more value without burning out.* Your manager just added another project to your plate. You're already working at capacity. Your first thought: "Don't they see how hard I'm working? Why are they asking for more?" Here's what they probably actually mean: work differently. Not more hours. Not superhuman effort. Different choices about where your time creates the most value. ## The Game Development Team That Heard "More" When We Said "Different" Years ago, I led process changes for game development teams. We wanted clearer expectations at each development stage and better communication about whether projects were on track. The change was straightforward: show us rough draft animations by the midpoint milestone. That way we could give feedback early, iterate faster, and avoid spending weeks polishing work before knowing if we were building the right thing. The team heard something completely different. "You want the game done by midpoint? We're already buried. How are we supposed to add more checkpoints on top of everything else we're doing?" They thought we were asking for more work. We were asking them to stop doing certain work. Stop polishing animations to final quality before getting feedback. Get rough drafts in front of stakeholders faster. Build to "good enough for feedback" instead of "final polish." I tried to clarify. It didn't land. They kept hearing "do more" when we were saying "do differently." The initiative failed because we never closed that gap. ## What Research Shows About Workload and Performance Employee perception of workload balance directly influences job satisfaction, productivity, and turnover. When workload exceeds capacity, employees experience burnout, dissatisfaction, and breakdown. But here's what most people miss: prioritizing tasks has a positive impact on employee performance, meaning the issue often isn't the amount of work but rather which work gets focus. Planning and prioritizing reduce stress, job pressure, and psychosomatic symptoms. Employees trained in time management report higher job satisfaction and engage more effectively in planning. The difference isn't working more, it's working on what matters. But there's a problem. Less than one third of employees are very satisfied with the quality and amount of internal communication they receive from their organizations. In one study, 70% of employees reported never discussing their career growth with their managers before leaving, and around 53% felt unrecognized for their contributions. The communication gap creates the workload perception problem. When managers add work without clarifying priorities, employees assume they're expected to do everything. When employees don't ask clarifying questions, they work to standards nobody requested. ## My Own Shift: From "Do It All" to "Do What Matters" I spent years trying to get everything done. Every request that landed on my desk, every project, every task. I worked harder. I worked longer. I delivered exactly what was asked for. My career was fine. Not great. Fine. Then I made a shift. I stopped trying to do it all and started asking what actually mattered. What creates the most impact? What moves the needle? What happens if this doesn't get done? I started saying no to some things. I started delivering what was needed instead of what was literally asked for. I stopped assuming I understood the priority and started asking clarifying questions. That's when things changed. Faster promotions. More visibility. Better results with less grinding. The difference wasn't working smarter in the productivity-hack sense. It was operating differently. Making different choices about where my time went. ## Technical Visibility Strategies: What Your Manager Actually Needs When your manager adds work or changes expectations, they're not asking you to work harder. They need you to make different choices about how you use your time. Not more than eight hours. Not nights and weekends. Not superhuman productivity. Employees need guidelines in the initial stage of prioritizing tasks, and time management is one of the best strategies to deal with prioritizing tasks effectively. But most people default to "get it all done." Your manager needs you to default to "get the right things done." ### Engineering Manager Burnout Recovery: The Three Priority Questions When your manager adds work or shifts priorities, ask three questions: **Question 1: What is most important right now?** Not what's urgent. Not what's loudest. What actually matters most to the business, the team, or the project? Your manager may not spell this out. Ask directly. "Given everything on my plate, what should I prioritize?" Employees who are better at setting clear work priorities are less likely to experience stress due to workload accumulation. The clarity reduces the stress, not the hours worked. **Question 2: If one of these things didn't get done, which would have the least impact?** This is the inverse of priority. What can you delay, delegate, or drop entirely? Most people assume everything matters equally. It doesn't. Find out what matters least and stop doing it. 84% of workers indicated they would be more productive if they could structure their workday based on their work style preferences. Part of structuring effectively is knowing what NOT to do. **Question 3: Where am I making assumptions about what my manager expects?** You think you know what "done" looks like. You think you know what quality standard they want. You think you know the timeline. Ask clarifying questions. "When you say you need this by Friday, does that mean rough draft or final polish?" "What does good enough look like for this project?" Half the time, you're working to a higher standard than anyone asked for. Employees who are less trusted by their managers exert less effort and are less productive, but the reverse is also true, when communication is clear and expectations are explicit, employees can focus their effort effectively. ## High-Achiever Overwhelm: What "Working Differently" Actually Looks Like Here's what this looks like Monday morning. Your manager just told you about new goals or added work to your plate. Do not assume you need to work harder. Do not assume you need to fit it all in. Ask: "Given this new priority, what should I deprioritize or stop doing?" Then ask: "What does good enough look like for this? What's the minimum viable version that creates value?" You'll discover one of two things: **Discovery 1:** Something on your plate actually doesn't matter as much as you thought. Drop it or delay it. **Discovery 2:** Your manager didn't realize how full your plate already was. Now they do. They'll help you reprioritize. Either way, you're not working harder. You're working differently. ## Leading Without Authority: Making Better Choices With Your Time The shift is not about doing more. It's about making different choices with the time you have. Planning, goal-setting, prioritization, and task organization emerged as particularly beneficial strategies for enhancing productivity, well-being, and overall performance. But these strategies only work when you know what to prioritize, and that requires asking the questions that clarify what matters. Stop trying to get it all done. Start asking what actually matters. Your manager is not asking for superhuman effort. They're asking you to deliver the most value with the hours you already have. That's a different question entirely. ### The Monday Morning Action Before your next one-on-one with your manager, write down three things: 1. What you're currently working on 2. What new requests or priorities have been added 3. Which current work you're unsure still matters Then ask: "Given these new priorities, what should I deprioritize or stop doing entirely?" You'll get clarity. You'll reduce stress. You'll create more value without working more hours. <hr /> **What assumptions are you making about your workload that you could clarify with your manager this week?** You're great at the work. Let's make you impossible to ignore. If you're stuck trying to do it all instead of figuring out what matters, let's talk. I help technical and systems leaders get clear on where their time creates value and communicate it with confidence so they get the recognition and career growth they deserve. **Learn more:** https://www.jessestaffordcoaching.comhttps://jessestaffordcoaching.com/blog/manage-list-leader-stop-treating-likehttps://jessestaffordcoaching.com/blog/manage-list-leader-stop-treating-likeTL;DR: In 7 minutes, you'll learn how to stop treating your to-do list as a completion checklist and start treating it as a decision tool to achieve...Sat, 28 Feb 2026 00:00:00 GMT**TL;DR:** In 7 minutes, you'll learn how to **stop treating your to-do list as a completion checklist** and **start treating it as a decision tool** to achieve **clarity on what actually matters and reduced stress from impossible workloads**. ## The Hidden Problem With Most Leaders' To-Do Lists I block three hours every Monday morning to plan my week. I review my calendar, update my to-do list, and set my priorities. For years, I treated this time like project triage. I would look at everything on my list and figure out how to cram it all in. I would move things around, shuffle priorities, and convince myself that if I just worked a little smarter, I could get it all done. I was lying to myself. Here is what I noticed: when something did not feel important, I freely moved it to a future date. Sometimes next week. Sometimes next month. And nothing bad happened. The dates were not real. They were placeholders. Manufactured urgency designed to keep me busy, not productive. That is when I realized: **my to-do list is not a list of things to get done. It is a list of things to decide when, if, and how they get done.** ## Why Leaders Struggle With Task Prioritization Research from [Psychology Today](https://www.psychologytoday.com/us/blog/blindspotting/202602/why-leaders-struggle-with-prioritization-not-time-management) found that CEOs spend less than 50% of their time on their stated priorities. Even more striking, [a study of knowledge workers](https://myhours.com/articles/time-management-statistics-2025) found that 60% of their time is spent on "work about work", emails, meetings, searching for documents, rather than meaningful work. Most corporate deadlines are artificial. They exist to create a sense of urgency, not because the work is actually business-critical. A leader sets a date because it keeps the project moving forward. Or because they were managed that way themselves and it worked. Or because they need something to put in the project tracker. I am not saying this is malicious. Most of the time, it is not even intentional. It is just how corporate work operates. Dates fuel the desire to stay busy by keeping everyone focused on the next deadline. But [being busy is not the same as being productive](https://www.activtrak.com/blog/wasting-time-at-work/). When you treat every deadline as real, you end up optimizing for activity instead of impact. ## The Cost of Treating Every Task Like It Matters Equally According to [time management research](https://www.timewatch.com/blog/time-management-statistics-in-2022/), 56% of people say they do not have things under control at work every day. Only 23% feel in control four days a week. When you treat every deadline as real, you: - Spend your time checking boxes instead of doing work that matters - Feel stressed because there will always be more tasks than time - Feel guilty when things do not get done, even if those things were never actually important Here is what I learned: **there will always be more work to do than there is time to do it.** Being honest about that is a stress reducer. Communicating openly about it removes the fear of failure. People ask me all the time: "How do you get everything you're supposed to do done?" My answer: **"I just don't."** ## Technical Visibility Strategy: Treat Your To-Do List as a Decision List Every Monday morning, I evaluate every task on my list against a set of questions: ### Question 1: What Are My Priorities for the Week? Do I need to focus on an immediate goal? Plan some strategy? Just be present for meetings? This is not a theoretical exercise. I literally ask: what is my meeting load? Can I realistically make progress on this task in the time I have available? ### Question 2: How Important Is It That This Gets Done This Week? What happens if it does not? What makes this date important? If I do not have favorable answers to those questions, I move the task to next week. Or next month. Or I delete it entirely. ### Question 3: Does This Align With My Actual Priorities? I also organize my to-do list into three categories: - Things I need to do - Things I need to delegate - Things I need to follow up on This structure forces me to think about what actually requires my time versus what I should be handing off or monitoring. ## Engineering Manager Burnout Recovery: The Questions That Change Everything When someone gives me a task with a deadline, I ask three questions: **What is the importance of this work to the project?** Not "is it important," but what specifically makes it matter. **What will happen if it is not done?** This reveals whether the deadline is real or manufactured urgency. **What makes this date important?** Is there a customer commitment? A regulatory requirement? Or is it just a placeholder? Sometimes I ask these questions silently and decide for myself. Sometimes I ask the person more openly. It depends on how much context I already have about the situation and the business priority. And here is the critical part: **I weigh it against my current priorities.** If it does not make priority one, I share that and let them know when I will be able to get to it. This is not about saying no. It is about being honest about capacity and trade-offs. ## High-Achiever Overwhelm: How This Changed How I Lead Once I realized my own to-do list was a decision list, I started treating delegation the same way. ### Give Clear Priority and Context When I assign work to someone on my team, I give a clear priority and a deadline that aligns with it. Not just "get this done by Friday," but "this is a priority two task, and here is why I want it by Friday." ### Explain Why the Date Matters I do not make them guess whether the deadline is real. I tell them what makes it matter. ### Ask When They Can Actually Get It Done Because if I do not ask, they will say yes to everything and then quietly move things around on their own list without telling me. And then I am blind to whether the work is actually happening. This approach does two things: it gives them the context to make their own decisions about their workload, and it gives me visibility into what is realistic. ## Leadership ROI: What This Looks Like on Monday Morning Here is the concrete shift: **Before:** I looked at my to-do list and asked, "How do I get all of this done?" **Now:** I look at my to-do list and ask, "What decisions do I need to make about each of these tasks?" The stress comes from treating every task like it has to get done. The clarity comes from deciding what actually matters this week. Some tasks are priority one. Those get time blocked on my calendar. Some tasks are priority two. Those get done if I have capacity. Some tasks are not actually my priority at all. Those get delegated or deleted. And some tasks have fake deadlines. Those get moved to a future date when they actually matter. ## Leading Without Authority: The One Action to Take Monday Morning **Open your to-do list and ask three questions about each task:** 1. What happens if this does not get done this week? 2. What makes this date important? 3. Does this align with my actual priorities? If you do not have good answers, move it. Or delegate it. Or delete it. Your to-do list is not a list of things to get done. It is a list of decisions about when, if, and how things get done. Stop treating it like a completion checklist. Start treating it like a decision tool. <hr /> **What decisions are you making about your to-do list this week?** You're great at the work. Let's make it impossible to ignore. If you're a technical or systems leader who wants to get clear on what actually matters and communicate it with confidence, let's talk: [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/choosing-job-choose-youll-work-victimhttps://jessestaffordcoaching.com/blog/choosing-job-choose-youll-work-victimTL;DR: Stop treating your job like something happening TO you and start choosing how you work WITH it to reclaim control and accelerate your career...Wed, 11 Feb 2026 00:00:00 GMT**TL;DR:** Stop treating your job like something happening TO you and start choosing how you work WITH it to reclaim control and accelerate your career without changing companies. Research from LaMarsh Global shows that victim mentality in the workplace manifests as feelings of helplessness where employees believe change happens to them rather than with them. This passive state leads to stress, decreased job satisfaction, and career stagnation. But here is what the research misses: the moment you acknowledge you are choosing to stay, everything changes. I turned down a job that offered me a 50% pay increase. The other company checked all the boxes on paper. Better title. More money. New challenges. But something in my conversations with them felt off. The culture did not fit. The way they talked about their team did not sit right with me. Even with the significant raise, I knew it would not be a better environment for me. So I said no. And then I had to sit with what that meant. ## The Victim Mentality Trap: What Research Shows According to research published in the journal Work and Occupations, employees with higher levels of workplace autonomy reported significantly better well-being and job satisfaction. But here is the paradox: victim mentality destroys that autonomy before you even realize you have it. A LinkedIn study found that 10 common signs mark victim mentality in the workplace: constant complaining, deflecting responsibility, blaming others when things fail, claiming to be overworked, focusing only on enjoyable tasks, and refusing to look in the mirror to ask how your own actions contribute to problems. I was exhibiting every single one of these patterns. If I was choosing to stay at my current job with the micromanaging boss, the uncertainty about promotions, the projects that were not gaining traction, then I needed to stop acting like a victim of it. I could not keep complaining about being micromanaged while also choosing to work there. I could not keep being frustrated about not being promoted while also deciding this was still the best place for me. The realization hit me hard: I am choosing to be here. Which means I also need to choose how I am going to work with the people here and manage my relationships with them. ## Technical Visibility and Career Consequences Research from ITD World confirms that workplace visibility is essential for career advancement. Leaders must be able to notice and recognize efforts and contributions to consider individuals for mission-critical projects, promotions, and career growth. But victim mentality creates invisibility by design. When you treat your job like something happening to you, you make your work invisible. You wait instead of proactively showing what you have accomplished. You complain instead of translating your technical excellence into business language your manager understands. Before my realization, I was stuck in this exact pattern. I complained about not being promoted. I was frustrated that my projects were not gaining traction. I was upset about being micromanaged but felt like I could not do anything about it. I waited for my boss to ask what I was working on instead of proactively sharing updates. When I did share, I spoke in technical language they did not understand. I focused on the value I wanted to create, not the value that mattered to them or the business. I was treating my job like something that was happening to me. My boss was a problem I had to endure. The slow promotion timeline was unfair. The lack of recognition for my work was their failure to see my value. But here is the thing. I was choosing all of it. I just was not acknowledging that choice. ## The Research on Employee Agency A study published in PMC examining job autonomy and work meaning found that job autonomy satisfies employees' intrinsic needs by providing a sense of control and achievement, which keeps employees motivated and enthusiastic at work. When employees perceive higher work control, they develop a high sense of responsibility and positive attitudes when facing opportunities and adjustments. But you cannot access that autonomy while operating in victim mode. Victim mentality and employee agency are mutually exclusive. Research from the University of Birmingham Business School found that employees with higher autonomy reported positive effects on overall well-being and job satisfaction. The study emphasized that autonomy gives employees control over their work, which increases their sense of competence and mastery. Once I accepted that I was choosing to stay, I had to figure out how to work with the reality of that choice. ## Choosing Your Actions: The Communication Shift I changed how I shared updates. I started sending monthly presentations to my boss that contained a status update on every project with relevant data to show improvement. I stopped waiting for them to ask. I stopped speaking in technical language. I translated my work into outcomes that mattered to them and the business. This was the beginning of what I now call the Show Your Work framework. I did not have a name for it back then, but the way I started communicating became the foundation of that approach. Research on proactive communication and career advancement confirms this shift works. A study published in PMC found that managers evaluate employees' promotability by processing social information, including proactive communication behaviors. Research from California Lutheran University shows that communication skills connect directly to career advancement, with professionals who can frame ideas for different audiences often moving quickly into management roles. I also intentionally started having fewer one-on-ones with my micromanaging boss. If a situation required a meeting, I always brought a peer along. I created buffers and structures that let me work effectively within the constraints of that relationship. I could not choose whether my boss micromanaged. I could not control when I would get promoted. I could not force my projects to get more visibility. But I could choose how I communicated. I could choose how I structured my interactions. I could choose where I focused my time and energy. ## The Hard Truth About Choice and Consequences Here is what research on workplace autonomy misses: You get to choose your decisions, actions, and words. You do not always get to choose the consequences. When I chose to stay at my current job, it also meant I had to live with the consequences of a micromanaging boss and uncertainty about when I would get a raise or promotion. But I had to choose to find ways to work with that boss that did not feel negative for me. I had to find a way to be comfortable with my current career trajectory. That shift allowed me to focus my time and energy on things that were ultimately good for my career, even if it took longer to get there. I stopped wasting energy complaining about things I could not control. I started investing that energy in things I could control: how I communicated, how I positioned my work, how I built relationships with peers and stakeholders beyond my immediate boss. The micromanaging did not immediately stop, but improved with time. The promotion timeline accelerated as I improved how I shared information. Immediately though, I stopped feeling like a victim of those things. I felt like someone in control and making choices. Working within the reality of those choices. ## What This Means for Technical Leaders Monday Morning Research from Oak Innovation confirms that supporting employees means helping them shift from victim mentality to proactive engagement. But this research focuses on what managers should do. The truth is simpler: you need to do it yourself. If you are complaining about your boss, your job, or your company, ask yourself one question: "What choices are keeping me stuck with these frustrations?" Are you choosing to stay? Then you also need to choose how you are going to work with the reality of that place. You cannot control whether your boss micromanages, whether you get promoted on your timeline, or whether your work gets the recognition you think it deserves. But you can control how you communicate. You can control how you structure your relationships. You can control where you focus your energy. Or you can choose to look for a new job. Stop treating your job like something happening to you. Start treating it like something you are choosing. And then choose how you are going to work with it. **Research Sources:** - LaMarsh Global: "Navigating the Victim Mentality in the Workplace" - University of Birmingham Business School: "Autonomy in the workplace has positive effects on well-being and job satisfaction" - PMC: "Job Autonomy and Work Meaning: Drivers of Employee Job-Crafting Behaviors" - PMC: "Employee Proactive Personality and Career Growth" - ITD World: "Visibility at Work: Key to Career Advancement" - California Lutheran University: "Top 6 Communication Skills for Career Growth" - Oak Innovation: "Understanding And Supporting Employees With A Victim Mentality" <hr /> What choices are keeping you stuck with these frustrations? **You're great at the work. Let's make you impossible to ignore.** Ready to stop complaining and start choosing how you work with your reality? Let's talk about building your Show Your Work framework: [book a free call](/lets-talk)https://jessestaffordcoaching.com/blog/teams-junk-drawer-process-without-contexthttps://jessestaffordcoaching.com/blog/teams-junk-drawer-process-without-contextTL;DR: In 7 minutes, you'll learn how to identify which processes are organizational junk drawers and how to replace rigid checklists with clear...Wed, 11 Feb 2026 00:00:00 GMT**TL;DR:** In 7 minutes, you'll learn how to identify which processes are organizational junk drawers and how to replace rigid checklists with clear context, so your team moves faster and delivers better results. Research by Gary Hamel and Michele Zanini found that the U.S. economy loses approximately $3 trillion annually (nearly 17% of GDP) due to excessive bureaucracy and process bloat. Your organization is likely contributing to that number without realizing it. The problem is not that you have processes. The problem is you keep adding processes "just in case" without ever removing the ones that no longer serve you. Like a junk drawer filled with items you might need someday, your processes accumulate rules created for problems that happened once years ago and will never happen again. ## The Seven-Dumpster Wake-Up Call I learned this lesson the hard way when my manager decided our team needed a cleaner work environment. Once a quarter, we stopped everything and cleaned for a couple hours. It felt productive at the time. Organized space, organized mind, right? One quarter, we decided to truly declutter our entire building. We spent two solid weeks getting rid of everything we did not actually use anymore. Old machines. Outdated chairs. Stacks of paper. CDs and floppy disks. Obsolete electronics. Books that had not been opened in a decade. We filled seven 9-yard dumpsters. Seven. But the resistance we encountered was remarkable. At every turn, someone was holding onto something with the same justification: "I am not sure if I will need that." "Let me go through that first." "I was saving this for X situation that might come up." The moment that crystallized everything came when I found an engineer at their desk with a small trash can filled to the brim. Ten pounds of old thumb drives and circuit boards. They were methodically sifting through the pile, examining each piece, deciding what to keep. I said what seemed obvious to me: "It is already in a trash can. Just throw it away." Their response? "What if we get a field issue on one of those old games we released? What if we need one of these specific parts to test the problem or recreate the bug?" Eventually, they threw it all away. We never needed any of it. ## When I Finally Connected the Dots Years passed before I realized what that decluttering exercise was really showing me. Our organizational processes were exactly like the clutter in that building. A massive collection of everything we thought we might need to solve problems that may never come up again. Take our test case library as a perfect example. It had grown into a collection of every single bug we had missed over 20 years of operations. Every scenario that appeared once. Every edge case from a single project that shipped in 2006 and has been obsolete for a decade. We never went back and asked the critical questions: Can this specific problem still happen with our current technology? Does this particular rule still apply to how we work today? We just kept adding. More test cases. More processes. More checklists. More rules layered on top of rules layered on top of rules. ## The Hidden Cost of Process Without Context Here is what research tells us about what happens when organizations operate this way. A comprehensive study published in the Harvard Business Review calculated that 64% of organizations reported a Bureaucratic Mass Index (BMI) score of more than 70, indicating significant bureaucratic drag. Organizations with more than 5,000 employees averaged a BMI of 72, showing that process bloat scales with company size unless actively managed. The research found that employees in bureaucratic organizations spend an average of 28% of their time (more than one full day every week) on bureaucratic activities like preparing reports, attending unnecessary meetings, complying with internal requests, securing sign-offs, and interacting with staff functions that add minimal value. But here is what makes it worse: processes have a legitimate place in organizations. When they are minimal and deliberately paired with context about why they exist and what they accomplish, processes create valuable frameworks for consistency and quality. The friction emerges when you create process without context. When you hand your team a checklist without explaining the underlying goals, constraints, and decision-making principles. ## What Happens When Teams Only Have Checklists Your team stops thinking critically and starts following steps mechanically. They cannot adapt their approach when the actual situation does not match the predetermined checklist. They cannot make the contextually appropriate call for the specific problem they are facing right now. They escalate decisions to you because the process does not cover this particular scenario. So what do you do? You add another rule to cover that new scenario. Which creates more friction the next time an even slightly different situation appears. That organizational friction manifests everywhere. In how slowly your teams can deliver products to market. In how difficult it is for customers to work with you. In how many talented people leave because they feel like "cogs in a machine" rather than valued problem-solvers. Even Amazon, one of the most operationally sophisticated companies in the world, recognized they had developed this problem. In 2024, CEO Andy Jassy launched a "bureaucracy mailbox." This was an internal tool allowing employees to flag inefficiencies, redundant rules, and approval bottlenecks that were slowing down the organization. If Amazon needs to actively fight process bloat at their scale, your organization almost certainly has room for improvement. ## The Automated Testing Reality Check I am watching this pattern play out in real-time right now with my QA team. They are in the middle of rolling out an automated testing initiative, which is genuinely important work. But their instinct is to create comprehensive processes upfront to prevent every problem they think might possibly encounter down the road: - Detailed documentation requirements that must exist before any test can be released - Rigid specifications for how an automated test should be defined and structured - Multi-layer approval processes that need to be completed before implementation I keep redirecting them to a different approach: solve only the problems you actually encounter as they occur in practice. Create process only after you have enough completed work under your belt to understand what the general flow actually looks like in reality rather than theory. Do not burden your team with elaborate rules designed for hypothetical situations that may never materialize. Instead, burden them with rich context about goals, constraints, and principles so they can handle actual situations effectively when those situations inevitably show up. ## What Context Actually Looks Like in Practice I wrote about this principle extensively in my previous post, "[Stop Solving Your Team's Problems](/blog/hey-boss-stop-solving-teams-problems)." Your fundamental job as a leader is not to provide your team with the answer to every question. Your job is to clarify desired outcomes, define realistic boundaries, and share relevant information that helps them make better decisions. Providing context means ensuring your team genuinely understands: - **What you are ultimately trying to achieve** (the specific outcomes that matter) - **Why it matters in the broader picture** (how it connects to organizational success) - **What constraints actually exist** (not assumed constraints, but real limitations) - **How to make effective trade-offs** when real situations do not perfectly match any playbook Context gives people clear boundaries to work within. Not a rigid predetermined path they must follow regardless of circumstances. Costco has built their entire customer service reputation on this approach. They maintain a "Risk-Free 100% Satisfaction Guarantee" that allows customers to return most items at any time, with no receipt required because all purchases are linked to membership accounts. That represents remarkably minimal process overhead. But here is what makes it actually work in practice: Costco gives their employees clear context rather than elaborate rulebooks. The overarching goal is straightforward. Customer satisfaction. Employees have genuine authority to make judgment calls in service of achieving that goal. They do not need 47-page return policy manuals covering every conceivable edge case. They do not need to escalate to management for every slightly unusual situation. They understand the goal clearly. They make the call based on that understanding. That is minimal process deliberately paired with maximum context. And it scales remarkably well. ## Is Your Process a Junk Drawer? Four Diagnostic Questions Here are four questions to help you identify which processes have become organizational junk drawers: ### 1\. When was the last time this specific rule prevented the exact problem it was originally designed to solve? If you cannot remember a recent instance, or if the answer requires going back multiple years, you might be maintaining a process that solves a problem that no longer exists in your current reality. ### 2\. If we removed this process entirely tomorrow morning, what would actually break? If the honest answer is "nothing would break" or "I genuinely do not know what would happen," you have almost certainly identified a junk drawer process that exists purely through organizational inertia. ### 3\. Can the people actually following this process clearly explain WHY it exists? If your team members know they must follow certain steps but cannot articulate the underlying purpose or the problem being prevented, that is a significant red flag indicating process without context. ### 4\. Does this process solve a real constraint or an assumed constraint? Most organizational processes are built on assumptions about what might potentially go wrong in hypothetical scenarios. Those underlying assumptions need to be explicitly tested against current reality rather than simply accepted as eternal truths. ## What to Do Monday Morning When your team approaches you with questions about policy or process, pause before responding. Do not immediately answer with a rule from the handbook. Do not reflexively create a new checklist to cover this situation. Instead, ask them a simple question: "Based on our goals and the outcomes we are trying to achieve, what makes sense in this specific situation?" If they cannot answer that question effectively, share relevant information to help inform their decision-making. Provide context about constraints, priorities, trade-offs, and past learnings. Then ask again: "Given that additional context, what do you think is the best path forward today for this particular situation?" This approach accomplishes two valuable things simultaneously. First, it forces your team to engage in genuine thinking about the actual problem in front of them instead of simply searching for the predetermined rule to follow mechanically. Second, it reveals precisely where your team needs additional context. If team members consistently get stuck making the same categories of decisions, that signals they do not yet understand the underlying goals, constraints, or principles well enough to operate effectively with appropriate autonomy. Give them context and decision-making principles. Not another process to memorize. ## Stop Adding to the Organizational Junk Drawer Your processes are like that trash can full of obsolete thumb drives. Filled with rules you added "just in case" to prevent problems that happened once years ago and will almost certainly never happen again under current conditions. You never went back and systematically asked: Does this specific problem still exist in our current environment? Does this particular rule still serve us effectively given how we actually work today? You just kept adding more layers. More rules. More checklists. More approvals. More friction. Research from the London Business School estimates that reducing bureaucratic drag would add $3 trillion to economic output in the United States alone. That represents redeploying 21.4 million people from bureaucracy-feeding activities into genuine value-creating work. The solution starts with one decision: stop reflexively adding to the junk drawer. Start systematically giving your team the context, principles, and decision-making authority they need to think clearly for themselves. <hr /> **What process currently exists in your organization because of a problem that happened once, years ago, and probably will not happen again?** You are great at the work. Let's make you impossible to ignore. Want help reading between the checklists and start solving real business problems? Visit [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/observation-framework-leaders-get-called-visionaryhttps://jessestaffordcoaching.com/blog/observation-framework-leaders-get-called-visionaryVisionary leadership isn't about predicting the future. It's about observing the present more carefully than everyone else.Tue, 27 Jan 2026 00:00:00 GMTVisionary leadership isn't about predicting the future. It's about observing the present more carefully than everyone else. Early in my career, I won an award for being a visionary team member. The recognition came from work I did improving our localization process. Teams were spending months doing manual translation work. They went through game content line by line, identifying text that needed translation, then retrofitting it all in. It took forever. Most teams put it off until the end of projects, which made it worse. I started pitching ideas to fix it. Built a prototype. Ran the numbers on what it was costing us. I talked to my boss. Then his boss. Then people in other departments. Anyone who might care about months of wasted manual work. It took dozens of conversations before someone finally said yes and allocated resources. They called it visionary. It wasn't. I just watched people do tedious work and refused to accept "that's just how it is." **Technical leaders who solve problems others ignore get labeled visionary. But that label misses what actually happened.** ## Why the "Visionary Leader" Label Is Misleading The problem with calling someone visionary is that it implies a mystical ability to see the future. It makes their success seem unrepeatable. Like you either have the gift or you don't. That is wrong. And it stops technical leaders from recognizing they can do the same thing. When I [show my work proactively](/blog/stop-managing-up-start-showing-work) or [build relationships that drive career growth](/blog/professional-relationships-drive-career-growth), I'm not doing anything mystical. I'm following a repeatable process that anyone can learn. The same applies to the leaders we call visionary. They're not predicting. They're observing. ## What Steve Jobs and Jeff Bezos Actually Did **Steve Jobs didn't predict the iPhone.** In his 2007 presentation introducing the device, Jobs focused on the problem with existing smartphones: "They all have these keyboards that are there whether or not you need them to be there." [The Singju Post](https://singjupost.com/steve-jobs-iphone-2007-presentation-full-transcript/) He saw people frustrated with fixed keyboards on devices that needed flexible interfaces. He had the resources and authority to fix it. **Jeff Bezos didn't predict e-commerce dominance.** He made a methodical list of 20 products that could be sold online, narrowed it to five promising options, then chose books for a practical reason. As he explained in a 1997 interview, books had over 3 million titles worldwide, compared to 200,000 music CDs. [CNBC](https://www.cnbc.com/2024/01/13/in-1997-jeff-bezos-said-why-he-chose-books-to-sell-on-amazon.html) The selection advantage made the decision obvious. Neither Jobs nor Bezos saw around corners into the future. They watched the present more carefully than their competitors. Then they refused to quit until they fixed what they saw. ### The Real Skill Behind "Visionary" Success The difference between me and Jobs isn't vision. It's scale and authority. We both saw problems others had normalized. We both had conviction about what better looked like. We both built proof of concepts. I had to pitch mine dozens of times to get resources allocated. He could greenlight the iPhone. But the skill is identical: relentless observation of how work actually happens. This matters for technical leaders because you don't need executive authority to start observing. You can begin this process tomorrow, [leading without formal authority](/blog/confident-leaders-treat-every-decision-hypothesis), and still create the momentum that gets you labeled visionary. ## The Observation Framework: Five Steps That Look Like Vision Here is the actual process behind what people mistake for visionary thinking. ### Step 1: Watch People Work (Really Watch) Not in theory. Not in status meetings. Watch the actual work. I spent time sitting with localization teams. I watched them open files. I watched them copy and paste. I watched them manually search for text strings. I watched the same steps repeat across every project. Most leaders skip this step. They assume they know how work happens because they used to do it. Or because people described it in a meeting. But work evolves. Workarounds develop. What you think is happening and what is actually happening diverge over time. Block time to observe. Sit with someone on your team while they do their work. Ask them to narrate what they're doing. Do not interrupt. Do not fix. Just watch and listen. ### Step 2: Notice the Friction They've Normalized Listen for specific signals that indicate normalized friction: - The sighs when they click through repetitive steps - The "I wish this would..." comments - The workarounds they've invented because the official process doesn't work - The manual work that feels like "just part of the job" - The processes that used to make sense but don't anymore When I watched localization teams, I heard: "This takes forever but there's no other way." That phrase is the sound of normalized friction. They'd accepted months of manual work as unchangeable reality. Your job is to refuse that acceptance. To question what everyone else has stopped questioning. ### Step 3: Build Proof It Could Be Different Do not go straight from observation to pitching. Build something first. I built small prototypes showing automated localization could work. Not production-ready systems. Just enough to demonstrate the concept wasn't fantasy. Then I gathered data: - How much time the current process took per project - How much that time cost in salary and opportunity cost - How much we could save with the new approach - What quality improvements we might see Data transforms "I have an idea" into "Here's what I've proven is possible." This step is where [getting manager approval](/blog/get-manager-approval-engineering-side-projects) becomes easier. You're not asking them to believe in your vision. You're showing them proof. ### Step 4: Tell the Story Until Resources Are Allocated I did not pitch the localization improvement once and give up when someone said no. I brought it to different people. I refined the story based on what resonated. I showed the business case from multiple angles: - Time saved (for engineering managers who cared about velocity) - Cost reduced (for directors who cared about budgets) - Quality improved (for product managers who cared about user experience) The story matters because resources don't get allocated to ideas. They get allocated to solutions to problems that matter to decision-makers. Translate your observation into their language. Show them why the friction you noticed costs them something they care about. ### Step 5: Do Not Quit After the First No Persistence is what separates people who get called visionary from people who had a good idea once. It took me dozens of conversations before someone allocated resources to the localization project. Dozens. Not three. Not five. Dozens. Most people quit after the first no. Some quit after the third. The ones who get labeled visionary are the ones who keep going until someone says yes. This doesn't mean being annoying. It means: - Finding different angles to present the same solution - Building more proof as you go - Bringing the idea to different decision-makers - Timing your pitches strategically - Showing early wins from small experiments [Professional relationships](/blog/professional-relationships-drive-career-growth) make this easier. When you've built credibility across your organization, persistence looks like determination rather than desperation. ## Why Technical Leaders Need This Framework **You're already doing hard work.** Infrastructure migrations. System redesigns. Technical debt reduction. Security improvements. All of it matters. But if that work stays invisible, you don't advance. You don't get the resources you need. You don't get recognized as someone who drives business value. The Observation Framework gives you a repeatable process for: - Identifying problems others have stopped seeing - Building the case for solving them - Getting resources allocated without executive authority - Building a reputation as someone who moves things forward That reputation is what people mistake for vision. It's not. It's observation plus persistence plus storytelling. ## What This Looks Like in Practice Jobs didn't wake up one day and predict the iPhone. He spent years watching people use technology. He noticed the friction of fixed keyboards on smartphones. He built prototypes. He persisted through technical challenges and internal skepticism. By the time he announced the iPhone, he'd already solved the hard problems through observation and iteration. Bezos didn't predict e-commerce. He read growth projections, made lists, analyzed selection advantages. He started with books because the numbers made sense. He built proof. He kept going when others said online shopping would never work. His "vision" was actually careful analysis of what customers needed combined with relentless execution. I didn't predict that localization could be easier. I watched teams suffer through manual work. I built prototypes showing a better way. I made the business case. I kept pitching until resources were allocated. The "visionary" award came after the work, not before it. Same pattern across all three examples: 1. Watch people work (really watch, don't assume you know) 2. Notice the friction they have normalized 3. Build proof it could be different 4. Tell the story until resources are allocated 5. Do not quit after the first no ## Your Action Plan: Starting This Week Block two hours this week. Watch someone on your team do their actual work. Not a meeting about the work. Not a status update. Sit with them while they do the work. Ask them to narrate what they are doing. Listen for the sighs, the workarounds, the "I wish this would..." comments. Do not fix anything yet. Just watch and listen. Notice what they have learned to accept as "just how it is." That is where your next "visionary" idea is hiding. It is not in predicting the future. It is in refusing to accept the friction everyone else has normalized. Then follow the framework: - Build a small proof of concept (even if crude) - Gather data on the current cost and potential savings - Tell the story to multiple people in different ways - Keep refining based on feedback - Do not stop after the first no You do not need executive authority to start this process. You do not need to be anointed as visionary. You just need to see what others have stopped seeing and refuse to accept it. The "visionary" label will come later, after you've done the work. And by then you'll know it was never about vision at all. <hr /> **What friction has your team normalized that you stopped noticing? What would you see if you watched them work for two hours this week?** You're great at the work. Let's build the bridge. Ready to turn observation into action and build your reputation as someone who moves things forward? Let's talk about what you're seeing and how to build the case: [book a free call](/lets-talk)https://jessestaffordcoaching.com/blog/use-emotions-leader-without-letting-controlhttps://jessestaffordcoaching.com/blog/use-emotions-leader-without-letting-controlTL;DR: In 4 minutes, you'll learn how to stop suppressing emotions at work and start naming them calmly to build trust, improve communication, and turn...Sun, 25 Jan 2026 00:00:00 GMT**TL;DR:** In 4 minutes, you'll learn how to stop suppressing emotions at work and start naming them calmly to build trust, improve communication, and turn frustration into actionable feedback. When you suppress emotions to stay professional, your team picks up on it anyway. The anger leaks out sideways: shorter responses, blame in meetings, teams avoiding each other. **Research from Daniel Goleman shows that emotional intelligence accounts for nearly 25% of leadership performance variability**, a massive effect. Yet most leaders still believe hiding emotions is professional. It's not. It creates exactly the problems you're trying to avoid. I had a manager whose team built games. By the time I got involved, he was complaining about the server team to anyone who would listen, his engineers were doing the same, and the two teams couldn't be in the same room without mocking each other afterward. They worked together constantly. Had to. The games needed the backend infrastructure. Except the server team kept changing APIs without telling anyone. My manager's team would find out when a game stopped working. Or when the product team asked why they weren't using a new feature that had apparently launched weeks ago. Or when the server team complained the games were late because they had nothing to test against. Debugging took days. Sometimes his engineers spent a week reverse engineering what changed because there was no documentation. No changelog. No heads up. My manager was furious. But he never said it to the server lead directly. He said it to me. To his team. He complained about the server team in meetings with other departments. His team picked up on it and did the same. The server team fired back through product management and upper management. Both sides blamed each other for every delay. They stopped meeting. The only time they were in the same room was when another department forced it. Then they would sit through the meeting and mock each other afterward. Everything became endless email chains that dragged on for weeks until someone just gave up and figured it out themselves. The relationship was poisoned. ## Why Suppressing Emotions at Work Backfires The old adage says emotions don't belong at work. Stay unflappable. Be composed. Don't let them see you sweat. It sounds like leadership advice. But research shows it's actually creating three critical problems in your organization. ### Your Team Detects Suppressed Emotions Anyway You think you're hiding frustration or disappointment. You're not. Your tone shifts. Your body language changes. You get quieter in meetings or give shorter responses in Slack. Your team notices immediately. They just don't know why. Research published in Leader to Leader by Daniel Goleman found that emotions are highly contagious in work groups, particularly from leaders to their teams. When leaders suppress emotions, team members sense the disconnect and fill the gap with their own (usually negative) assumptions. ### Suppression Creates Distance and Destroys Psychological Safety When you refuse to acknowledge what you're feeling, you appear robotic. Disconnected. Your team can't read you accurately, so they start guessing about your emotional state. This guessing game erodes what Harvard researcher Amy Edmondson calls "psychological safety", the belief that you won't be punished for speaking up. [Google's Project Aristotle](https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2020.01581/full), which analyzed over 250 team variables, found psychological safety was the single most important factor in high-performing teams. More important than talent, resources, or structure. Yet only 47% of employees worldwide describe their workplaces as psychologically safe. Emotional suppression is a major contributor to that gap. ### It Blocks Honest Communication Across Your Organization If you won't name what's bothering you, your team won't either. They learn to suppress their own frustrations. Problems go unspoken. Resentment builds. Teams start avoiding each other instead of solving things together. As discussed in "Immunity to Change" by Robert Kegan and Lisa Lahey, even professions built on human connection (like social work) often develop cultures of emotional suppression. The irony is that suppressing emotions in work that requires human connection actually undermines the very relationships you need to be effective. This is how cross-functional collaboration dies. Not because of bad processes, but because leaders model emotional suppression and teams follow suit. ## The Difference Between Suppressing and Regulating Emotions Professionalism is not suppressing emotions. It's regulating them. There's a critical difference that most leadership advice misses. ### What Emotional Regulation Actually Looks Like I coached my manager through a conversation with the server team lead. He was resistant at first. By that point, he figured the relationship couldn't get worse anyway. The conversation was simple. He said something like: "I need to be honest. I get frustrated when API changes happen without documentation, because my team spends days debugging what turned out to be an undocumented change. Can we set up a notification system before changes go live?" Calm. Specific. Named the emotion and explained why it mattered. The server lead adjusted immediately. They set up a Slack channel for API change notifications. Started documenting breaking changes before deployment. It took time, but the next couple projects went more smoothly. The constant anger started fading. ### The Three-Part Framework for Using Emotions in Leadership Here's what made that conversation work, broken down into a framework you can use: **1\. Name the emotion calmly** "I get frustrated when..." or "I'm disappointed that..." said in a collected tone shows you're aware of your emotional state. You're not hiding it or pretending it doesn't exist. But you're also not yelling or visibly angry. [Research on emotional intelligence in leadership](https://journals.sagepub.com/doi/10.1177/15344843251342689) shows that leaders who can identify and articulate their emotions are viewed as more trustworthy and effective by their teams. **2\. Explain the specific cause** Don't just say "I'm frustrated." Get specific about what behavior or outcome is causing the reaction. "I'm frustrated because API changes are undocumented and my team spends days debugging phantom issues" gives the other person actionable information. **3\. Suggest a path forward** "Can we set up a notification system?" turns the emotion into a collaborative problem-solving conversation instead of a complaint or attack. This is using emotion as part of your response, not letting emotion dictate your response. ## How to Turn Emotions Into Leadership Data When you feel upset or frustrated as a leader, that emotion is information. Don't suppress it. Don't react from it. Use it. ### The Pause-and-Identify Process Pause when you feel strong emotion. Do not respond immediately. Ask yourself: Why am I upset specifically? Not "this situation is bad." Get granular. What exact behavior or outcome is triggering this emotional response? That specificity transforms emotion into actionable feedback. "I'm frustrated" tells you nothing useful. "I'm frustrated because undocumented API changes are causing my team to waste days on reverse engineering" tells you exactly what needs to change. ### Why Emotional Intelligence Matters More Than IQ for Technical Leaders Research by EQ provider TalentSmart, [cited by Harvard Business School](https://online.hbs.edu/blog/post/emotional-intelligence-in-leadership), found that emotional intelligence is the strongest predictor of workplace performance. 71% of employers now value emotional intelligence over technical skills when evaluating candidates for leadership roles. For technical leaders, this creates a unique challenge. You built your career on technical excellence. But as you move into leadership, the problems that matter most are human problems: communication gaps, team dynamics, cross-functional friction. Your frustration about invisibility, miscommunication, or being misunderstood is data. It's telling you that something in how you're communicating needs to change. Suppressing that frustration means you miss the signal. Exploding from it damages relationships. Naming it calmly and investigating the cause? That's how you identify the actual problem and fix it. ## The Real Cost of Emotional Suppression in Organizations Let's be direct about what happens when leaders suppress emotions instead of regulating them. ### Best Case Scenario: Reduced Psychological Safety and Innovation Your team stops sharing concerns with you because they can't read how you'll react. They see you suppress your own emotions and learn that emotional honesty isn't safe here. Amy Edmondson's research shows that innovation and problem-solving both require psychological safety. When leaders suppress emotions, [teams stop engaging in the interpersonally risky behaviors](https://www.sciencedirect.com/science/article/abs/pii/S1053482217300013) that drive learning and improvement: voicing concerns, admitting mistakes, asking for help, experimenting with new approaches. ### Worst Case Scenario: Bureaucratic Self-Protection They avoid making decisions. They find ways not to take responsibility. They create processes, approval chains, and red tape to protect themselves from your unpredictable emotional reactions. This is how businesses get bureaucratic. Not because someone designed bad policies. Because people got afraid of their leader's unspoken emotions and built protective barriers. If your team can't trust that you'll name what's bothering you instead of letting it simmer and leak out sideways, they'll start managing around you. And you'll wonder why everyone needs three approval levels to make simple decisions. ## What Monday Morning Looks Like Next time you feel frustrated or disappointed about something at work, use this two-step process: ### Step 1: Pause and Identify the Specific Cause Do not respond immediately when you feel strong emotion. Take time to ask yourself: Why am I upset specifically? What exact behavior or outcome is causing this reaction? Write it down if that helps. Get concrete. Move from "I'm frustrated with the marketing team" to "I'm frustrated because marketing committed to a launch date without checking technical feasibility, and now my team is being blamed for delays we predicted." ### Step 2: Name the Emotion Calmly in Your Next Conversation In your next conversation with the relevant person, say: "I'm frustrated that \[specific thing\] because \[specific impact\]." Stay collected. This is not venting. This is providing clarity about what's not working so you can collaborate on fixing it. Watch what happens. The person you're talking to won't think you're unprofessional. They'll think you're honest. And your team will learn that naming problems is safe in your organization. ## The Line Between Using and Being Ruled By Emotions Here's the critical distinction that determines whether emotional honesty strengthens or damages your leadership: **Using emotions as part of your response:** You can explain what you're feeling and why. "I'm frustrated because \[specific behavior\] is causing \[specific impact\]. Can we \[specific solution\]?" **Being ruled by emotions:** You yell, explode, or respond without explanation. Your team can't predict your reactions. They start avoiding situations that might trigger you. The first builds trust and solves problems. The second destroys psychological safety and creates bureaucratic self-protection. You're not supposed to be unflappable. You're supposed to be human. The question is whether you're using your emotions as information about what needs to change or letting them make decisions for you. <hr /> ## Additional Resources on Leadership and Emotional Intelligence For further reading on leadership effectiveness and emotional intelligence: - [Daniel Goleman on Emotional Intelligence and Leadership](https://onlinelibrary.wiley.com/doi/full/10.1002/ltl.20813) - Research showing EI's impact on team performance - [Amy Edmondson on Psychological Safety](https://hbr.org/2023/02/what-is-psychological-safety) - How psychological safety drives team learning and innovation - [Google's Project Aristotle Findings](https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2020.01581/full) - Research on what makes teams effective <hr /> **What emotion are you suppressing right now that your team already knows about?** You're great at the work. Let's build the bridge. Ready to lead with clarity instead of suppression? Let's work on turning those emotions into actionable feedback together: [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/following-process-means-missing-goal-engineeringhttps://jessestaffordcoaching.com/blog/following-process-means-missing-goal-engineeringTL;DR: In 4 minutes, you'll learn how to stop treating company processes as the goal and start giving your team the context they need to deliver...Sat, 24 Jan 2026 00:00:00 GMT**TL;DR:** In 4 minutes, you'll learn how to stop treating company processes as the goal and start giving your team the context they need to deliver business value when plans inevitably fall apart. ## The Problem with Process-First Leadership Reed Hastings, Netflix's co-founder, built one of the most successful tech companies by doing something counterintuitive: [removing controls and leading with context instead of process](https://www.shortform.com/blog/contextual-leadership/). His philosophy was simple. If you give employees context about goals and constraints, they make better decisions than if you force them through rigid procedures. Most engineering and systems leaders do the opposite. They build teams around procedures. Documentation requirements. Approval chains. Sign-off processes. These become "the rules of working with my team." And when things go sideways (which they always do), those same leaders try to force the anomaly back into the existing process. I learned this the hard way during a game launch that nearly failed because we followed the rules. ### When the Checklist Became More Important Than the Contract We were launching games into a new market. Contractual deadline. Non-negotiable. But our company's standard testing, release, and compliance processes would make us miss it by weeks. One individual contributor kept pushing back. "We can't skip the documentation steps. It's against policy." Instead of arguing, I went to the senior manager above them. Not to complain. To understand. "Help me understand what you need to make this work. Here is the goal and why it matters." **Here is what I discovered:** Most of the documentation existed because something happened once, years ago. We were terrified of repeating that mistake. But we had already fixed the root cause when it first happened. The checklist remained even though the problem was gone. We condensed three approval meetings into one email thread. We kept the security review (legal boundary) but eliminated the redundant sign-offs (process theater). We launched on time. And I learned that [leadership is not about following processes, it is about making judgment calls](https://triplecrownleadership.com/judgment-in-leadership/) that serve the business goal. ## Why First-Level Managers Default to Procedure According to research on leadership judgment, most managers treat processes as decision-making shortcuts. They follow the rules because following rules feels like competence. [The problem is that heuristics-based judgment](https://www.sfmagazine.com/articles/2022/november/how-leaders-can-use-better-judgment) only works when conditions match expectations. When conditions change, the checklist fails. Here is what happens: **Managers assume the process protects them.** If they follow every step and still miss the deadline, they can say "we did everything right." Leadership does not reward effort. Leadership rewards outcomes. **Teams escalate decisions they should make themselves.** Without context, they default to asking permission for things that do not need approval. This creates bottlenecks. (I wrote about this in [managing former peers](/blog/im-managing-my-former-peers), where I avoided making calls because I thought collaboration meant consensus.) **Anomalies get forced into existing procedures.** A client needs something urgent. A system fails in an unexpected way. A market shifts. The team tries to fit the square peg into the round hole because "that is how we handle these situations." This is learned helplessness. And it is costing your team velocity, innovation, and the ability to respond when the world does not cooperate. ## The Bridge Between Rules and Sound Judgment **Context over process.** That is the bridge. When your team understands the goal, the business value that needs to be delivered, and the actual constraints, they can make smart decisions without waiting for permission. When they do not understand context, they treat the checklist as the goal. They miss deadlines because they assumed completing steps was more important than delivering value. ### What Leadership Scaffolding Actually Means [Noel Tichy and Warren Bennis argue that judgment is the single most important leadership skill](https://www.sigmaassessmentsystems.com/leadership-judgment/). But judgment does not mean "make it up as you go." It means understanding the scaffolding, the non-negotiables that actually matter. Here is the scaffolding: **Legal and ethical boundaries.** We could not skip the security review. That was a legal requirement. No amount of deadline pressure changes that. **Company policies that exist for real reasons.** Not "we have always done it this way" but actual risk mitigation or strategic alignment. **Your own values and principles.** The lines you will not cross, even under pressure. **Clarity on the goal and the business value.** What success actually looks like, not just what tasks need completing. **Information about the environment and constraints.** What your team is working within, what has changed, what matters now. Everything else is judgment. Not a playbook. Not step-by-step instructions. We could not skip the security review. But we could condense the approval process. The goal (protect the company from risk) stayed the same. The business value (launch on time, meet the contract) was protected. We removed the process that did not serve either. ## What Most Engineering Managers Do Instead (And Why It Backfires) Research on [participative leadership and decision-making](https://www.researchgate.net/publication/232538639_Leadership_and_the_Decision-making_Process) shows that managers struggle with knowing when to involve teams and when to make calls themselves. Most default to one of two extremes: **They escalate everything to leadership.** Waiting for permission. Covering themselves by getting sign-off. This slows delivery and signals to your team that you do not trust your own judgment. **They muscle through with the existing process.** Working harder instead of working differently. Accepting that they will miss the deadline because "we followed the rules." Neither approach delivers the outcome leadership actually needs. ### The Question That Changes How You Lead When you face your version of this (launch deadline, urgent client need, system failure), do not ask "what is the process?" Ask: **"What is the goal, and what do I actually need to deliver it?"** Then give your team the same clarity. Not just steps to follow, but the context that lets them make smart calls when the steps do not fit. This connects directly to what I wrote about in [communication and building influence across your organization](/blog/peers-control-success-build-those-relationships). You cannot build that influence if you are stuck waiting for permission or hiding behind procedures. ## How to Lead with Context Starting Monday **Stop looking for the next checkbox to check.** Instead, answer these three questions before you pull out the process manual: 1. **What is the goal?** Not the task list. The actual business value that needs delivering. 2. **What do I actually need to deliver it?** Which parts of the process serve the goal, and which parts are theater? 3. **What context does my team need to make smart calls themselves?** Legal boundaries, company policies, strategic goals, current constraints. Then communicate that context. Not once. Repeatedly. In different ways. (I call this "[7 times, 7 ways](/blog/hidden-cost-workplace-assumptions-unspoken-expectations)" because people need multiple exposures before information sticks.) **Your team will deliver faster.** They will make better decisions. And when the unexpected happens (and it will), they will not freeze waiting for you to tell them which checkbox to check next. They will build the bridge between following the rules and delivering the outcome leadership actually rewards. <hr /> **What process are you following right now that no longer serves the actual business goal?** *You're great at the work. Let's build the bridge.* Ready to lead with context instead of checklists? Let's talk about how to give your team the clarity they need to make decisions without waiting for permission every time something does not go according to plan. [book a free call](/lets-talk)https://jessestaffordcoaching.com/blog/get-manager-approval-engineering-side-projectshttps://jessestaffordcoaching.com/blog/get-manager-approval-engineering-side-projectsLearn how to get manager approval for engineering side projects at work. A proven framework for getting buy-in for technical improvements that benefit...Mon, 05 Jan 2026 00:00:00 GMTLearn how to get manager approval for engineering side projects at work. A proven framework for getting buy-in for technical improvements that benefit your team and advance your career. I knew our translation integration process was broken. Everyone on the team knew it. We spent 800 hours per game manually configuring translations, and it delayed our releases by two weeks every single time. I had an idea to fix it. A tool that could automate most of the work. I pitched it to my manager. He said no. "Focus on your game. We need you to finish early." The logic made no sense to me. Other disciplines weren't going to finish early anyway. And even if we did, there would just be another game waiting. Why not fix this problem for everyone, forever? So I did two things. I worked on the tool anyway without telling anyone. And I kept asking. My manager. Their manager. Their manager's manager. It took almost a year before leadership finally cared enough about the translation problems to greenlight my project. By then, I had a proof of concept that saved 50% of our translation work. When it became a full project with dedicated time, we hit 90% savings within another year. Today, it's a flagship internal process with a dedicated team. It saves the company thousands of hours annually. But here's what I learned through that frustrating year of rejection: **I was asking the wrong question. And my manager was answering a question I never actually asked.** ## Why Engineering Side Projects Get Rejected (And Why Google's 20% Time Failed) When you ask to work on a side project, you think you're proposing innovation. Your manager thinks you're asking to abandon ship. This disconnect is why even the most famous side project policy in tech history ultimately failed. Google's "20% time" launched Gmail, Google News, and AdSense. Products that generated billions in revenue and transformed how millions of people use the internet. But by 2013, [the program was effectively dead](https://en.wikipedia.org/wiki/Side_project_time). Former Google employees described it as "120% time" because engineers could only work on passion projects by putting in extra hours beyond their regular workload. Only about 10% of engineers consistently used the program, according to internal reports. What happened? As Google grew and quarterly earnings pressure mounted, managers prioritized immediate deliverables over speculative innovation. Engineers struggled to balance core responsibilities with side projects. There was no formal tracking, no resource allocation, and no protection for the time. The same pattern plays out in engineering teams everywhere. Side projects sound great in theory. But when your manager is measured on shipping features and hitting deadlines, your proposal to work on something else sounds like a threat to their goals. Understanding this dynamic is the first step to changing the conversation. ## The Communication Gap That Triggers Automatic Rejection You say: "I want to build this tool that could help everyone." They hear: "I want to work on something that isn't your priority while you're trying to hit your goals." You think: "This will save us so much time in the long run." They think: "I need you focused on what's due next quarter, not a speculative project with uncertain payoff." You believe: "I'm proposing valuable innovation." They believe: "You're asking for permission to not do your actual job." This is the communication gap that kills engineering side projects at work before they even start. You're excited about the solution. Your manager is worried about protecting their current commitments. [Most communication problems in leadership](/blog/communication-gap-triggers-micromanagement-close) stem from this same root cause. You think you're being clear. But your message gets filtered through your manager's context, priorities, and pressures that you may not even see. Neither of you is wrong. You're just solving completely different problems. ## What I Got Wrong About Getting Buy-in for Technical Improvements Looking back at my translation tool saga, I made four critical mistakes that extended my timeline from weeks to a full year. ### Mistake 1: I Pitched My Solution Instead of Defining Their Problem My manager already had a way to handle translations. It was painful and slow, but it was predictable. They could plan for it. They understood the resource requirements. My new tool? Completely unpredictable. Unproven. A risk to the schedule. I should have led with: "Translation integration costs us 800 hours per game. It blocks other teams from starting their work. It's making us miss certification windows and delaying releases. Here's what it's specifically costing you." Why the problem exists. Then what you can do about it. When you start with the solution, managers evaluate it as a nice-to-have. When you start with the problem, they evaluate it as a must-fix. ### Mistake 2: I Didn't Quantify the Cost of the Current Approach "Everyone hates this process" isn't data. "We spend 800 hours per game on translation integration and it delays release by two weeks" is data your manager can actually use. Managers care about things that affect their goals and their metrics. Show them how the current problem is already hurting what they're measured on. Make it concrete. If you can't quantify the cost, you haven't done enough research to pitch the solution yet. ### Mistake 3: I Framed It as Either/Or Instead of Both/And I presented it as: "Can I work on this instead of my game?" I should have framed it as: "I can do this without impacting the game schedule. Here's the 5 hours per week I have available because other disciplines are blocked waiting on their work. Here's the checkpoint at one month where we evaluate if it's working. If it's not delivering results by then, I stop." Make it concrete. Remove the perceived risk. Give them an off-ramp. [Treating decisions like testable hypotheses](/blog/confident-leaders-treat-every-decision-hypothesis) instead of permanent commitments makes it easier for managers to say yes to experiments. ### Mistake 4: I Fought at the Wrong Organizational Level My direct manager didn't care enough about translation integration. It wasn't their problem to solve. Their boss's boss cared deeply. Studio-wide efficiency? Reducing bottlenecks across multiple teams? That mattered at their level. Sometimes the thing that's not important to your manager is absolutely critical to someone two levels up. Work with your manager to escalate to the person who actually owns the problem you're trying to solve. Going around your manager damages trust. Working with them to find the right stakeholder builds it. ## The Framework That Actually Gets Engineering Side Projects Approved After coaching dozens of engineers through this exact challenge, here's the framework that consistently works for getting buy-in for technical improvements. ### Step 1: Define the Problem, Not Your Solution Write down what's broken. Be specific. What does it cost in time, money, missed deadlines, or team morale? Who does it affect? How often does it happen? Your manager needs to care about the problem before they'll care about your solution. If you can't make them feel the pain of the current state, they won't invest in changing it. ### Step 2: Show How It Protects Their Goals Your manager is measured on something. Shipping features on time. Reducing bugs. Improving team velocity. Hitting revenue targets. Show them how fixing this problem helps them hit their targets. Or at the very minimum, show them it won't hurt their ability to deliver. Connect your technical improvement directly to their business priorities. This is how you transform a side project into strategic work. ### Step 3: Make It Low-Risk With Clear Checkpoints Give them a specific time commitment. A clear checkpoint to evaluate progress. An off-ramp if it's not working. "I'll spend 5 hours per week for the next month building a proof of concept. At the end of the month, we'll review the results together. If it's not showing measurable improvement, I stop and return full focus to primary projects." This removes the fear that you'll disappear down a rabbit hole for six months with nothing to show for it. ### Step 4: Create Visuals That Make the Problem Concrete I wish I had done this earlier in my translation tool journey. A simple diagram showing current state versus future state makes the problem real in a way that words never can. Show the workflow. Show the bottlenecks. Show where time gets wasted. Then show what it could look like. Visuals make abstract technical concepts concrete for non-technical stakeholders. They also force you to think more clearly about the actual problem you're solving. ### Step 5: Find the Right Stakeholder If your manager doesn't care about the problem, ask them who does. Work with them to escalate. "I understand this isn't your top priority right now. Who in the organization would care most about reducing our translation overhead? Can you help me get 15 minutes with them to present this?" This approach respects your manager's time and priorities while still moving your initiative forward. ## The Language That Changes the Conversation The difference between getting shut down and getting approval often comes down to how you frame the initial ask. **Weak framing:** "Can I work on this side project to improve our translation process?" **Strong framing:** "Translation integration is costing us 800 hours per game and delaying releases by two weeks. I think I can cut that by 50% without impacting my current project schedule. Can I spend 5 hours a week for the next month building a proof of concept? If it's not working by then, I'll stop." **Weak framing:** "I have this cool idea for a tool that could help the team." **Strong framing:** "Here's the problem: we're spending 40 hours per sprint on manual configuration that could be automated. Here's what it's costing us: delayed feature delivery and increased bug rates. Here's my proposal: 6 hours per week for 6 weeks, with a demo at week 3. Does this solve a problem you care about? If not, who should I talk to?" **Weak framing:** "Why won't management let us innovate?" **Strong framing:** "I want to make sure I'm solving the right problems. What are the top three things keeping you up at night right now? If this isn't one of them, let's talk about how to get this in front of someone it matters to." Notice the pattern. You're not asking for permission to do less work. You're proposing a solution to a problem that's already costing the team, with a clear plan and defined checkpoints. ## Why Engineering Side Projects Matter for Your Career The research on career development is clear. [Professional relationships drive career advancement](/blog/stop-optimizing-past) more than technical skills alone. But side projects serve a different critical function. Side projects are where real innovation happens. They're where you develop skills that set you apart. They're where you build things that make your impact visible across the organization. According to research on workplace innovation, companies that successfully implement side project programs see significant benefits. [Atlassian's "ShipIt Days"](https://builtin.com/software-engineering-perspectives/20-percent-time) resulted in major improvements to their core products. Over 60% of side project ideas eventually made it into production at companies that tracked outcomes systematically. But more importantly for your career, side projects are how you demonstrate leadership before you have the title. When you identify a problem, build a solution, and get organizational buy-in, you're showing exactly the skills companies look for in senior engineers and engineering managers. The ability to see beyond your immediate tasks, identify systemic problems, and drive solutions through an organization is what separates individual contributors from leaders. ## What to Do Next Week Before your next conversation about a side project or technical improvement: **Monday:** Define the problem, not your solution. Write down what's broken, what it costs, and who it affects. Make it concrete with real numbers. **Tuesday:** Research how this problem impacts your manager's goals. Connect your proposed improvement to their priorities and metrics. **Wednesday:** Outline your low-risk proposal. Specific time commitment, clear checkpoints, defined off-ramp. Make it easy for them to say yes to an experiment. **Thursday:** Create a simple visual. Current state versus future state. Show the bottlenecks and the proposed improvements. **Friday:** Identify the right stakeholder. If your manager doesn't own this problem, figure out who does. Prepare to work with your manager to escalate appropriately. Then have the conversation. Not "Can I work on this cool thing?" but "Here's a problem costing us X. I can fix it with Y time commitment without impacting Z. Here's how we'll know if it's working. Does this solve a problem you care about?" ## The Real Value of Side Projects Side projects aren't time wasted. They're where innovation comes from. They're where you develop skills that accelerate your career. They're where you build systems that multiply your impact. But your manager can't see any of that if you're asking them to choose between your idea and their goals. Show them it's not a choice. Show them it's both. The translation tool I fought for over that frustrating year became one of the most impactful things I built in my entire time at that company. It saved thousands of hours. It reduced stress for dozens of teams. It became a model for how we approached process improvement across the studio. But I could have gotten there in one month instead of twelve if I had known how to frame the conversation correctly. You already know how to build the solution. Now you know how to get permission to build it. <hr /> **What engineering side project are you trying to get approved right now? What's the real problem you're trying to solve?** Share in the comments below. **You're great at the work. Let's make it visible.** If you're struggling to get buy-in for ideas that could make real impact, or if you want to improve how you communicate technical value to leadership, let's talk. I help tech and systems leaders communicate their value and grow without burning out. ### [Schedule a conversation](/lets-talk) <hr /> ## Related Articles - [Hey Boss, Feedback Please](/blog/hey-boss-feedback-please) - [Stop Optimizing for the Past](/blog/stop-optimizing-past) - [The Communication Gap That Triggers Micromanagement](/blog/communication-gap-triggers-micromanagement-close) - [Why Confident Leaders Treat Every Decision Like a Hypothesis](/blog/confident-leaders-treat-every-decision-hypothesis)https://jessestaffordcoaching.com/blog/hidden-cost-workplace-assumptions-unspoken-expectationshttps://jessestaffordcoaching.com/blog/hidden-cost-workplace-assumptions-unspoken-expectationsBack in college, I took an FPGA Design course that assigned brutal weekly homework. Pages of digital logic problems, code to write, waveforms to...Wed, 31 Dec 2025 00:00:00 GMT## When "Good Enough" Becomes "Never Enough" Back in college, I took an FPGA Design course that assigned brutal weekly homework. Pages of digital logic problems, code to write, waveforms to document, test cases to verify. I was terrible at time management and procrastinated constantly. One week, desperate and out of time, I asked my professor a simple question: "What do you actually need to see to know I understand this material?" His answer surprised me. Usually, he just wanted to see a waveform showing the input and output with a brief explanation of why it was correct. Not the full problem set. Not all the documentation. Just proof I understood the concept. I started doing half the assigned work and getting the same grades as students who completed everything. They were furious with me. But here's what stuck with me: **the written assignment and the actual requirement were two completely different things.** Most students assumed they needed to do everything exactly as specified. I asked what was actually necessary. That lesson followed me into leadership. And when I stopped asking those questions, it cost my team their nights, their weekends, and eventually their mental health. ## The $62 Million Communication Problem Workplace miscommunication costs companies with 100,000 employees an average of [$62.4 million per year in lost productivity](https://www.supernormal.com/blog/miscommunication-in-the-workplace), according to Business Insider research. But here's the part nobody talks about: a significant portion of that cost comes from employees doing work that was never actually required. According to a [Society for Human Resource Management survey](https://agilityportal.io/blog/miscommunication-in-the-workplace), 44% of workplace mistakes result from miscommunication. But it's not just unclear instructions causing the problem. It's the assumptions employees make when filling in the gaps. Research from [peopleHum](https://www.peoplehum.com/blog/6-common-reasons-for-miscommunication-at-work) identifies assumptions as one of the six primary causes of workplace miscommunication. When team members assume something is true without verification, they act on incomplete or incorrect information, leading to wasted effort and unnecessary work. I watched this pattern destroy a team member's well-being. ## When Your Team Assumes You Want the Impossible We lost an engineer from my game development team. The business decided we couldn't replace the position due to budget constraints. I gathered the remaining engineers, the project manager, and the engineering manager to deliver the news. My message was direct: we need to reduce our roadmap significantly. The departing engineer was working on six projects. I expect at least that many to come off our plate so the team doesn't burn out. The project manager came back proposing we cut only three projects. I was surprised but after extensive questioning about their plan, I reluctantly agreed. The team seemed genuinely confident they could handle the reduced scope without overextending themselves. Two months later, during a routine one-on-one, one of the engineers mentioned feeling completely overwhelmed and burned out. I was confused. We'd cut half our roadmap. How were they still overworked? The truth came out slowly. The team had assumed we wouldn't want to lose any projects despite my explicit direction to reduce workload. They knew management cared about hitting deadlines and maintaining momentum. So when they said they could handle it, what they actually meant was: "We'll work extra hours and juggle two projects each to make this work without you noticing." They had adjusted their estimates to hide the extra work. They were working nights and weekends. They were burning themselves out to deliver on what they assumed I wanted, not what I actually asked for. **I said reduce the roadmap. They heard keep everything moving no matter the cost.** ## The Scar Tissue That Filters Every Message This pattern isn't unique to my team. According to [recent burnout statistics](https://www.teamout.com/blog-post/employee-burnout-statistics), 82% of employees reported being at risk of burnout in 2025, with 32% citing heavy workload as the primary driver. But the workload often isn't coming from explicit demands from leadership. It's coming from assumptions about what leadership expects. Every employee filters your messages through their past experiences with previous managers. The boss who said "work-life balance matters" right before demanding weekend work. The leader who praised "taking ownership" but punished anyone who couldn't keep every project on track. The manager who claimed to value transparency but punished honesty about capacity. As I discussed in my post about [how employees filter leadership messages through scar tissue](/blog/message-delivery-audit-sharing-information-isnt), this creates an invisible barrier to communication. You can say exactly what you mean, but your team hears what they expect based on their history with other leaders. The engineer working extra hours wasn't ignoring my direction. They were protecting themselves from consequences they'd experienced with previous managers who said one thing and expected another. ## Why Asking Feels Risky (But Costs Less Than Assuming) Here's the uncomfortable truth: employees don't ask clarifying questions because past experience has taught them that asking makes them look incompetent, difficult, or uncommitted. A [2024 NAMI workplace poll](https://www.nami.org/support-education/publications-reports/survey-reports/the-2024-nami-workplace-mental-health-poll/) found that 62% of employees who felt uncomfortable discussing mental health at work also experienced burnout from their jobs. The connection? When employees can't ask for clarity without fear of judgment, they default to assumptions that drive overwork. Research from [Pumble](https://pumble.com/blog/miscommunication-in-the-workplace/) shows that when teams communicate effectively, productivity increases by 25%. But effective communication requires more than leaders speaking clearly. It requires team members feeling safe enough to verify their understanding before acting. My engineering team didn't ask if we really needed all those projects delivered because asking would have signaled they couldn't handle the workload. In their previous experiences, admitting capacity constraints led to being viewed as less committed or capable. So they assumed. They overworked. They burned out. ## The Show Your Work Framework: Testing Assumptions Before They Cost You The framework I teach my coaching clients addresses this exact problem. I call it "Show Your Work," and it has three critical steps that force assumptions into the open before they drive unnecessary work. ### Step 1: I Plan To (Not "May I") Start every significant task by stating your plan before you execute it. This isn't asking permission. It's declaring your intention and inviting course correction. **The wrong approach:** "Should I create a detailed analysis of the Q3 performance data?" **The right approach:** "I plan to create a summary of Q3 performance focusing on the top three trends. I'll have a draft by Wednesday for your feedback." This shift does two things. First, it surfaces your assumption about what's needed (a summary vs. detailed analysis). Second, it gives your manager or stakeholder a chance to redirect you before you invest time in the wrong direction. If they actually needed the detailed analysis, they'll tell you now. If they just needed the summary, you've saved yourself hours of unnecessary work. ### Step 2: Update, Update, Update Share regular progress without waiting to be asked. This isn't micromanagement fuel. It's assumption insurance. Every update is an opportunity for someone to say "That's not what I meant" before you've invested significant effort in the wrong direction. More importantly, it prevents the silent assumption spiral where you think you're on track but you've actually misunderstood the goal entirely. When my engineering team was planning to work extra hours on those projects, regular updates would have surfaced that plan immediately. I would have stopped them and reprioritized on the spot rather than discovering the problem two months later when burnout set in. ### Step 3: Check In When Done When you complete work, don't just deliver it and move on. Show the finished product, explain what you learned, and share what you're planning to tackle next. This step reveals whether your definition of "done" matches your manager's expectations. Maybe your complete report is more detailed than necessary. Maybe it's not detailed enough. You won't know unless you check, and that mismatch will drive rework or wasted effort on future projects. As I discussed in my post about [the critical difference between solving problems and enabling problem-solvers](/blog/hey-boss-stop-solving-teams-problems), effective leadership requires creating environments where teams can verify their understanding rather than operating on assumptions. ## The Real Cost of Assumptions According to [Aflac's 2024-2025 WorkForces Report](https://newsroom.aflac.com/2024-11-12-American-workforce-burnout-reaches-tipping-point), nearly 3 in 5 American workers are experiencing moderate to high burnout. Heavy workloads (32%) and long work hours (27%) are the top contributors. But here's what the statistics don't capture: how much of that workload and those long hours stem from employees doing work nobody actually asked them to do? How many people are perfecting presentations that only needed to be drafts? How many are creating comprehensive documentation when a simple summary would suffice? How many are working weekends to deliver on deadlines that were never actually set? [Grant Thornton's 2024 State of Work in America survey](https://www.grantthornton.com/insights/press-releases/2024/november/employee-burnout-continues-to-surge-as-mental-and-emotional-stress-mount) found that 51% of employees suffered burnout in the past year, with mental and emotional stress at 63% being the top cause. That stress often comes from the gap between what employees assume is expected and what's actually required. The engineer on my team wasn't stressed because I demanded extra work. They were stressed because they assumed I expected it based on past experiences with other leaders. ## What Leaders Can Do Monday If you manage a team, the Show Your Work framework helps, but you also need to actively surface the assumptions your team is making before they turn into burnout. When a team member's plan doesn't match your expectations, dig deeper. Don't just correct the plan. Understand the assumption that created it. **Ask questions like:** - "Walk me through your thinking on this approach. What are you optimizing for?" - "What are you assuming about timeline/resources/priorities?" - "Help me understand what led you to this solution." These questions reveal whether your team is operating on hidden assumptions that will drive unnecessary work. As I explored in my post about [managing former peers and making clear decisions](/blog/im-managing-my-former-peers), clarity requires more than stating expectations once. It requires actively checking that your message landed correctly. ## What Individual Contributors Can Do Monday If you have a manager (or stakeholders), stop assuming you know what they want. Start testing those assumptions before you invest significant effort. **Before you spend your weekend perfecting a deliverable:** - "What level of detail do you actually need for this?" - "When do you need this by?" (Don't assume the deadline) - "What's the primary decision this analysis will inform?" **Before you work late to complete everything on a list:** - "If I had to choose two items from this list to prioritize, which would you pick?" - "What's the minimum viable version of this that would be useful?" These questions feel risky. They feel like admitting you don't know what you're doing or can't handle the workload. But the alternative is burning yourself out doing work that was never actually necessary. My college professor taught me this lesson early: the assignment isn't always the requirement. The written expectations aren't always what's actually needed. Ask what success looks like before you assume you know. ## The Pattern Across Every Industry Whether you're in tech, healthcare, education, or any other field, this pattern repeats itself. Employees assume what's expected based on past experiences. Leaders assume their instructions were clear because they stated them. The gap between those two assumptions creates massive amounts of unnecessary work and drives burnout. The research is clear: [86% of executives blame workplace failures on ineffective communication](https://www.culturemonkey.io/employee-engagement/miscommunication-in-the-workplace/). But ineffective communication isn't just about unclear messages. It's about unverified assumptions filling in the gaps. My engineering team assumed I wanted all projects delivered on time. I assumed they understood "reduce the roadmap" meant exactly that. Neither of us checked those assumptions until burnout forced the conversation. ## Stop Assuming. Start Asking. Your assumptions about what's expected are costing you evenings, weekends, mental health, and possibly your relationship with your job. Your team's assumptions about what you want are costing them the same things. The solution isn't better assumptions. It's fewer assumptions. It's building systems and habits that surface expectations clearly before work begins, not after it's complete. Show Your Work isn't just about visibility. It's about creating continuous opportunities to test whether your understanding matches reality before you invest significant effort in the wrong direction. Start with one thing this week. One project where you state your plan first. One deliverable where you ask what success actually looks like before you assume. One update where you surface your approach before you're too invested to change it. The students in my FPGA course who did every problem on every assignment weren't wrong. They were thorough. They were committed. They were probably exhausted. I did half the work and got the same result because I asked what was actually needed. Stop doing work nobody asked you to do. The cost is too high. <hr /> ## Related Reading - [It's Your Fault You're Being Micromanaged](https://blog.jessestaffordcoaching.com/2024/06/its-your-fault-you-are-being.html) - Understanding different micromanager types and how to adapt your communication - [The Message Delivery Audit: Why Sharing Information Isn't Leading](/blog/message-delivery-audit-sharing-information-isnt) - How employees filter your messages through past experiences - [Hey Boss, Stop Solving the Team's Problems](/blog/hey-boss-stop-solving-teams-problems) - Creating environments where teams can clarify expectations instead of assuming <hr /> **You're great at the work. Let's make it visible.** If you're looking for help building communication systems that prevent assumption-driven overwork while making your value clear to leadership, consider reaching out. Let's talk about how you can lead with clarity and reduce burnout on your team. [Schedule a conversation here](/lets-talk).https://jessestaffordcoaching.com/blog/my-boss-said-i-couldnt-promotedhttps://jessestaffordcoaching.com/blog/my-boss-said-i-couldnt-promotedI thought the one-on-one was routine. My team was performing well.Sun, 28 Dec 2025 00:00:00 GMT### The promotion conversation I wasn't expecting I thought the one-on-one was routine. My team was performing well. Projects were shipping. People were growing in their roles. I'd been working toward the Sr. Manager promotion for months. Then my boss said it. "You can't be promoted to Sr. Manager because you've never fired anyone." The words hung in the air between us. I don't remember my exact response, but it was something like "So I won't be promoted because I'm good at leading my team?" What I wanted to say was much sharper. What I thought later, driving home, was even worse. I walked out feeling like I'd discovered an artificial ceiling. Like the rules of advancement had suddenly changed. My team's results didn't matter. The projects we shipped didn't matter. The people I'd developed didn't matter. Apparently, what mattered was checking a box on some invisible management scorecard: "Has terminated an employee." That conversation, among others, changed everything about how I showed up at that company. I stopped chasing visibility. Stopped networking for advancement. Stopped doing things because they'd look good on a promotion packet. Instead, I focused on doing excellent work, being direct when I saw problems, and honestly? I stopped caring if my honesty was career-limiting. Part of me hoped it would be. I also quietly started looking for other jobs. ## What I Didn't Understand Then Years later, after managing many people and teams, and coaching dozens of leaders through similar transitions, I understand that conversation completely differently. I still think my boss handled it terribly. But he was pointing at something real, even if he couldn't articulate it clearly. Here's what I know now that I didn't know then: **there's a massive gap between understanding performance management and having actually done it.** We can teach new managers the process. Show them the forms. Walk them through the legal requirements. Explain the SMART goal framework and the importance of documentation. But according to [Gartner Research](https://teamflect.com/blog/performance-management/people-management-for-first-time-managers), 85% of new managers receive no formal training when they assume their roles. They're expected to figure it out. And even when training exists, it can't bridge the gap between knowing what you should do and having the emotional awareness to actually do it when it matters. That gap? That's what my boss was really talking about. ## The Decisions You Won't Make (Until You've Made Them Once) If you've never managed someone through formal performance issues or let someone go, there are specific judgment calls you're unlikely to make: ### "This person isn't the right fit for this role." ### "We need different skills on the team, which means making a change." ### "Despite months of feedback and support, this isn't working." Why? Because managers who haven't crossed that line tend to give endless chances. They make excuses for underperformers. They take 100% responsibility for someone else's performance. They believe that if they just try harder, communicate better, or find the right project, everything will click into place. They do work for struggling team members "because it needs to get done." They run interference to prevent those team members from looking bad to other stakeholders. They have the same feedback conversation over and over, hoping this time it will land differently. One more chance. One more coaching session. One more improvement opportunity. Research backs this up. [Studies show](https://www.atana.com/blog/post/why-managers-avoid-difficult-conversations) that 70% of employees avoid difficult discussions with others. Among managers, only 24% report directly confronting challenging situations, while 53% deal with difficult circumstances by ignoring them. The cost? [Gallup research](https://www.gallup.com/workplace/404996/quiet-firing-stop-doing.aspx) estimates that every avoided difficult conversation costs organizations $7,500 and seven lost workdays. But the real cost is what happens to your team when they watch you avoid accountability over and over. ## The Invisible Line Here's what changes after your first time managing someone through serious performance issues: **You draw an invisible line.** It's not something you can point to or explain easily. It's a feeling based on experience. A threshold of "this far and no further" that exists only in your head. Before you've been through it, you don't know where that line is. You keep giving chances because you genuinely don't know when to stop. After? You work harder to keep people from approaching the line in the first place. You give feedback earlier and more directly. You address small problems before they become big ones. You document more carefully. You involve HR sooner. And when someone crosses the line? You move to formal performance management without the endless hoping and second-guessing. According to [research on first-time managers](https://www.cultureamp.com/blog/how-first-time-managers-can-develop-fair-and-effective-performance-reviews), this clarity is essential: "Performance management is arguably one of the most important functions of a manager. In addition to keeping team members on track, performance reviews can also be used to support growth and development." But you can't get that clarity from a training manual. ## What I See Coaching Managers Through This I've coached dozens of managers through their first serious performance management situation. The before and after is striking. **Before:** They frame everything as "How can I help you succeed?" without acknowledging that success requires the employee to do their part. They're absorbed in [solving their team's problems](/blog/hey-boss-stop-solving-teams-problems) instead of helping team members solve their own. **After:** They understand that clear expectations and support are their job. Meeting those expectations is the employee's job. They stop taking 100% ownership for someone else's performance. It's not about becoming cold or less empathetic. It's about understanding where your responsibility ends and theirs begins. When I managed someone through formal performance issues the second time, everything felt different. I was more direct from the start. I escalated sooner. I'd learned to recognize the patterns that reliably predict continued underperformance. That learning? That's what my boss was pointing at, even though he framed it as an arbitrary firing requirement. ## Is This Experience Really Necessary? Not everyone agrees, including me. Some leadership experts argue that requiring specific "hard experiences" creates unnecessary barriers to advancement. They point out that managers can learn through coaching, simulations, and observation. There's truth to this. Artificial gates can delay talented people from advancing. And some managers learn faster through various methods than others. But here's what I've observed both as a manager and a coach: **there's something fundamentally different about facing the actual consequences of a performance conversation.** When the stakes are real and someone's employment is genuinely on the line, you learn things about yourself you can't learn in a training room: - How you handle the emotional weight - What you're willing to tolerate and for how long - How direct you can be when it truly matters - Where your empathy ends and accountability begins As [one leadership researcher notes](https://www.ivey.uwo.ca/executive-education/insights/2020/12/managing-performance-as-an-emerging-leader/), "The skills that made you successful in your previous role are not the same ones you need to manage performance effectively." You discover those new skills under pressure, not in theory. ## What To Do If You Haven't Been Through This Yet If you're managing people and haven't had to manage someone through serious performance issues, that gap is affecting your decisions right now. You might be avoiding conversations, giving too many chances, or making excuses without realizing it. Here's what to do Monday: **Look honestly at your bottom performers.** Not to punish them, but to see clearly. Write down specifically where they're not meeting job-level expectations. Be concrete. Not "communication needs improvement" but "misses three out of five deadlines without proactively flagging delays" or "delivers work requiring 10+ hours of rework by senior team members." If you're avoiding this exercise, that's information. If you're making excuses for them, that's information. If you're hoping it improves on its own, that's information. You don't need to start a formal process tomorrow. But you do need to see where the line is before someone crosses it. This connects directly to [giving effective feedback](/blog/hey-boss-feedback-please). You can't manage performance if you're not [communicating clearly](/blog/candid-communication-isnt-enough) about expectations and gaps. And remember, [telling someone once isn't leadership](/blog/message-delivery-audit-sharing-information-isnt). Performance management requires ongoing, documented conversations that build a clear pattern. ## The Real Learning That conversation with my boss years ago was poorly delivered. It was probably motivated by budget constraints rather than genuine development concerns. But the underlying point he couldn't articulate? That was valid. **Management is experience-based in ways that training can't replicate.** The first time you manage someone through serious performance issues fundamentally changes how you lead. It changes what you're willing to tolerate. It changes how quickly you act. It changes where you draw the line between support and accountability. I wish someone had explained it that way instead of framing it as "you need to fire someone to get promoted." Maybe if they had, I would have actively sought out that learning instead of feeling punished for managing well. But I got there eventually. And when I did, I understood exactly what he was trying to say. **What's been your experience with performance management? Did your first serious performance conversation change how you lead?** <hr /> **You're great at the work. Let's make it visible.** I coach tech and systems leaders who want to lead with clarity, communicate their value, and grow without burning out. If you're struggling with performance conversations or managing underperformers, let's talk about how you can get clearer on expectations and act faster when problems show up. [Let's talk](/lets-talk)https://jessestaffordcoaching.com/blog/performance-management-mistake-cost-me-teamhttps://jessestaffordcoaching.com/blog/performance-management-mistake-cost-me-teamThey quit the day we handed them the performance improvement plan. Not after a few weeks of trying.Fri, 19 Dec 2025 00:00:00 GMTThey quit the day we handed them the performance improvement plan. Not after a few weeks of trying. Not after we'd worked through the documented concerns. The same day. They walked out of that meeting, resigned, and I never saw them again. I drove a good person out of the company. Not because they couldn't do the work. Because I overwhelmed them with so much feedback that improvement became impossible. Let me show you two versions of this story. What actually happened, and what I should have done instead. ## Timeline 1: What Actually Happened We promoted one of our junior managers to senior manager when the original leader retired. They were great at execution. A solid doer. They knew the work inside and out. On paper, it made sense. But a senior manager role isn't about doing the work anymore. It's about leading through others, setting direction, measuring success across the whole team. They'd never built those skills. The problem showed up immediately. We'd brought in a new junior manager to backfill their old role. The senior manager treated that junior manager's team like it wasn't really theirs. They'd focus intensely on one part of the department, the part they'd always run, but the other half might as well have been invisible. When I asked about overall team performance, they'd talk about their old area. When projects crossed team boundaries, coordination fell apart. I saw all of it. And I gave feedback. Constantly. In one-on-ones, I'd point out gaps in their understanding of the whole team. In staff meetings, I'd redirect their focus when they only talked about half the work. In performance reviews, I documented the pattern. In skip-level meetings with their reports, I'd hear the same concerns and bring them back to the senior manager. Every week, new observations. Every conversation, more areas to improve. They were trying. I could see the effort. But something always fell off. They'd start checking in with the junior manager more, then strategic planning would slip. They'd focus on team-wide goals, then execution details would crater. So I'd give more feedback about what wasn't working. One day, frustrated after another missed deadline on a cross-team project, I said: "Watching your team test our games is like watching five year olds play soccer." I actually said that. Out loud. To someone who was drowning in feedback and trying desperately to improve. The cycle continued for months. More feedback, less progress, more frustration on both sides. Nothing was getting better. Everything felt stuck. HR and I started the performance improvement plan process. We documented the concerns, outlined the expectations, scheduled the meeting. They quit that same day. Walked out of the meeting and never came back. ## Timeline 2: What I Should Have Done Same promotion. Same person. Same initial problem, they couldn't see the whole team as their responsibility. But this time, I stop. Instead of listing every gap I'm seeing, I ask myself: What are the 2-3 core behaviors that, if they changed, would solve most of these other problems? I land on three things: **First, understanding how goal setting and communication should work at the senior manager level.** They needed to learn that their job was clarifying direction and ensuring alignment, not diving into tactical execution. Tactical work still happens, but they measure and communicate about it. They don't get into the weeds and drive it themselves. **Second, learning to lead through other managers.** They needed to see the junior manager's team as fully their responsibility. Success meant the junior manager succeeded, not that they personally fixed every problem. This meant measuring team performance across both areas, coaching the junior manager, and removing obstacles, not doing the junior manager's job. **Third, finding where expectations weren't clear.** Instead of assuming they understood what I wanted, I needed to actively identify where they felt confused or unsuccessful. What did they think success looked like? Where did my expectations not match their understanding? These three behaviors. That's it. Every one-on-one focuses on these. Not on the missed deadline from Tuesday. Not on the communication gap from last week's meeting. Just these three leadership behaviors. When they talk only about their old team in staff meeting, I don't add it to the feedback list. I connect it back to behavior two: "You're leading through another manager now. How is their team performing? What support do they need from you?" When a cross-team project struggles, I don't document another failure. I ask: "What's your goal for this project? How are you measuring whether both teams are aligned? What's blocking success?" When I'm frustrated about something that feels like five-year-old soccer, I don't say it. I take a breath and ask myself: Does this connect to one of the three behaviors we're working on? If not, I let it go. This takes discipline. New problems emerge weekly. My instinct screams to mention all of them. But I don't. Because adding more feedback won't help them improve faster. It will ensure they improve never. Instead, I keep coming back to the same three behaviors. We talk about specific situations where they showed up. We discuss what different choices would look like. We track progress on changing these habits, not on fixing every outcome. Some weeks they backslide. That's normal. We talk about what happened and refocus. But because we're not also trying to fix five other things simultaneously, they actually have the mental space to change. After a few months, I start seeing real improvement. They're setting clearer goals with both managers. They're asking about team-wide metrics instead of just their old area. They're catching themselves when they start diving into tactical work and redirecting their energy to leadership work. They don't become perfect. But they become noticeably better. And more importantly, they feel successful. They can see their own progress because the targets are clear and consistent. ## What Happens After You Narrow Focus Here's what nobody tells you about focused feedback: the hardest part isn't identifying the 2-3 behaviors. It's resisting the urge to add more when new problems emerge. Because new problems will emerge. Constantly. You'll see a communication failure and want to add "better stakeholder updates" to the list. You'll notice a delegation issue and want to include "empowering the team." You'll observe a meeting that went poorly and think "we need to talk about this too." Don't. Ask yourself: Does this new problem connect to one of the 2-3 behaviors we're already working on? If yes, bring it up as an example of that existing behavior. If no, let it go. This requires you to track progress differently. Stop making mental lists of every problem. Start keeping notes on whether you're seeing change in the specific behaviors you identified. In your one-on-ones, resist the temptation to bring up every issue from the week. Instead, ask: "Tell me about a situation this week where you led through your junior manager instead of solving the problem yourself." Or "How did you clarify goals for the team this week?" You're looking for evidence of behavior change, not perfect outcomes. The outcomes will improve when the behaviors change. But you have to give the behaviors time to actually shift. Most behavior change takes 60-90 days of consistent focus. That's two to three months of talking about the same 2-3 things over and over. It feels repetitive. It feels slow. It works. ## The Discipline of Staying Focused The reason I overwhelmed my senior manager with feedback wasn't because I didn't care. It was because I cared too much about too many things at once. Every problem I saw felt urgent. Every gap felt like something they needed to fix immediately. I convinced myself that being comprehensive was being helpful. I was wrong. Here's how to stay focused when every instinct tells you to add more: **Keep a separate list for yourself.** When you see a new problem, write it down. But don't bring it to them. Review your list weekly. Ask yourself: Is this still a problem? Often, fixing the core 2-3 behaviors resolves issues you thought needed separate attention. **Use a framework to structure your feedback.** Something like SBI (Situation-Behavior-Impact) forces you to be specific about what you observed. This clarity helps you decide if the observation connects to your existing focus areas or if you're adding something new. **Schedule a 30-day review.** Put it on your calendar. In 30 days, you'll assess whether the 2-3 behaviors you identified are still the right ones. Not before. This prevents you from constantly shifting focus while still allowing for course correction if needed. **Ask them what's working.** In every conversation, ask them to identify where they're seeing progress. This keeps you both focused on change, not just problems. It also reveals whether they understand what you're asking for. When you're tempted to bring up that seventh thing they need to improve, remember: you're not helping them get better faster. You're ensuring they never improve at all. ## The Cost of Getting It Wrong I lost a capable employee who could have grown into the senior manager role. Not because they lacked potential. Because I didn't give them a realistic path to success. I failed in my fundamental job as a leader: developing people. I saw someone struggling and responded by making the struggle harder. I thought I was being thorough. I was being destructive. The "five year olds playing soccer" comment wasn't just cruel. It was evidence that I'd lost perspective. I was so frustrated by the lack of progress that I couldn't see I was causing the problem. They quit the day we gave them the performance improvement plan because by that point, they'd been receiving improvement feedback for months. The formal plan wasn't new information. It was confirmation that nothing they did would ever be enough. I see this pattern now in coaching conversations. Leaders come to me frustrated that their team member "just isn't getting it" despite "all the feedback I'm giving." When I ask what they're focusing on, they list eight things. Ten things. Everything they see that's not working. They're creating the same failure I created. With the same good intentions. ## What To Do Monday If you're managing someone's performance right now, stop adding to the feedback list. Instead, do this: **Identify the 2-3 behaviors that matter most.** Go back to your values, your leadership principles, your team goals. Ask yourself: What specific behaviors is this person showing that aren't supporting the culture and direction I'm building? What behaviors, if they changed them, would solve most of the other problems I'm seeing? Write them down. Be specific about what those behaviors look like in practice. **Review your recent feedback.** How many different things have you asked them to improve in the last month? If it's more than three, you're overwhelming them. Pick the 2-3 that matter most and let the rest go for now. **Plan your next conversation.** It should focus entirely on those 2-3 behaviors. Not on outcomes. Not on the full list of problems. Just those critical behaviors. Prepare specific examples of where you've seen them (or not seen them) in action. **Commit to 60 days.** These three behaviors are your focus for the next two months. Write it down. Put it somewhere you'll see it before every one-on-one. When you're tempted to add more feedback, look at that note and stop yourself. **Ask them what's unclear.** In your next conversation, don't just give feedback. Ask where they're confused about what success looks like. Where do they feel unsuccessful? What support do they need to change these specific behaviors? Then listen. Really listen. Because sometimes the problem isn't that they won't change. It's that they don't know what you're actually asking for. ## You Can Do This Differently I can't undo what happened with my senior manager. They're gone. I don't get a second chance with them. But you might still have time. If you're overwhelming someone with feedback right now, you can stop. Today. This conversation. You can narrow your focus to what actually matters and give them a realistic shot at success. It requires discipline. You'll see problems you want to mention. You'll have to bite your tongue. You'll worry that you're not being thorough enough. Let that worry go. Comprehensive feedback doesn't help people improve. Focused feedback does. Stop giving them everything you see. Start giving them what they can actually use. **Have you seen this pattern?** Either in yourself or in leaders you've worked with? What helped break the cycle? Drop a comment, I'd learn from your experience. <hr /> **You're great at the work. Let's make it visible.** If you're struggling to give focused performance feedback, or you recognize yourself in this story and want to change course before you lose someone, let's talk. I help leaders get clear on what matters most and develop their people effectively. **Contact me:** [book a free call](/lets-talk)https://jessestaffordcoaching.com/blog/confident-leaders-treat-every-decision-hypothesishttps://jessestaffordcoaching.com/blog/confident-leaders-treat-every-decision-hypothesisWe hired two engineers the same year. Both bets.Sun, 09 Nov 2025 00:00:00 GMTWe hired two engineers the same year. Both bets. Only one paid off. The first was passionate about games. Knew all the techniques and theories. Could talk for hours about game design. But when it came to writing code, he struggled. He knew the basics but couldn't apply the concepts. A bet that passion would translate to skill. That on-the-job training would close the gap faster than it did. After a year, he was barely adequate. We had to let him go. The second hire was technically capable. No social skills. No apparent passion for games. A bet that technical ability mattered more than enthusiasm. That person became one of the team's favorites. Both were leadership decisions based on incomplete information. Both were educated guesses about what would happen. Only one hypothesis held up. That's how leadership decision-making actually works. You're not making certainties. You're making testable bets and watching what happens. ## The Leadership Uncertainty Paradox: Why Confidence Doesn't Mean Certainty Here's what breaks leadership decision-making for most people. They think showing up confident means being sure about their choices. So when a hire doesn't work out, they get defensive. When a strategy fails, they blame external factors. When a promotion backfires, they say the person "wasn't ready" instead of admitting their hypothesis was wrong. The problem isn't that you made a bad decision. The problem is you pretended it wasn't a hypothesis in the first place. > **Confident leadership doesn't require certainty.** It requires being ready to make the call with incomplete information and handle what comes next. Executive presence isn't about never being wrong. It's about owning your decisions, testing them honestly, and adjusting based on results. ## What Confident Leaders Do Differently With Leadership Decision Making Leaders who handle uncertainty well don't have better crystal balls. They treat decisions like scientists treat experiments. They say "I'm making a bet" instead of "I'm making the right call." They write down what they're actually betting on instead of keeping it vague. They set checkpoints to measure if the hypothesis is working instead of hoping for the best. When the bet doesn't pay off, they adjust. They don't double down because admitting failure feels like weakness. The scientific method isn't just for labs. It's the best framework for leadership decision-making when you don't have all the answers. This is the opposite of [micromanagement](https://blog.jessestaffordcoaching.com/2024/03/its-your-fault-you-are-being.html), where leaders pretend they need certainty about every detail before allowing teams to move forward. ## The Scientific Method Applied to Leadership Decisions Science works because it tests ideas against reality. Leadership should work the same way. #### **Here's how scientists approach uncertainty:** They observe a problem. They form a hypothesis about what might solve it. They test the hypothesis. They measure results. They conclude whether it worked. They adjust and try again. Leaders do this whether they realize it or not. The difference is whether you do it intentionally or pretend you're making sure things. ### Control Variables: What Are You Actually Testing? When scientists run experiments, they isolate variables. They change one thing and keep everything else the same. That's how they know what actually caused the result. Leaders rarely do this. They hire someone AND change the team structure AND launch a new project. Then when it works or fails, they don't know why. With the passionate engineer, I was testing whether passion could overcome skill gaps. But I didn't control for other variables. Was the team structure set up to support someone learning on the job? Did I give clear enough direction? Did I check in frequently enough? I treated it like a sure thing instead of an experiment. That made it harder to know what actually went wrong. With the technical hire, I isolated the variable better. I knew technical ability was there. I was specifically testing whether lack of social skills and passion would be a problem. Turns out, for that role on that team, it wasn't. > **Before your next leadership decision, ask: What am I actually testing here?** Be specific. Write it down. ### The Null Hypothesis: What If You're Wrong? Scientists always ask "what if my hypothesis is wrong?" They design experiments to test whether they're wrong, not just to prove they're right. Leaders do the opposite. They look for evidence that confirms their decision was good. They ignore early warning signs. They explain away problems instead of treating them as data. The null hypothesis for my passionate engineer hire would have been: "Passion will NOT overcome significant skill gaps in a reasonable timeframe." If I'd framed it that way, I would have set clearer benchmarks. I would have adjusted faster when he wasn't progressing. Instead, I kept hoping more time would fix it. > **Ask yourself: What would prove this bet wrong?** Then watch for those signs instead of ignoring them. ## Common Mistakes Leaders Make When Avoiding Uncertainty Most leadership decision-making problems come from pretending you have more certainty than you do. Here's what that looks like in practice. ### Mistake 1: Waiting for Perfect Information You keep gathering data. You run one more interview. You ask for another report. You tell yourself you need to be thorough. Really, you're afraid to make the bet. Perfect information doesn't exist. At some point, you have more questions than answers and you still need to move. That's leadership uncertainty. Get comfortable with it. The fix: Set a decision deadline. When you hit it, make the call with whatever information you have. ### Mistake 2: Consensus Building Before Moving You think good leaders get everyone on board before making decisions. You spend weeks getting buy-in. You revise the plan until everyone agrees. This isn't leadership. It's risk avoidance. You're spreading the blame so if it fails, it's not just on you. Confident leaders make bets even when not everyone agrees. They explain their reasoning. They listen to concerns. But they don't wait for unanimous support before testing a hypothesis. The fix: Explain the bet you're making and why. Ask for feedback. Then make the call and own it. ### Mistake 3: Sunk Cost Fallacy (Doubling Down on Bad Bets) You invested time training someone. You spent money on a strategy. You publicly committed to an approach. So when the data shows it's not working, you invest more. You give it another quarter. You tell yourself it just needs more time. This is the sunk cost fallacy. You're throwing good money after bad because admitting the bet was wrong feels like admitting you were wrong. Scientists don't do this. When an experiment fails, they conclude it failed and move on. They don't keep running the same experiment hoping for different results. **The fix:** Decide in advance what results would prove the bet isn't working. When you see those results, adjust. The money and time are already gone. Don't waste more. ## The Anatomy of a Good Leadership Bet: A Science-Based Framework Here's how to structure your next leadership decision like a hypothesis instead of a hope. ### Step 1: Observe the Gap What problem are you solving? What opportunity are you seeing? Be specific. Not "we need more senior people." Try "we have three projects stuck because no one can make architectural decisions without me." ### Step 2: Form Your Hypothesis State what you're betting and why. "I'm betting that promoting Sarah to Senior Engineer will unblock these projects because she's already making good technical decisions informally." Write this down. Include: - What you're betting on (the person, strategy, approach) - What you expect to happen (specific outcomes) - Why you think this will work (your reasoning) ### Step 3: Define Success Metrics How will you know if the hypothesis is working? For a hire: "In 90 days, they're independently completing tasks similar to what the team does." For a promotion: "In 60 days, two of the three blocked projects are moving forward without my input." For a strategy: "In 30 days, we see a 15% improvement in the metric we're targeting." Be specific. Set the timeline. Write it down. ### Step 4: Set Checkpoints Don't wait until the end to measure. Set interim checkpoints. 30 days: Early indicators. Is anything clearly not working? 60 days: Progress check. Are we moving toward the outcome? 90 days: Evaluation. Did the hypothesis hold? At each checkpoint, review the data honestly. Look for evidence you're wrong, not just evidence you're right. This checkpoint approach also works for [one-on-one conversations with your team](/blog/good-one-on-one-look-like), where regular check-ins help you understand if team members are progressing as expected. ### Step 5: Adjust Based on Results If the bet is paying off, great. Keep going. If it's not, you have options: - Adjust the approach (hypothesis was right, execution was wrong) - Pivot the bet (hypothesis was partially right, needs modification) - Cut losses (hypothesis was wrong, try something else) The key is making this decision based on data from your checkpoints, not hope or sunk costs. When you need to adjust, remember that [your job isn't to solve the problem for your team](/blog/hey-boss-stop-solving-teams-problems). Your job is to clarify what needs to happen and let them figure out how. ! ## How to Evaluate If Your Hypothesis Is Working Measuring results isn't about waiting to see if things feel better. It's about having clear criteria you decided before you made the bet. **At each checkpoint, ask three questions:** **1\. Is the specific outcome I predicted happening?** Not "is this person doing okay?" That's too vague. Try "are they completing tickets at the rate I expected?" or "have they reduced my decision-making load?" **2\. What evidence would prove I'm wrong?** Look for that evidence specifically. Don't just look for signs you're right. **3\. What have I learned that changes my hypothesis?** Maybe the bet is working but for different reasons than you thought. That's useful data for your next bet. ## Building Executive Presence Through Honest Decision Making Executive presence isn't about projecting certainty you don't have. It's about being honest about leadership uncertainty while still moving forward. When you say "I'm making a bet on this" out loud, two things happen. **First, it builds trust.** People respect leaders who are honest about risk. They don't respect leaders who pretend every decision is guaranteed to work. **Second, it makes course correction easier.** When you frame something as a hypothesis from the start, changing direction isn't failure. It's learning. The best leaders I've worked with all do this. They make bets. They own them. They watch what happens. They adjust. They're not right more often than other leaders. They're just honest about the process. ## What to Do Monday Before your next hire, promotion, or strategic decision, try this: > **Write down: "I'm betting that \[X\] will lead to \[Y\] because \[Z\]."** Be specific. Not "this person will be great." That's not a hypothesis. Try "I'm betting that her experience leading remote teams will help her manage our distributed engineering group because the challenges are similar." > **Then write: "I'll know this is working if \[specific outcome\] happens by \[specific date\]."** Not "things get better." That's not measurable. Try "Three team members report feeling more supported in our next engagement survey" or "Project velocity increases 20% in the next quarter." > **Set your checkpoints: 30, 60, 90 days.** At each one, look at the data. Ask what would prove you wrong. Be honest about what you're seeing. If it's working, keep going. If it's not, adjust. You're not wrong. The bet just didn't pay off. That's leadership decision-making. You make educated guesses based on incomplete information. You test them honestly. You adjust based on results. The leaders with the best executive presence aren't the ones who are always right. They're the ones who treat every decision as a hypothesis and get comfortable with leadership uncertainty. Start calling your decisions what they are: bets. You'll make better ones. <hr /> **What's a leadership decision you're facing right now? What's your hypothesis?** Share in the comments. **You're great at the work. Let's make it visible.** Leadership decision-making gets easier when you have someone to help you test your hypotheses and build your executive presence. If you're navigating a tough call or want to get better at handling leadership uncertainty, let's talk. [Jesse Stafford Coaching](/) **Related posts:** - [It's Your Fault You're Being Micromanaged](https://blog.jessestaffordcoaching.com/2024/03/its-your-fault-you-are-being.html) - [Hey Boss, Stop Solving the Team's Problems](/blog/hey-boss-stop-solving-teams-problems) - [What Does a Good 1-on-1 Look Like?](/blog/good-one-on-one-look-like)https://jessestaffordcoaching.com/blog/information-doesnt-reach-employees-fixhttps://jessestaffordcoaching.com/blog/information-doesnt-reach-employees-fixThe gap between what leadership announces and what employees actually know isn't a communication problem. It's a systems problem.Sun, 09 Nov 2025 00:00:00 GMT**The gap between what leadership announces and what employees actually know isn't a communication problem. It's a systems problem.** Information gets filtered, blocked, and lost at every organizational level. Understanding why this happens and what both senders and receivers can do about it is the difference between aligned teams and constant confusion. ## The Real Cost of Information Loss Last October, I started getting urgent requests about project updates. Teams needed to account for a major software change coming in the next release. The problem? That change had been delayed five months earlier. The February announcement reached everyone. The May delay only reached a handful of managers. Those managers had competing priorities. The delay fell off their radar. By October, multiple teams were still planning for the original timeline. They had no idea anything changed. Nobody was lazy. Nobody deliberately dropped the ball. The information just stopped moving. > **This happens in your organization too.** Research shows a striking gap between what leaders think they communicate and what employees actually receive. One study found that two-thirds of senior managers believe they explain major decisions well. Only one-third of front-line employees agree. The message gets lost somewhere between the top and bottom of your organization. ## Why Information Doesn't Reach Employees: The System Fails, Not the People Think about how water moves through a building. The main line has full pressure. It splits into smaller pipes on each floor. Those pipes branch into individual offices. Some pipes narrow. Some have filters. Some valves close when other areas need flow. By the time water should reach the third floor bathroom, nothing comes out. The water company thinks everything is fine. The main line shows full pressure. > **Your organizational communication works exactly the same way.** Leadership announces something. Full pressure. Clear message. It hits the first layer of managers. The pipe narrows. Each manager filters based on priorities. Some decide it's not urgent. Some think their team doesn't need it yet. Some forget. It hits the next layer. The pipe narrows again. More filtering. More competing priorities. By the time it should reach the person who needs it, nothing comes out. The system creates the blockage. Not the people in the system. ### The Grapevine Problem Research reveals another challenge. Studies show that 70% of all organizational communication happens through informal channels, not official ones. Employees trust what they hear from peers more than what comes through formal announcements. The grapevine carries information faster than your carefully planned cascade. But the grapevine also distorts messages. Adds speculation. Fills gaps with guesses. When official channels fail, the grapevine takes over. And what employees hear often bears little resemblance to what leadership said. ## Common Reasons Information Gets Blocked ### Management Layers Act as Filters Every management level between you and the end user is a potential blockage point. Managers receive dozens of messages daily. They make split-second decisions about what to share. What seems critical to you might not make their top ten priorities. They also translate your message through their own lens. What you said and what they share rarely match exactly. ### Competing Priorities Override Your Message That software delay I mentioned? The managers who heard about it had fifteen other things demanding attention. Your message competed with budget reviews, staffing issues, customer escalations, and their own project deadlines. Your critical update lost. Not because they didn't care. Because humans can only track so much at once. ### Assumptions Kill Communication Senders assume: "I told my direct reports, so everyone knows." Managers assume: "This doesn't affect my team right now." Receivers assume: "If something important happened, someone would tell me." All three assumptions are wrong. All three create information gaps. ### Physical and Structural Barriers Remote work. Different time zones. Separate buildings. Departments that never interact. Physical separation makes information sharing harder. You can't overhear the conversation at the next desk. You miss the hallway context. You're not in the room when decisions get made. Organizational silos compound the problem. Engineering doesn't talk to Sales. Sales doesn't loop in Support. Support doesn't know what Product is building. Information gets trapped in departmental bubbles. ## What Senders Get Wrong About Communication You announced the change. You sent the email. You covered it in the all-hands meeting. You think your job is done. **Your job hasn't started.** ### The One-and-Done Myth Telling someone once doesn't mean they heard you. It definitely doesn't mean they'll remember. It absolutely doesn't guarantee they'll share it with their teams. Marketing research going back to the 1930s found that people need to encounter a message at least seven times before they take action. Movie studios discovered that potential customers had to see a poster seven times before buying a ticket. Your employees need the same repetition. Maybe more, given how much information competes for their attention. ### The Cascade Assumption You assume your direct reports will cascade your message down. With the same urgency. The same detail. The same accuracy. They won't. They have their own interpretation. Their own priorities. Their own communication style. What you said and what they share are two different messages. By the time it reaches three levels down, your original message is unrecognizable. ### Missing the 7 Times, 7 Ways Rule One email isn't enough. One meeting isn't sufficient. One Slack message gets buried. **If something matters, communicate it seven times using seven different methods.** - Email announcement - All-hands meeting mention - Slack channel update - One-on-one conversations - Team meeting discussion - Written documentation - Dashboard or wiki entry Each method reaches different people. Each repetition reinforces the message. Each format serves a different learning style. There is no such thing as over-communication in organizations. ## What Receivers Get Wrong About Information Flow You're waiting for information to reach you. You assume someone would tell you if something important changed. **Stop waiting. Start asking.** ### The Passive Information Trap When something doesn't make sense, you wonder about it. You mention it to a colleague. You assume someone else will figure it out. You don't ask upstream. You don't check the source. You don't verify what you heard through the grapevine. The information exists somewhere. You just haven't found it. [Stop assuming your manager should have all the answers](/blog/one-on-ones-my-manager-kind-terrible) and start asking better questions. ### The Silence Means Nothing Myth You hear nothing about that project. You assume that means nothing changed. Silence doesn't mean stability. It means the information pipeline broke somewhere between the source and you. Don't interpret silence as "everything's fine." Interpret it as "I need to check." ### Failing to Build Information Pathways You rely on your direct manager for all information. When they don't share something, you're stuck. **Build multiple pathways:** - Ask your manager - Check with the project owner - Review the wiki or shared docs - Connect with someone closer to the source - Join relevant Slack channels or email lists More pathways mean more chances information reaches you. ### Assuming Bad Intent When information doesn't reach you, your first thought: "Why didn't anyone tell me?" That frustration is valid. The blame isn't. The person who didn't tell you probably didn't know you needed to know. Or they assumed someone else told you. Or they forgot. Or it never reached them either. **Assume positive intent.** The information was missed, not hidden. [Understanding why people micromanage](/blog/stop-being-micromanaged-without-waiting-manager) starts with recognizing they're responding to their own information gaps and fears, not deliberately withholding from you. ## How to Fix Information Flow in Your Organization ### For People Sending Information ### Repeat Your Message Seven Times, Seven Ways Don't stop after you announce something once. Start a communication campaign. Email it. Present it. Discuss it in one-on-ones. Post it in Slack. Document it. Reference it in meetings. Update dashboards. Each method reaches someone who missed the previous six. ### Don't Assume Your Message Cascades Accurately Your direct reports won't share your message directly. They'll share their version of your message. Follow up. Ask what people heard. Correct misunderstandings. Fill gaps. Check three levels down. What's the front line saying about your announcement? Does it match what you said? ### Verify Receipt and Understanding Don't ask "Did everyone get my email?" Ask "What did you understand from my email?" The first question gets head nods. The second reveals gaps. Create feedback loops. Make it easy for people to ask questions. Reward those who point out confusion. ### Use Multiple Communication Channels Different people consume information differently. Some read every email. Some ignore email but watch Slack. Some need to hear it in person. Some want written documentation they can reference later. Hit all the channels. The same message, adapted for each format. [Varying your communication locations and methods](/blog/should-mix-up-one-on-one-locations) can dramatically change what information surfaces. ### For People Receiving Information ### Ask Questions Upstream When something doesn't add up, investigate. "I heard the software change is coming next month, but I also heard it was delayed. Which is correct?" Don't wait for clarity to find you. Go get it. ### Check the Source Directly Your manager doesn't know. Ask their manager. Still unclear? Contact the project owner. Find the person closest to the information. Skip the telephone game. Go to the source. ### Build Relationships Across Layers Know people outside your immediate team. Connect with folks in other departments. Build relationships with leaders two or three levels up. When you need information, you'll know who to ask. When they share updates, you'll be on the list. ### Create Your Own Information Channels Don't rely solely on what flows down to you. - Subscribe to relevant email lists - Join project Slack channels - Attend optional updates or town halls - Read meeting notes from leadership meetings - Check shared wikis and documentation The more channels you monitor, the less likely you'll miss critical information. ### Assume Information Gaps, Not Intentional Hiding When you discover you missed something important, your first reaction might be frustration or anger. Take a breath. Assume the gap was systemic, not personal. Then fix your information pathways so it doesn't happen again. ## Practical Action Steps for Monday Morning ### If You Send Information to Teams: ✓ **Identify your most critical message right now.** What does your team absolutely need to know? ✓ **Plan seven different ways to share it.** Email, meeting, Slack, one-on-one, documentation, dashboard, follow-up. ✓ **Schedule those seven touchpoints over the next two weeks.** Space them out. Hit different channels. ✓ **Ask three levels down what they heard.** Not "did you get my message?" but "what did you understand?" ✓ **Correct gaps immediately.** When you find misunderstandings, clarify fast before they spread. ### If You Receive Information from Leadership: ✓ **List three things you're unclear about in your current work.** What decisions or changes would affect your projects? ✓ **Identify who would know the answer.** Project owner? Their manager? The department head? ✓ **Ask directly this week.** Don't wait. Send the email or Slack message today. ✓ **Build one new information pathway.** Join a Slack channel. Attend a town hall. Connect with someone in another department. ✓ **Set a weekly check-in with your manager specifically about information flow.** "What's changing that I should know about?" Make this a [regular part of your one-on-one agenda](/blog/one-on-ones-my-manager-kind-terrible). ### For Everyone: ✓ **Stop believing one announcement is enough.** If you're sending, plan repetition. If you're receiving, expect gaps. ✓ **Assume positive intent when information fails.** The system broke. The people didn't. ✓ **Build redundancy into your information channels.** More pathways mean fewer missed messages. ## The Bottom Line on Why Information Doesn't Reach Employees Your organizational communication system is like plumbing. Pressure drops as messages move through layers. Pipes narrow. Valves close. Filters catch things. Information doesn't flow automatically from top to bottom. The system itself creates blockages. **Senders:** Stop thinking one announcement is enough. Plan for repetition. Verify understanding. Check three levels down. **Receivers:** Stop waiting for information to find you. Ask questions upstream. Build multiple pathways. Assume gaps, not hiding. **Everyone:** Accept that perfect information flow is impossible in organizations. Build systems that account for inevitable failures. There is no such thing as over-communication. The gap between what leadership says and what employees know costs time, money, and trust. Close that gap. Repeat your messages. Chase down clarity. Fix the plumbing.  **What information got stuck in your organization recently? Where did the message stop flowing? Share your experience in the comments below.** **You're great at the work. Let's make it visible.** Struggling with communication breakdowns in your organization? I help tech and systems leaders build strategies that actually reach people. Let's talk about closing your information gaps. **Schedule a conversation:** https://www.jessestaffordcoaching.com/lets-talkhttps://jessestaffordcoaching.com/blog/was-last-time-invested-own-careerhttps://jessestaffordcoaching.com/blog/was-last-time-invested-own-careerNot a company-paid training. Not a mandatory certification course your boss signed you up for.Sun, 09 Nov 2025 00:00:00 GMTNot a company-paid training. Not a mandatory certification course your boss signed you up for. Not a lunch-and-learn that happened to be scheduled during your team meeting. I'm talking about you opening your wallet and investing your own money in learning something that advances YOUR career goals, not just your current job requirements. If you can't remember the last time, you've made a dangerous trade. You've handed control of your career trajectory to people who are optimizing for quarterly profits, not your long-term success. And here's the uncomfortable truth: **most professionals never realize they made this trade until it's too late.** ## The Permission Trap: Why Waiting for Company-Funded Learning Is Killing Your Career You graduated college. Landed a decent job. Started climbing the ladder. Along the way, you accepted an unspoken agreement that you probably don't even remember agreeing to. The agreement goes like this: Your company will decide what skills you need. Your company will determine when you're ready to learn them. Your company will control the timeline and budget for your professional development. In exchange, you'll work hard, deliver results, and trust that if you need to know something important, they'll make sure you learn it. > **This agreement is destroying your career potential.** ### Why Companies Won't Fund the Learning That Actually Matters Let's be clear about what companies optimize for when they invest in employee training. Companies fund learning that increases your value to them in the next 6-12 months. They pay for skills that solve problems they're facing right now. They approve training budgets for competencies that directly impact current projects or quarterly goals. Your company needs you to be 10% better at your current role. You need to be qualified for roles that don't exist at your company yet. Your company wants you to solve this quarter's challenges more efficiently. You need exposure to approaches from completely different industries. Your company invests in making you valuable to them. You need to invest in making yourself valuable to you. > **Those two things occasionally overlap. But not nearly as often as you think.** ### The False Belief That's Holding You Back Here's what most professionals believe: "If the skill really mattered, the company would pay for me to learn it." This sounds reasonable. It's not. This belief assumes your company knows what your career needs three years from now. They don't. They're barely planning beyond next quarter's OKRs. This belief assumes your manager is actively thinking about your career growth. They're not. They're thinking about team capacity, project deadlines, and how to retain headcount in next year's budget. This belief assumes HR is strategically planning your career trajectory. They're not. They're managing compliance requirements, filling open positions, and processing performance reviews. **Nobody is steering your career except you.** And if you're waiting for permission to learn, you've handed the steering wheel to people who aren't even looking at your destination. ### What You're Actually Losing While You Wait Every year you wait for company approval to learn something new, here's what you're giving up: **Career velocity.** Your peers who invest in themselves are building skills that qualify them for opportunities you won't even recognize as opportunities. **Market value.** The difference between being qualified for one role versus three roles isn't your current performance. It's the skills you've invested in developing outside your job description. **Professional leverage.** When your only learning comes from your current employer, your only options come from your current employer. **Industry perspective.** Learning exclusively from people inside your company is like learning about the ocean from people who've only swum in one lake. The opportunity cost of waiting isn't just the learning you miss. It's the career moves you can't make, the offers you don't receive, and the trajectory you never get to choose. ### The Trap of "I Don't Have Time" Let's address the most common excuse: You're too busy. You're too busy because you're working at 100% capacity, solving problems with the limited toolkit you currently have. If you had a broader toolkit, approaches from other industries, frameworks from that book everyone references, and insights from professionals who've solved similar challenges, you'd solve those same problems faster. **You don't have time to learn because you haven't invested in learning.** It's a loop that only breaks when you decide to break it. ## The Professional Development Pyramid: Your Learning Investment Options Not all learning investments are created equal. Some require significant money but create exponential returns. Others cost almost nothing but require consistency. Here's how to think about building your personal professional development strategy: ! ### Base Level: Free and Low-Cost Options (The Foundation You're Ignoring) #### **Local Professional Groups and Meetups** Cost: Free to $20 for occasional event fees These are the learning opportunities hiding in plain sight. Every city has professional groups meeting monthly. Tech meetups. Leadership roundtables. Industry-specific associations. Most professionals ignore these because they seem too basic or too casual. That's a mistake. What you actually get: - Direct access to professionals facing similar challenges - Real conversations about current problems and solutions - Low-pressure environment to test ideas and get feedback - Networking that leads to opportunities months or years later - Consistent learning touchpoints without major investment **The challenge:** These require showing up consistently, not just when you need something. **Where to start:** Meetup.com, LinkedIn Events, your city's Chamber of Commerce, industry-specific associations #### **Toastmasters and Speaking Groups** Cost: $50-$100 per year for Toastmasters membership; many speaking groups are free You know what skill advances careers faster than almost anything else? Being able to stand in front of people and clearly explain your ideas. Most professionals are terrible at this. The ones who aren't terrible got that way through practice, not natural talent. What you actually get: - Structured practice presenting ideas - Immediate feedback from supportive peers - Confidence speaking in front of groups - Communication skills that translate to every meeting you're in - Leadership opportunities within the organization **The challenge:** You have to be willing to look awkward while you improve. **Where to start:** Toastmasters International, local TEDx speaker programs, presentation skills workshops ### Middle Level: Books and Online Learning (The Scalable Investment) #### **Books: The Most Underrated Career Investment** Cost: $15-$30 per book, $200-$300 per year for regular reading If you read one book per month about your field or adjacent fields, you're learning from 12 experts per year. Most professionals read zero. The math on books is almost offensive. For the cost of one lunch meeting, you get the distilled expertise of someone who spent 20 years learning something the hard way. What you actually get: - Deep understanding of specific topics - Frameworks you can apply immediately at work - Reference material you return to repeatedly - Exposure to ideas your company would never teach you **The challenge:** Actually reading them instead of letting them pile up on your nightstand. **Strategy:** Buy the book the moment you hear it referenced twice. Read it within two weeks. Implement one thing within one week of finishing. #### **Online Courses and Platforms** Cost: $20-$200 per course, or $30-$50/month for platform subscriptions The democratization of education means you can learn advanced skills from world-class instructors for less than most people spend on coffee in a month. Platforms like Udemy, LinkedIn Learning, Coursera, and Pluralsight offer structured learning paths for virtually any skill. What you actually get: - Video instruction you can pause and rewatch - Structured curriculum with exercises - Certificates that signal skill development - Ability to learn during lunch breaks or evenings - Progress tracking and accountability **The challenge:** Low completion rates. Buying the course isn't the same as finishing it. **Strategy:** Block learning time on your calendar like any other meeting. Set a deadline to complete courses within 30 days of purchase. ### Top Level: Conferences and Workshops (The Multiplier Investment) #### **Industry Conferences** Cost: $500-$4,000 depending on size and location This is where the real acceleration happens. Not because conferences teach you things you couldn't learn elsewhere. Because they expose you to people, ideas, and possibilities you'd never encounter staying inside your company bubble. What you actually get: - Face-to-face conversations with people solving bigger versions of your problems - Exposure to approaches from completely different contexts - Industry connections that turn into opportunities years later - Proof that solutions you thought were impossible are being done elsewhere - Inspiration and energy that carries you through months of execution **The ROI nobody talks about:** The value isn't in the sessions you attend. It's in the conversations during breaks, the people you meet at dinner, and the ideas that collide in your head on the flight home. **The challenge:** Conferences are expensive and require time away from work. **Strategy:** Budget $250/month specifically for one conference per year. Choose conferences where you can learn from adjacent industries, not just your own. ## My $30,000 Investment: What Actually Happened Let me tell you what self-funded learning actually looks like over a decade. I paid my own way to GDC (Game Developers Conference) eight times. My employers covered three. At $2,000-$4,000 per conference, that's roughly $16,000-$32,000 I invested in those eleven trips total. Add books at $200-$300 per year over fifteen years: another $3,000-$4,500. Let's call it $20,000-$35,000 of my own money over fifteen years in the gaming industry. #### **Here's what I got for that investment:** I became a senior manager and director while my university classmates were being promoted to senior individual contributor roles. That's a 3-5 year career acceleration. I had job offers I could decline. When a company tried to underpay me, I had options. When a role wasn't right, I could walk away. Most professionals can't do that. I built a network across the gaming industry. When I wanted to solve a problem, I knew people at a dozen other companies who'd already solved it. I learned approaches from studios I'd never work for, techniques from platforms I'd never use, and frameworks from contexts completely different from mine. That cross-pollination made me better at my actual job. I eventually became someone people recognized in the industry. They asked me to speak at conferences. To consult. To help their companies improve. **But here's the part most people miss:** The biggest return wasn't the career acceleration or the salary increase or the industry recognition. The biggest return was control. I controlled when my career moved forward, not my company's budget cycle. I controlled what skills I developed, not my manager's opinion of what I needed. I controlled my trajectory, not HR's succession planning spreadsheet. ### The Conference That Changed Everything That first GDC I paid for myself, the one where I brought my resume, I learned how other development teams were approaching process improvement. My company didn't need me to know that. But six months later, when we faced a major process breakdown, I had already seen three different approaches to solving it. I implemented a solution that saved the project. That solution got me promoted. That promotion led to more responsibility. That responsibility led to more opportunities. **That single $3,000 investment paid for itself dozens of times over.** Not because the conference was magical. Because I was learning things that advanced my career goals, not just my current job requirements. ### What I Learned About Companies and Career Development After fifteen years of investing in my own growth while watching companies manage training budgets, here's what I know for certain: > Companies will invest in your current role. They won't invest in your future roles. When my company paid for conferences, it was because the conference directly benefited a project they cared about right then. When they said no, it wasn't personal. It just wasn't their priority. The skills that got me promoted weren't the ones my company paid to develop. They were the ones I invested in developing because I knew where I wanted my career to go. **Your company isn't being cheap. They're being rational.** They're optimizing for business outcomes, not your career outcomes. Those things overlap sometimes. But not reliably enough to bet your career on. ## Your Action Plan: Taking Control This Month Enough theory. Here's exactly what to do. ### Week 1: Identify Your Direction You can't invest strategically if you don't know where you're going. **Answer these questions:** - What role do you want three years from now? (Not your boss's opinion. Yours.) - What skills does that role require that you don't have yet? - What's one skill that would make you more valuable across multiple companies, not just your current employer? **Write down one specific skill.** Not "leadership" or "communication." Something concrete like "leading cross-functional technical projects" or "presenting complex ideas to executives" or "system design for distributed architectures." ### Week 2: Research Your Learning Options For the skill you identified, find: - Three books that people in that space recommend - Two online courses that teach that skill - One local group where people with that skill gather - One conference where people with that skill speak **Spend 2-3 hours researching this week.** You're not buying anything yet. You're mapping your options. ### Week 3: Make Your First Investment Based on your research, pick ONE thing to invest in this month: - If budget is tight: Buy the most-recommended book or join a free local group - If you have $50-$100: Buy an online course and schedule time to complete it - If you can invest $250+: Start budgeting for a conference registration **The key:** Actually do it this week. Don't wait for the perfect time or the ideal option. ### Week 4: Block Your Learning Time Learning doesn't happen in spare time. It happens in scheduled time. Block two hours on your calendar every week specifically for professional development. Treat it like any other important meeting. Because it is. During those two hours: - Read the book you bought - Work through the online course - Attend the local meetup - Research the next learning investment **Protect this time.** When someone tries to schedule over it, say no. ### Month 2: Set Up Your Budget Decide how much you're investing in your career each month. Not what feels comfortable. What your career is actually worth. **Budget options:** - **$50/month:** One book, participation in free groups - **$150/month:** Books, one online course, local meetup participation - **$250/month:** Everything above plus budgeting for one conference per year - **$400/month:** Multiple courses, books, conference budget, workshop opportunities **Here's the perspective shift:** This isn't an expense. It's an investment that compounds. The skills you build this year qualify you for opportunities next year that pay for the investment dozens of times over. ### Month 3: Apply What You Learn The real value comes from application, not consumption. After every book, course, conference, or meetup: 1. Identify one thing you learned that applies to your current work 2. Implement it within the next week 3. Observe what changes 4. Share what you learned with your team or manager **This does two things:** It reinforces your learning through application. And it makes your investment visible to the people who influence your career. ## The Uncomfortable Question You Need to Answer If you're not investing in your own career growth, why would anyone else? Your company won't invest in making you more valuable to other companies. Your manager won't fund learning that qualifies you for roles outside their team. HR won't develop skills that make you more marketable elsewhere. That's not their job. It's yours. **You can wait for permission.** You can hope your company decides you're worth investing in. You can trust that someone else is planning your career trajectory. Or you can take $250 this month and invest it in learning something that advances your actual career goals. One of those paths leads to career acceleration, increased leverage, and real options. The other path leads to hoping your company's priorities align with your career goals. They won't. ## Stop Waiting for Your Company to Decide Your Career Is Worth Investing In I paid for myself to attend GDC eight times because I decided my career was worth more than my company's training budget. That decision to invest my own money in my own growth changed my entire career trajectory. Not because the conferences were magic. Because I stopped waiting for someone else to decide I was worth developing. > **Your company will invest in your value to them. You need to invest in your value to you.** Those are different things. And confusing them is one of the most expensive career mistakes you can make. So here's the question: When was the last time you invested your own money in learning something that advances your career? If you can't remember, you've been waiting too long. **What's the one skill you need to develop but keep waiting for your company to pay for? Drop it in the comments, let's talk about your actual options.** <hr /> **You're great at the work. Let's make it visible.** Ready to stop waiting for permission and start taking control of your career trajectory? Let's talk about your next move: [book a free call](/lets-talk) <hr /> **Related Posts:** - [Why Professional Relationships Drive Career Success More Than Performance](/blog/professional-relationships-drive-career-growth) - [The Respect Paradox](/blog/respect-paradox-proving-yourself-makes-experienced)https://jessestaffordcoaching.com/blog/engineers-love-solving-problems-thats-problemhttps://jessestaffordcoaching.com/blog/engineers-love-solving-problems-thats-problemAt standup, the team made a call. The feature they needed wouldn't be ready in time, but they found an undocumented API that could work.Sat, 08 Nov 2025 00:00:00 GMTAt standup, the team made a call. The feature they needed wouldn't be ready in time, but they found an undocumented API that could work. Problem solved. Deadline safe. Two months later, they went through the full release process again. And external testing. And additional regulatory costs. The workaround didn't work across all jurisdictions. The customer complained. Engineers are highly trained problem solvers. You're amazing at finding problems to solve and finding solutions to them. That's what makes you valuable. It's also what gets you in trouble. ## The problem with being good at problems When you see a problem, you solve it. That's the job, right? Not always. The team saw a clear problem: the platform feature wouldn't be ready before the deadline. They identified a solution using an undocumented API. They executed and hit the date. But they never asked if the date mattered. Product management was never consulted about waiting one month. No one asked if they could reduce scope. The feature was only needed by one customer. They assumed the deadline was the goal. The deadline was just a date. ## Dates feel concrete because they are concrete December 31st is a real day. Q4 ends. The calendar doesn't negotiate. That makes dates feel important. Dates are the easiest thing to focus on because they are the most concrete part of the product. > But concrete doesn't mean critical. Most software deadlines are based on sales targets, quarterly revenue projections, or executive pressure. Very few are actually immovable. The team treated the deadline like physics. It was politics. ## What they should have done When they learned the platform feature wouldn't be ready, they had options they never explored. They could have waited one month. Product management might have been fine with it, but they were never asked. The team assumed they would say no. They could have reduced scope and shipped without the feature since only one customer needed it. Again, product management might have preferred that trade-off. They were never asked. The team knew that scope never goes down. Or they could have communicated the risk. Use the undocumented API but tell stakeholders it might break in certain jurisdictions. Let someone else decide if that risk was acceptable. They did none of these things. They saw a problem and solved it. ## Not every problem needs a solution This is hard for engineers to recognize in the moment. You're trained to solve problems. That's your value and what you're good at. But not every solution adds business value. Not every problem is worth solving. And dates are always made up. Before you jump to solve, ask one question: **How does this benefit the end customer or create value for the business?** If the answer is "it hits the deadline," that's not an answer. That's an assumption. The team assumed hitting the date mattered more than code quality, regulatory compliance, and customer experience. They were wrong. ## Sometimes the best solution is no solution The team could have done nothing. Shipped without the feature. Told product management they'd need another month. Instead they used an undocumented API. They hit the deadline. Then they started over. Just because you can find a solution doesn't mean you should use it. Stop solving every problem you find. Start asking if the problem needs solving at all. ## What to do Monday morning Next time you see a problem and immediately start solving, stop. Ask yourself: Does this problem need solving right now? What happens if we don't solve it? Who decided this was urgent? Talk to product management. They might be fine with the delay. They might prefer reduced scope. They won't know you need trade-off decisions if you don't ask. The deadline feels real because it's on the calendar. The customer's experience is real because it affects your business. Focus on what's real. <hr /> **What's a deadline you hit that you wish you'd pushed back on?** <hr /> **You're great at the work. Let's make it visible.** If you're looking for help communicating trade-offs to stakeholders or knowing when to push back on deadlines, consider contacting me. Let's talk about how you can lead with clarity instead of just hitting dates. [book a free call](/lets-talk)https://jessestaffordcoaching.com/blog/message-delivery-audit-sharing-information-isnthttps://jessestaffordcoaching.com/blog/message-delivery-audit-sharing-information-isntI thought I was being clear. We needed our QA team to shift their approach.Sun, 19 Oct 2025 00:00:00 GMTI thought I was being clear. We needed our QA team to shift their approach. Stop waiting until features were complete to start testing. Get involved earlier. Test continuously throughout development, not just at the end. I explained it in a team meeting. I sent follow-up emails. I talked about it in one-on-ones. Everyone nodded. Everyone said they understood. Three months later, they were still testing the same way they always had. The problem wasn't that they didn't want to change. The problem wasn't that I hadn't communicated the change. The problem was that I had shared information without ensuring they actually heard it. **There's a massive difference between those two things.** ## What Your Team Actually Hears Here's what I learned from that QA situation: your team isn't hearing your current message. They're hearing your current message filtered through every past experience they've had with leadership. The QA team had spent years being told their job was to find bugs. Every performance review, every priority conversation, every crisis meeting reinforced this. Test thoroughly. Catch defects. Don't let broken features ship. So when I told them to start testing before features were complete, their past experiences translated my message into something completely different. What they heard was: "Find bugs faster" or "Test incomplete work AND complete work" or "Add more to your workload." What I actually needed them to hear was: "Your job is changing. You're moving from quality assurance to quality communication. Your role is to tell us continuously whether quality is good enough to keep building, not just to verify quality at the end." That's a fundamental mindset shift. And fundamental mindset shifts don't happen because you explained something once in a meeting. ## The Scar Tissue Problem Every leader who ever disappointed your team member left scar tissue. Every time a previous boss said one thing and did another. Every time priorities shifted without explanation. Every time transparency turned out to be selective. That scar tissue doesn't go away just because you're a different leader. When you announce a new initiative, some of your team is hearing the last three "new initiatives" that launched with fanfare and died quietly. When you talk about work-life balance, someone is remembering the boss who said that right before crunch time hit. When you emphasize collaboration, others are recalling when "collaboration" meant their ideas got ignored. **You're not just competing with your own clarity. You're competing with years of other people's broken promises.** With my QA team, the scar tissue was thick. They'd been pulled into projects late, blamed for quality issues they had no chance to prevent, and told repeatedly that their value was measured by defects found. Years of that experience created a filter that distorted every message about changing their approach. I could say "your job is communication" all I wanted. What they heard through their filter was "find problems faster and tell us about them sooner." Close, but fundamentally different. One is about testing cadence. The other is about redefining their entire role. ## Sharing Information vs Ensuring Understanding Most leaders think communication works like this: I have information. I share the information. The information is now communicated. That's not communication. That's transmission. Real communication requires confirmation that the message landed correctly. Not that people heard words. That they understood the meaning, integrated it with what they already know, and can act on it. **Here's how you know the difference:** Sharing information looks like: "I told them in the all-hands." "It's in the email I sent." "We talked about it in our one-on-one." Ensuring understanding looks like: "They started asking different questions." "I saw them make a decision that reflected the new approach." "They explained it to someone else accurately." With the QA team, I was definitely sharing information. I explained the new approach multiple times. I answered questions. I thought I was being crystal clear. But ensuring understanding would have looked different. I would have asked them to explain back to me what they thought was changing. I would have tested whether they could describe their new role to someone else. I would have watched for whether their daily decisions reflected the shift. I did none of that. I just kept explaining and assumed eventually it would click. ## The Message Delivery Audit After the QA experience, I developed what I now call the Message Delivery Audit. It's based on a simple marketing principle: people need to encounter a message seven times, delivered seven different ways, before it actually registers. **Seven touches. Seven methods.** Not because people are stupid. Because competing with scar tissue, existing mental models, and daily workflow demands requires repetition and variety. Here's what the audit looks like: ### The Seven Touches Count how many times your team has encountered this message. Not how many times you've said it. How many times they've heard it, seen it, or engaged with it. If you're under seven, you haven't communicated it yet. You've started to communicate it. With QA, I thought three months of mentions was enough. But when I actually counted discrete encounters with the message, it was maybe ten times spread across the entire team. For a fundamental mindset shift affecting eight people's daily work? Nowhere near enough. ### The Seven Methods This is where most leaders fail. They use the same channel repeatedly and think they're communicating. I kept talking about the QA shift in meetings and one-on-ones. Same method. Same context. Same format. What actually worked was changing how the message was delivered: **1\. Planning Sessions** We started doing QA planning at the beginning of each project, not the end. They had to articulate what quality meant for this specific feature before development started. This forced them to think about their role differently, they were defining quality standards, not just verifying against them. **2\. Status Updates with On Track/Off Track** We changed the status update format. Instead of "found 12 bugs," the updates became "quality is On Track" or "quality is Off Track for shipping on Friday." This shifted the conversation from bug counting to quality judgment. They had to communicate about readiness, not just problems. **3\. Game Discussions** We included QA in early game design conversations. Not to test anything yet. To understand what quality would mean for player experience. This reinforced that their expertise was about understanding quality, not just executing test cases. **4\. Decision Authority** We gave QA the authority to call whether quality was good enough to ship. Not just report findings, make the call. This forced them to own the communication role, not just execute the testing role. When you're responsible for the decision, you can't just be the messenger. **5\. Recognition and Feedback** When someone on the QA team communicated about quality well, "we're off track for Friday but on track for Monday if we adjust scope", I called it out specifically. I reinforced the behavior I wanted with recognition. Different method again. **6\. Documentation Updates** We rewrote the QA process documentation together. They had to articulate the new approach in writing. Seeing their own words describe the change made it more real than hearing my words. **7\. Teaching Others** I had the QA lead explain the new approach to a different team. Teaching forces clarity. You can't explain something you don't truly understand. This was the confirmation that the message had finally landed. Notice what happened: the same core message got delivered through planning formats, status structures, meeting inclusion, decision authority, recognition patterns, documentation, and teaching opportunities. **That's seven different ways. Each one reinforced the others.** ## What the Audit Reveals When you run a Message Delivery Audit on an important message, you'll usually discover two things: **First, you've barely started communicating.** You think you've mentioned something repeatedly because it feels repetitive to you. But you've encountered your own message dozens of times while preparing it, thinking about it, and delivering it. Your team has encountered it maybe twice. **Second, you're using one or two methods at most.** Usually talking and email. Maybe a Slack message. You're not varying the delivery mechanism enough to break through the noise and competing priorities. The audit forces you to get specific: - What exactly is the message? - How many times has each team member actually encountered it? - How many different methods have I used? - Have I created opportunities for them to engage with it, not just hear it? - What evidence do I have that understanding occurred? With my QA team, running this audit (after the fact, unfortunately) showed me I'd delivered the message maybe four times, using two methods (talking and email). No wonder it hadn't landed. ## The Mindset Shift That Matters The QA experience taught me something crucial about leadership communication: **your job isn't to share information. Your job is to ensure understanding.** Those require completely different approaches. Sharing information is efficient. You say it once. Maybe twice. You move on. Your calendar is clear. Ensuring understanding is inefficient. You say it multiple ways. You watch for comprehension signals. You adjust when signals aren't there. You create structures that force engagement with the idea. Your calendar fills up with communication activities that feel redundant. **But only one of those approaches is actually leading.** Leaders who just share information end up frustrated. "I told them this months ago. Why aren't they doing it?" The answer: because you told them, but they didn't hear you. Not really. Not through their scar tissue. Not integrated with their existing understanding of their role. Leaders who ensure understanding invest time upfront in varied communication. They feel like they're being repetitive. They worry they're over-communicating. But their teams actually change behavior because the message landed. ## What Good Looks Like You'll know your message actually landed when you see three things: **1\. They explain it to others accurately.** Not in your words. In their words. Using their own examples. When my QA lead explained the new approach to another team and got it right, I knew the message had integrated with his understanding. **2\. They make decisions aligned with the message without you there.** The real test: what do they do when you're not in the room? When QA started saying "we're on track" instead of "we found bugs," I knew they'd internalized the shift. They were making the right judgment calls independently. **3\. They ask different questions.** When people truly understand something new, their questions change. Early on, my QA team asked, "When should we start testing?" Later, they asked, "What does quality mean for this feature?" The question shift showed the mindset shift. If you're not seeing these three things, you haven't communicated yet. You've transmitted. The message is still sitting in the outbox. ## Your Monday Morning Audit Here's how to use this immediately: **Pick one important message you need your team to understand.** Not ten things. One. The strategic shift, the priority change, the new expectation that really matters. **Run the audit:** 1. Write down exactly what you need them to understand (not just what you want them to do) 2. Count how many times each team member has encountered this message 3. List the methods you've used to deliver it 4. Identify evidence that understanding occurred (or didn't) **If you're under seven touches through at least five different methods, you're not done communicating.** Design your next seven touches: - Where can you build this into existing structures? (planning, status updates, reviews) - What decision authority could reinforce it? - Who could teach it to someone else? - What decisions would confirm they understand it? - How will you recognize the behavior you want? **Then commit to the repetition.** It will feel redundant. You'll think "I've already said this." You'll worry about over-communicating. Do it anyway. Because the alternative is what I did with my QA team: assume clarity happened the first time, get frustrated when behavior doesn't change, and waste months wondering why smart people aren't getting it. They were getting it. I just hadn't actually delivered it yet. **What messages have you been trying to communicate that aren't landing? What methods have worked for you when repetition alone hasn't?** Share your experience in the comments. <hr /> **You're great at the work. Let's make it visible.** If you're struggling to get important messages to land with your team, or you're tired of feeling like you're not being heard, let's talk about how you can move from sharing information to ensuring understanding. ### [Contact me here](/lets-talk)https://jessestaffordcoaching.com/blog/managing-managers-isnt-control-clarityhttps://jessestaffordcoaching.com/blog/managing-managers-isnt-control-clarityYou just got promoted. Congratulations.You’re now leading managers, the people who lead the people.Mon, 13 Oct 2025 00:00:00 GMTYou just got promoted. Congratulations.You’re now leading managers, the people who lead the people. That means your job has changed in a fundamental way. You’re no longer the person who *does* the work or even directly manages those who do it. You’re the person who creates enough clarity that others can lead effectively *without you.* ## **The First Shock: Progress Feels Slower** When you managed individuals, you could move fast, jump into the details, fix issues, and see progress that same afternoon. Now? Everything feels slower. Not because your team is weaker, but because your intent has to travel through two layers of interpretation. Every gap in clarity multiplies as it moves down the org chart. Your new challenge isn’t doing more; it’s *being understood faster.* ## **Your Real Work Is the Communication Loop** Clarity doesn’t end when you hit “Send” or finish a meeting. You have to *close the loop.;* That means: - Checking that your message landed the way you intended - Listening for how it’s being retold by your managers - Watching how decisions are made when you’re not in the room You’re not just communicating, you’re calibrating. If what your managers say to their teams doesn’t sound like what you meant, that’s not their failure. It’s feedback on your clarity. ## **Coach the “How,” Not the “What”** When your direct reports are managers, success isn’t about their output anymore; it’s about *how* they lead. That means shifting your conversations from: > > “Did your team hit the milestone?” > > to > > “How did you help your team get there?” You’re no longer a fixer, you’re a multiplier. Every coaching moment with a manager ripples through their entire team. ## **Build a Rhythm for Alignment** Skip-level conversations, weekly priorities, and structured reflection time aren’t “nice-to-haves.” They’re your visibility system. You need a consistent rhythm of: - **Setting direction:** Define the “why” and “what.” - **Syncing understanding:** Confirm alignment before execution. - **Surfacing friction:** Create space for managers to bring issues early. That rhythm keeps everyone connected to the same goals and stops you from being surprised when projects drift off course. ## **Protect Time to Think** You can’t delegate clarity. Block time each week to zoom out; review progress, refine your message, and think about strategy. If you don’t make time to think during work hours, your brain will find time for you at 2 a.m. ## **Bottom Line** Managing managers isn’t about having more authority. It’s about having more patience, more clarity, and better loops. You’re no longer leading people; you’re leading the people who lead people. Get that right, and the organization moves as one.; <hr /> If you’re growing into a director or senior manager role and want help building clarity and communication rhythms that scale, connect with me at [Jesse Stafford Coaching](/). *You’re great at the work. Let’s make it visible.*https://jessestaffordcoaching.com/blog/respect-paradox-proving-yourself-makes-experiencedhttps://jessestaffordcoaching.com/blog/respect-paradox-proving-yourself-makes-experiencedYou just got promoted. Congratulations.Mon, 13 Oct 2025 00:00:00 GMTYou just got promoted. Congratulations. Now you're leading someone who's been doing this work since before you graduated college. Maybe they started at the company when you were in high school. Maybe they interviewed you once and didn't hire you. And now you're their manager. Here's the paradox: New leaders think they need to prove they deserve the role before they can lead experienced people. But experienced people won't follow you until you show them you value their experience. Most new managers get this backwards. They think their job is to have answers. So they start managing everyone the same way. "Here are your assignments. Here are the deadlines. Let me know if you have questions." That approach fails with experienced people. Not because they won't do the work, but because you just told them their 15 years of experience doesn't matter. ## **What New Leaders Mistake for Respect** You think treating everyone equally is fair. It's not. It's lazy. You think staying distant maintains authority. It doesn't. It signals you're intimidated. You think proving you know what you're doing earns respect. It won't. Experienced people already know you don't know what they know. Here's what I got wrong: I once led someone who started at the company before I graduated high school. I needed them to change direction with the company. I started by managing them like everyone else. Assignments. Deadlines. Check-ins. It didn't work. They became distant. They stopped sharing what they knew. They did exactly what I asked and nothing more. ### **What Actually Works** Respect isn't earned by proving yourself. It's given first. I changed my approach. I asked them to present their experience to the team. I opened every conversation by asking them to bring their expertise to the table before I asked them to do anything. I asked questions. That worked. Here's the tension most new managers miss: You think asking questions makes you look weak. Experienced people think not asking questions means you don't value what they know. Your job isn't to have all the answers. Your job is to create an environment where your team can have answers. Experienced people already know this. They know they need to ask questions to understand decisions and direction. They're waiting to see if you know it too. ## **The Second Mistake I Made** I once managed someone who didn't hire me for a contributor role at the company. Then I became their manager. It took me six months before I could give them real feedback. I was intimidated. I respected their history at the company. I carried that rejection into every conversation. Then my boss had a hard conversation with me. I wasn't meeting goals. Something needed to shift with this person's team. I needed to give them feedback or we'd both be in trouble. ! I read Radical Candor. I changed my approach. I started being direct. I stopped avoiding the hard conversations because I was intimidated. The lesson: Respect their experience, but don't abdicate your responsibility to lead. They need you to bring clarity about business goals. They need you to make decisions when the team can't. They need you to tell them when something isn't working. ## **What to Do Tomorrow** Lead with curiosity. Here's what that looks like: Ask them to share their history with the team and company. What's going well? What isn't? Ask for their opinion on how to achieve the goal before you assign anything. Then have an honest conversation about business needs around the goal. Share context. Share constraints. Share why this matters to the business. Stop here most of the time. Let them figure out how to get there. Your position in the org chart should be used to share information that helps them apply their experience toward your goals. ## **When to Stop Asking and Start Directing** You stop asking when: - The team needs to make a pivot they don't or cannot see - The business need requires a specific approach - The team cannot make the decision for themselves But that should be the exception, not your default. Experienced people want two things from you: Listen to them. Respect their experience. Ask for their input, show them that you heard it, explain the direction considering their feedback. If you do that, they'll follow you. Not because you proved you deserve the role, but because you showed them you trust what they know. **P.S.** Stop using the word "subordinates." These are people who know more about getting work done than you do. Treat them that way. *You're great at the work. Let's make it visible.* If you're navigating this kind of leadership challenge, connect with me at [Jesse Stafford Coaching](/).https://jessestaffordcoaching.com/blog/communication-gap-triggers-micromanagement-closehttps://jessestaffordcoaching.com/blog/communication-gap-triggers-micromanagement-closeAfter 15 years leading teams, I've seen this pattern dozens of times: talented people getting micromanaged not because they're struggling, but because...Sun, 12 Oct 2025 00:00:00 GMTAfter 15 years leading teams, I've seen this pattern dozens of times: talented people getting micromanaged not because they're struggling, but because they're invisible. Their manager doesn't know what's happening, so they start digging. Here's how to break the cycle before it starts. Are you frustrated with your manager's over-involvement in your projects? Do they check in on your status too often? Does your manager think they know more about the work than you do? What about those times when they redo your work for no reason? You have to wonder: with how busy our managers must be, how do they find so much time to control everything? ## The Micromanagers To understand how to fix this, we need to explore why different managers end up micromanaging. Over time, I've observed various kinds of micromanagement, each with distinct ways and reasons for managers to get over-involved. These are not one-size-fits-all situations. At some point, every manager will probably exhibit each of these personas. ### The Doers ! One of the most common micromanagement styles is the doer. These are the managers who were once good at their team's job. More often than not, these people were promoted into management for their talent at getting the job done, and struggle with letting go. These micromanagers will usually give you detailed steps and checklists. They know what is happening because they tell you exactly what to do. These managers micromanage because they are uncomfortable with not knowing the daily details about how the work is getting done. ### The Taskmasters ! The next most common micromanager is the taskmaster. These managers need to know the plan and how much progress has been made. If they don't see every step the team takes, the project's outcome is not certain enough to satisfy them. Taskmasters hold many meetings and impromptu check-ins to get updates on short-term progress. These managers are uncomfortable with uncertain outcomes. ### The Amplifiers ! Amplifiers want to be able to confidently relay status and progress up the chain, probably to a taskmaster. ## The Pattern I Keep Seeing Here's what I've learned from both sides of the equation: in almost every case above, these managers feel like they don't know what is going on and don't know how to ask for what is missing. Or they're stepping in because nobody seems to be stepping up to ensure things are organized. The pattern is simple. These managers are looking for more information and team members who show they don't need to be told what to do. Once you see this pattern, you can give them what they need. ## Three Habits That Trigger the Pattern Before you start changing the dynamic, you need to recognize the habits that trigger micromanagement in the first place: 1. Only sharing when the work is complete, or you need a new task 2. Asking permission 3. Being worried about their time ### 1\. Lift Your Head and Share Stop putting your head down and only coming up for air when the work is complete. Many of us find it easy to get focused and work through the problems and tasks in front of us right to the end. This is one of the things that causes your manager to get uncomfortable and triggers micromanagement. It is easy to believe that since our managers assigned us a task, then they know what we are doing, but no news is not good news to a micromanager. ### 2\. Don't Ask Permission to Do Your Job "Sorry to bother you, but can I work on my weekly report tomorrow?" When you ask permission, you tell your manager that you cannot progress without their approval. You are telling them you are stuck, and they must stop what they are doing to get you moving. The micromanager hears you say, "You have to own the next steps and tell me what to do. I am not accountable." Many of us were taught from a young age to respect our elders and those in authority positions. However, there are ways to honor these values without encouraging the micromanagers around us. ### 3\. Your Manager is Not Too Busy It is your manager's responsibility to manage their own time. Frankly, if they have the time to micromanage you, they have time to receive your information. You do not need to worry about how busy they are. If your manager wants more information, give it to them. Overcommunication is not possible in a professional environment. Think about how often you feel like too much about a project is being shared with you. Share everything that can be shared. ## How to Break the Pattern It's time to build a new habit around proactive communication. I like to call it showing your work. Just like back in school when your math teacher wanted to show all the steps, showing your work lets your manager know how you plan to solve the problem (Doers), how much time you think it will take (Taskmasters), and when you will follow up on the status (Amplifiers). The difference between now and school is when you show your steps. In the professional world, you must explain the steps before doing the work, not wait until you get the correct answer. ### I Plan To "I plan to finish my weekly report tomorrow." "I intend to work with the marketing department to ensure they have all relevant information." Showing your work starts with sharing your plans. This is not asking. When you say "I Plan To" or "I Intend To," your manager hears: "Hey, I am going to do this unless you stop me." You are telling your manager you will do this, and now is the time to provide guidance or course correction. It shows that you are ready to own this project. > **Here is a leadership secret: this is what initiative looks like.** ### Update Update Update Create a reminder to regularly and proactively share your progress: what is going well, what has been unexpected, where you could use guidance, and the next steps in your plan. If you ensure these updates are consistent and thorough, you will keep your manager fed with enough information to keep them at bay. They will have what they need to be comfortable with the project in your hands. ### Share When You Are Done Finally, check in with your manager when you are done. Show them the completed work, tell them what you learned, and share what you are working on next. Remember, "I Plan To." ## What I've Learned After years of managing teams and being managed, this pattern is predictable. Micromanagement happens when there's an information gap. Your manager craves more information to the point of needing to dig into everything you do. The leaders who escape this cycle don't wait for their manager to change. They change what triggers the behavior. Stop waiting for them to give you tasks and for them to ask for updates. Start proactively showing your work: I plan to, share your progress along the way, and ask for feedback at the end. Begin replacing the words "May I" with "I Plan To." Then, reflect on how that changes your own perception of your autonomy. **Want more help improving how to show your work?** [Consider reaching out to me](/lets-talk). You're great at the work. Let's make it visible.https://jessestaffordcoaching.com/blog/department-chairs-relationship-problemhttps://jessestaffordcoaching.com/blog/department-chairs-relationship-problem(And Why It’s Killing Your Influence) You became chair because you’re brilliant at your discipline. You’ve published, mentored, and earned respect.Sun, 12 Oct 2025 00:00:00 GMT*(And Why It’s Killing Your Influence)* You became chair because you’re brilliant at your discipline. You’ve published, mentored, and earned respect. Then, overnight, the job changed from doing great work to leading people, many of them, your peers. And now? You’re isolated. You’re buried in admin work no one trained you for. You hesitate to ask for help because you don’t want to look lost. You avoid cross-campus connections because it feels political, and you didn’t sign up for politics. Meanwhile, your department stalls. Your initiatives die in committee. You’re working 60 hours a week and wondering what you’re doing wrong. Here’s the truth no one told you: > **Your success as chair has less to do with your scholarship and everything to do with your relationships.** **Here’s the playbook:** understand the isolation trap, redefine your team, build cross-campus relationships, make them reciprocal, and start small, but start now. ## **The Isolation Problem** Universities know this role is lonely. That’s why some have created “chair circles” to shrink the distance, boost confidence, and bring purpose back to the job. If you’re honest, when was the last time you: - Had coffee with another chair to talk shop? - Called a peer at another school for advice? - Met with IT or facilities just to learn how they work? - Asked someone in the dean’s office what keeps them up at night? If your answer is *rarely*, you’re not alone. Most new chairs avoid relationship-building because it feels like networking, and networking feels gross. Let’s fix that thinking. ### **Why Academics Resist Relationship-Building** Academia prizes independence. We value being right more than being connected. But here’s the problem: **you can’t lead in isolation.** This isn’t about schmoozing. It’s about understanding how your institution runs and who actually makes it run. Relationships get your department funded, staffed, and supported. They help you navigate conflict, influence decisions, and advocate effectively. Everyone around you is smart and hardworking. What separates successful chairs is their ability to build trust across the institution. > > “Dialogue leads to connection, which leads to trust, which leads to engagement.”, Seth Godin ## **Redefining “Team”** Your team isn’t just your faculty. > **Your team is everyone who helps move your initiatives from idea to done.** That includes: - Faculty and staff - Peer chairs - Associate deans and operations staff - Admissions, facilities, IT, HR, development Big initiatives (new programs, accreditation, enrollment, budgets) cross boundaries. The corporate world figured this out decades ago. Higher ed is still catching up. ### **Why Relationships Matter** Let’s get practical. ### 1\. They change how you see others When admissions misses targets or IT delays your request, it’s easy to assume incompetence. Strong relationships replace frustration with understanding and open doors to collaboration. ### 2\. They make your department more effective Know how and when decisions happen. Align your requests with the dean’s priorities. Translate institutional processes for your faculty. > **Example:** > If you understand the budget cycle, you’ll know *when* to request that new faculty line and *how* to frame it so it lands. ### 3\. They give you a voice Most decisions happen when you’re not in the room. If you haven’t built relationships with people who are, your department doesn’t have representation. ### 4\. They grow your perspective The best chairs are “T-shaped”: deep in one area, broad across many. You build that breadth by being curious about others’ worlds, budget, enrollment, IT, and development. ### 5\. They create opportunity Opportunities rarely come from open calls. They come from trust. When a dean needs someone reliable, they think of the chairs they know. ### **Make It Reciprocal** Relationships fail when they’re one-way. Be helpful. Offer what you know. Lend perspective. Listen more than you talk. Maybe another chair needs to vent. Maybe the dean’s office needs feedback from the field. Maybe someone in admissions needs your insight. > **Avoid saying:** “That’s not my job.” That phrase kills influence faster than budget cuts. ## **Where to Start** You’re thinking, *I don’t have time for this.* You don’t have time *not* to. Every hour spent building relationships saves dozens later. Start small. Start now. ### 1\. Your department staff They know everything. Treat them like partners, not assistants. ### 2\. One peer chair Ask what they wish they’d known in year one. Schedule a monthly coffee. ### 3\. Someone in the dean’s office They control access to information and often know more than the dean. Then expand to: - Chairs of potential partner departments - Associate deans and assistant provosts - Student services, admissions, and IT - Development officers ## **How to Reach Out** Put it on your calendar. Then do it. **Sample outreach:** > “Hi \[Name\], I’m chair of \[Department\]. I’d love to learn how \[their area\] works so I can collaborate better. Would you have 30 minutes for coffee next week?” **When you meet, ask:** - What’s most challenging about your role? - What do you wish chairs understood? - How can I make your job easier? And always end with: *How can I help you?* ## **The Long Game** Build relationships before you need them. When budget cuts hit or you’re trying to retain key faculty, those connections pay off. This isn’t politics. It’s leadership. Nothing meaningful in higher ed gets done alone. The chairs who invest in relationships are the ones whose departments thrive even in hard times. ## **Final Thought** You didn’t become chair to “network.” You did it to make an impact. So apply your scholarly curiosity to people, not just ideas. Be genuine. Be curious. Be helpful. Be human. In academic leadership, as in research, **collaboration always beats isolation.** ### Related Resources - [Stop Managing Your Dean and Start Showing Your Work](/blog/stop-managing-dean-start-showing-work) - [How to Lead Faculty Who Don’t Want to Be Led](/blog/lead-faculty-dont-want-led) Want to build relationships that move your department forward? [Let’stalk.](/lets-talk) *You’re great at the work. Let’s make it visible.*https://jessestaffordcoaching.com/blog/im-managing-my-former-peershttps://jessestaffordcoaching.com/blog/im-managing-my-former-peersYou just got promoted. Congratulations.Sun, 12 Oct 2025 00:00:00 GMTYou just got promoted. Congratulations. You're now managing people who were your equals last week. Here's what nobody tells you: the hardest part isn't managing your former peers. It's that you haven't stopped being their peer yet. ## The Problem Isn't Your Old Relationships Most advice about managing former peers focuses on "establishing authority" or "setting boundaries." That's not wrong, but it misses the real issue. The problem is you're still thinking like a peer. You still wait for consensus before making calls. You still answer every question directly instead of asking why they're asking. You still treat decisions like group projects instead of your job. Your team isn't confused about the org chart. They're confused because you are. ## What It's NOT **It's not treating everyone the same.** You think fairness means acting like nothing changed. It doesn't. Your friend who struggles with deadlines needs different management than your friend who doesn't. Pretending otherwise isn't fair. It's avoidance. **It's not being "one of the team."** You're not. You can be respected, trusted, even liked. But you make decisions about their work, their performance, their careers. That's not a peer relationship, and pretending it is makes you a bad manager and a worse friend. **It's not avoiding hard conversations because you know their situation.** You know Sarah's going through a divorce. That context matters. But if her work is suffering, knowing why doesn't mean you don't address it. It means you do it with more care, not less accountability. ## The Wake-Up Call I realized I was failing six months in. We were in San Francisco for a work trip. Five of us. We finished a meeting and headed out to find lunch. > **They followed me down the street. Through intersections. Around corners.** > > **I had no idea where I was going. I walked us in a complete circle.** Nobody questioned it. Nobody said "hey, where are we actually going?" They just followed. That's when it hit me: they were waiting for me to decide. Not because I knew San Francisco. Because I was their manager. And I had been avoiding exactly that for six months. ## What I Was Actually Avoiding Not big strategic decisions. Everyday stuff. Which direction do we go? What do we prioritize? How do we handle this? When do we push back? I thought I was being collaborative. I was waiting for consensus. Asking for input. Letting the team weigh in. What I was actually doing: avoiding my job. The team missed sprint goals. Multiple sprints. Because I wouldn't make the call on what mattered and what didn't. I treated every question like a discussion instead of a decision point. Someone would ask "should we do X or Y?" and I'd answer the question. Give them the information. Solve their problem. I should have been asking "why are you asking?" and "what do you think?" and "what's the actual goal here?" I wasn't guiding. I was just another peer with slightly more context. ## The First Real Decision I changed our sprints from two weeks to one week. Our business was prototyping. Rapid iteration. The business couldn't wait two weeks for feedback. Neither could we. The team pushed back. One week felt too fast. Too much overhead. Too chaotic. I made the call anyway. It was rough at first. But it worked. The business saw us as more responsive. We got better at breaking down work. We had more flexibility. More importantly, I stopped apologizing for making the decision. I owned it. ## What Changed I stopped thinking my job was to make decisions. My job is to create an environment where my team can make decisions. Now when someone asks me a question, I don't just answer it. I ask what they're trying to solve. I give them context about why we're doing the work and what success looks like. Then I let them figure it out. I make the decisions they can't make. The trade-offs between competing priorities. The calls that need manager-level context or authority. But I don't make their decisions for them. That's not management. That's bottlenecking. ## The Mistake I Made I got promoted to manage my team. I thought staying collaborative meant avoiding decisions. It didn't. They didn't need me to be their peer. They needed me to be their manager. To make calls when calls needed making. To give them clarity so they could make their own calls. The people who respected me most weren't the ones I tried to keep happy by avoiding decisions. They were the ones I gave clear direction, held accountable, and trusted to do their jobs. ## What to Do Monday Look at your last week. Find the decisions you avoided. The question you answered directly instead of coaching through. The priority call you waited for consensus on. The direction you didn't give because you thought it would feel too "manager-y." Pick one. Make the call. Give the clarity. Stop waiting. You're not their peer anymore. Start acting like their manager. **Because when you start acting like their manager, they can finally start acting like your team.** > *Leadership starts when you stop waiting for consensus and start creating clarity.* You're great at the work. If you're ready to make it visible, let's talk. [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/lead-faculty-dont-want-ledhttps://jessestaffordcoaching.com/blog/lead-faculty-dont-want-ledYou can’t fire them. You can’t promote them.Sun, 12 Oct 2025 00:00:00 GMTYou can’t fire them. You can’t promote them. You can’t give big raises. And last semester, they were your peers. Now you’re chair responsible for budgets, outcomes, and student success with a team that technically reports to you but answers to no one. Some even think you “joined the dark side.” > **Welcome to academic leadership: authority without power.** But here’s the truth: this isn’t a hopeless job. It’s just a different kind of leadership. One built not on *control,* but on *influence, clarity,* and *trust.* Here’s what that really looks like. ## **The Chair’s Real Job** You’re not here to manage faculty. You’re here to lead colleagues. That means: - Remove obstacles so people can do their best work - Build consensus around what matters - Translate and advocate between faculty and administration - Create conditions where faculty want to contribute - Show your work so others see how individual choices drive collective outcomes > **Try this:** Spend one week asking, *“What’s getting in your way?”* more than you ask, *“What are you working on?”* You’ll learn more and build more goodwill than in a semester of meetings. ## **Six Principles That Actually Work** ### 1\. Be Clear on How Decisions Get Made Ambiguity breeds drama. Clarity builds trust. > **Try this:** Map out every common decision your department makes and who owns it. Share the list. Invite edits. Post it. When everyone knows the process, they stop fighting over it. When in doubt, consult. You can always move faster than you can repair trust. ### 2\. Show Strength Through Vulnerability Faculty know when you’re bluffing. Don’t. > **Try this:** Start department meetings with one honest “constraint from above” you’re navigating. Then ask: *“How would you approach it?”* It shifts the tone from defending to collaborating. Vulnerability isn’t weakness; it’s the fastest route to credibility. ### 3\. Lead Through Motivation, Not Mandate Tenured faculty don’t respond to pressure. They respond to purpose. > **Try this**: Ask each faculty member, “What part of your work gives you the most energy?” > Then connect departmental goals to those sources of motivation. Influence follows alignment. ### 4\. Make the Invisible Visible Most faculty don’t see the domino effect of their choices. > **Try this:** Once a semester, show a simple slide: > “Here’s where our budget, enrollments, and research output come from.” Keep it factual. No spin. Clarity turns skeptics into collaborators. ### 5\. Create Conditions, Not Compliance You can’t force engagement, but you can make it easier. > **Try this:** > > - Make service assignments public so everyone sees workload balance. > - Celebrate small wins in meetings. > - Block time for your own deep work and tell them why. Model the environment you want to scale. ### 6\. Escalate Wisely You won’t win every battle, and you don’t need to. > **Try this:** Before escalating, ask yourself: > “Is this a hill to die on, or a rock to walk around?” Document, decide, and move on. Protect your energy for where you can make progress. ### The Conversations You’re Avoiding You don’t need perfect language, just courage and clarity. **Performance:** “What’s getting in the way of your research right now?” **Resources:** “Here’s the progress we’ve made, here’s what we could do with one more line.” **Succession:** “What do you want your legacy to look like when you step back?” These aren’t confrontations. They’re leadership in practice. ### What Success Looks Like Not control. Not perfection. Just movement in the right direction: - Faculty show up because they want to - Problems surface early - Wins get shared widely - The department’s reputation grows quietly but steadily You won’t make everyone happy. But you’ll make the work matter. If you are ready for some support navigating this uncertain role, [let’s talk.](/lets-talk) *You’re great at the work. Let’s make it visible.*https://jessestaffordcoaching.com/blog/peers-control-success-build-those-relationshipshttps://jessestaffordcoaching.com/blog/peers-control-success-build-those-relationshipsYour project just got killed in a meeting you weren't invited to. The VP who torpedoed it?Sun, 12 Oct 2025 00:00:00 GMTYour project just got killed in a meeting you weren't invited to. The VP who torpedoed it? You've never had a real conversation with them. **This happens more than you think.** Most leaders schedule 1-on-1s with their directs and skip-levels. Almost nobody schedules them with peers. That's leaving influence on the table. ## Why sideways relationships matter more than you realize Your next project will require budget from Finance, support from IT, or alignment with Operations. If the first time you're talking to those leaders is when you need something, you're already behind. **The pattern I see constantly:** Leaders who struggle to get things done often have great relationships up and down the org chart, but nothing sideways. > "Build relationships before you need them. If the first time you're talking to those leaders is when you need something, you're already behind." ## How to actually do this **Start simple.** Pick 3-5 peers in other departments. Send a calendar invite for 30 minutes monthly or quarterly. ### **The format that works:** - 10 minutes: What's keeping you up at night? - 10 minutes: What I'm working on - 10 minutes: Where might we help each other? ### **What to avoid:** - Making it transactional (don't lead with asks) - Canceling when things get busy (that's when you need them most) - Only meeting when there's a problem ## What good looks like You know someone well enough to: - Understand their priorities (not just your needs) - Text them a quick question - Give them a heads up before surprises hit **Real example:** A tech leader I coached scheduled quarterly coffee with the CFO. Six months later, when budget cuts came, Finance called *him* first to collaborate on where to trim. His projects survived. Others didn't. The difference? He knew what kept the CFO up at night. When cuts were inevitable, he was a partner in the solution, not a victim of the decision. ## Your move Look at your calendar right now. If you don't have standing 1-on-1s with at least three peers outside your department, block 30 minutes this week to set them up. **Why this works:** Influence isn't about authority. It's about relationships. And relationships are built in the boring, consistent conversations nobody else is having. The leaders who get things done aren't necessarily smarter or more strategic. They just know more people. And those people actually return their calls. <hr /> **You're great at the work. Now make it visible.** If you need help building influence across your organization, let's talk: [Jesse Stafford Coaching](/)https://jessestaffordcoaching.com/blog/stop-being-micromanaged-without-waiting-managerhttps://jessestaffordcoaching.com/blog/stop-being-micromanaged-without-waiting-managerYour manager is micromanaging you. They probably don't want to.Sun, 12 Oct 2025 00:00:00 GMTYour manager is micromanaging you. They probably don't want to. You definitely don't want them to. So why does it keep happening? Because there's a gap between what they need to feel confident and what you're giving them. Good news: you can close that gap. Are you frustrated with your manager's over-involvement in your projects? Do they check in on your status too often? Does your manager think they know more about the work than you do? What about those times when they redo your work for no reason? You have to wonder: with how busy our managers must be, how do they find so much time to control everything? ## **The Micromanagers** To answer this question, we need to explore why different managers end up micromanaging. Over time, I've observed various kinds of micromanagement, each with distinct ways and reasons for managers to get over-involved. These are not one-size-fits-all situations. At some point, every manager will probably exhibit each of these personas. ### **The Doers** !One of the most common micromanagement styles is the doer. These are the managers who were once good at their team's job. More often than not, these people were promoted into management for their talent at getting the job done and struggle with letting go. These micromanagers will usually give you detailed steps and checklists. They know what is happening because they tell you exactly what to do. These managers micromanage because they are uncomfortable with not knowing the daily details about how the work is getting done. ### **The Taskmasters** !The next most common micromanager is the taskmaster. These managers need to know the plan and how much progress has been made. If they don't see every step the team takes, the project's outcome is not certain enough to satisfy them. Taskmasters hold many meetings and impromptu check-ins to get updates on short-term progress. These managers are uncomfortable with uncertain outcomes. ### **The Amplifiers** !Amplifiers want to be able to confidently relay status and progress up the chain, probably to a taskmaster. ## **A Common Thread** I know that at this point, these still seem like problems they need to solve for themselves. However, in almost every case above, these managers feel like they don't know what is going on and don't know how to ask for what is missing. Or because nobody seems to be stepping up to ensure things are organized. The common thread is that these managers are looking for more information and team members who show they don't need to be told what to do. You can do this for them. ## **It's Time to Break Habits** You must break some habits before you start getting your manager to back off: 1. Only sharing when the work is complete, or you need a new task 2. Asking permission 3. Being worried about their time ### **1\. Lift Your Head and Share** Stop putting your head down and only coming up for air when the work is complete. Many of us find it easy to get focused and work through the problems and tasks in front of us right to the end. This is one of the things that causes your manager to get uncomfortable and triggers micromanagement. It is easy to believe that since our managers assigned us a task, then they know what we are doing, but no news is not good news to a micromanager. ### **2\. Don't Ask Permission to Do Your Job** "Sorry to bother you, but can I work on my weekly report tomorrow?" When you ask permission, you tell your manager that you cannot progress without their approval. You are telling them you are stuck, and they must stop what they are doing to get you moving. The micromanager hears you say, "You have to own the next steps and tell me what to do. I am not accountable." Many of us were taught from a young age to respect our elders and those in authority positions. However, there are ways to honor these values without encouraging the micromanagers around us. ### **3\. Your Manager is Not Too Busy** It is your manager's responsibility to manage their own time. Frankly, if they have the time to micromanage you, they have time to receive your information. You do not need to worry about how busy they are. If your manager wants more information, give it to them. Overcommunication is not possible in a professional environment. Think about how often you feel like too much about a project is being shared with you. Share everything that can be shared. ## **Build A New Habit** It's time to build a new habit around proactive communication. I like to call it showing your work. Just like back in school when your math teacher wanted to show all the steps, showing your work lets your manager know how you plan to solve the problem (Doers), how much time you think it will take (Taskmasters), and when you will follow up on the status (Amplifiers). The difference between now and school is when you show your steps. In the professional world, you must explain the steps before doing the work, not wait until you get the correct answer. ### **I Plan To** "I plan to finish my weekly report tomorrow." "I intend to work with the marketing department to ensure they have all relevant information." Showing your work starts with sharing your plans. This is not asking. When you say "I Plan To" or "I Intend To," your manager hears: "Hey, I am going to do this unless you stop me." You are telling your manager you will do this, and now is the time to provide guidance or course correction. It shows that you are ready to own this project. Here is a leadership secret: this is what initiative looks like. ### **Update Update Update** Create a reminder to regularly and proactively share your progress: what is going well, what has been unexpected, where you could use guidance, and the next steps in your plan. If you ensure these updates are consistent and thorough, you will keep your manager fed with enough information to keep them at bay. They will have what they need to be comfortable with the project in your hands. ### **Share When You Are Done** Finally, check in with your manager when you are done. Show them the completed work, tell them what you learned, and share what you are working on next. Remember, "I Plan To." ## **Wrap It Up** You and your manager want the same thing: for you to do great work without constant check-ins. The gap exists because they need information you're not giving them. This causes them to crave more information to the point of needing to micromanage. Stop waiting for them to give you tasks and for them to ask for updates. Start proactively showing your work: I plan to, share your progress along the way, and ask for feedback at the end. Begin replacing the words "May I" with "I Plan To." Then, reflect on how that changes your own perception of your autonomy. **Want more help improving how to show your work?** [Consider reaching out to me](/lets-talk). *You're great at the work. Let's make it visible.*https://jessestaffordcoaching.com/blog/stop-managing-dean-start-showing-workhttps://jessestaffordcoaching.com/blog/stop-managing-dean-start-showing-workUniversities now operate like corporations. Budgets, enrollment, and metrics dominate conversations that used to be about scholarship and teaching.Sat, 11 Oct 2025 00:00:00 GMTUniversities now operate like corporations. Budgets, enrollment, and metrics dominate conversations that used to be about scholarship and teaching. And yet, while chairs are expected to run their departments like business units, most get no leadership training at all. You’re managing budgets, people, and strategy. But nobody ever taught you how. So let’s borrow something that works from the corporate world: > > **Stop managing your dean. Start showing your work.** ## The Problem with “Managing Up” If “managing up” makes you cringe, you’re not alone. It sounds political. Manipulative. Everything you went into academia to avoid. You’re right to resist that language. You don’t *manage* your dean. Your job is to lead your department well and make sure the right people know what’s happening. ### Why Deans Feel Distant Your dean isn’t ignoring you; they’re overwhelmed. Ten departments. Ten priorities. Ten contexts. That’s maybe two hours a week to focus on yours. They’re juggling strategy, budgets, faculty issues, and their own next career step. When you assume they know your work, they don’t. When you don’t communicate, they can’t advocate. > “A dialogue leads to connection, which leads to trust, which leads to engagement.” - Seth Godin Without that dialogue, chairs burn out and departments drift. ### Managing Up Misses the Point Most chairs avoid “managing up” to stay above politics. But the result is silence, no updates, no visibility, no shared context. Your dean doesn’t see the work you’re doing or the challenges you’re facing. And no, “no news” isn’t good news. Many chairs also skip regular one-on-ones or come unprepared. Those meetings devolve into venting, not strategy. And because we’re taught “bring solutions, not problems,” we hide the issues our dean could actually help us solve. Sometimes, what you need isn’t autonomy, it’s a strategic partner. ## Think Like a Partner, Not a Protégé You don’t need flattery or politics. You need clarity and connection. Ask yourself: - What pressures is my dean under? - How can I reduce their mental load? - What information would help them make better decisions? Every dean is scanning for patterns. Help them see yours. > “The more senior you become, the more you’re brought in for your ideas rather than what you can do.” - Joanna Bloor If you want resources and visibility, think and act beyond your current role. ## Show Your Work Instead Good work doesn’t speak for itself. You have to *show* it. Think about how you ask your own students to show their work. It’s not just to verify the answer, it’s to understand their reasoning, how they break problems down, and the principles guiding their choices. Same here. As a department chair, your job is to make your thought process visible. - How you’re approaching challenges - How you’re prioritizing - How you’re aligning with the institution’s goals That’s leadership communication. ### Communication Is the Work Many chairs hold back out of courtesy: > “My dean’s busy. They don’t need all this detail.” But ask yourself: when was the last time you felt over-informed at work? Exactly. > “Whether they read it or not, flood your superiors with information that is documented – projections, evaluations, reports on progress, status updates.” - Bill Walsh You can’t always know what your dean wants to know. Err on the side of transparency. Over-communicate before problems erupt. ## The Three-Step Framework for Chairs Here’s how to show your work without politics: ### 1\. Share Your Plans Don’t ask *“Can I…?”* or *“Should I…?”* Say *“I plan to…”* This signals initiative, not permission-seeking. Example: > “I plan to restructure our undergraduate curriculum to better align with industry needs and improve retention. > I’m meeting with our top three partners this month and will send you a draft proposal in three weeks.” You’ve shown thinking, ownership, and a timeline. Your dean can now guide instead of micromanaging. ### 2\. Share Your Progress Update, update, update. Use BLUF (Bottom Line Up Front) to respect their time. Include: - What’s going well - What’s not - Where you need input - What’s next Example: > “Meetings with our three industry partners are complete. All want to host co-op students starting next fall. > Challenge: We need two new technical courses. Options include an adjunct hire, CS partnership, or online license. > I plan to meet with the CS chair next week and bring you a recommendation by month-end.” Short, clear, actionable. ### 3\. Ask for Feedback When the work’s done, close the loop. Share results. Reflect on lessons. Ask what could be improved. Example: > “The curriculum restructure is approved. I learned that I should engage cross-department partners earlier. > Any feedback on how I managed the process? I plan to apply these lessons to our graduate program next.” That’s visible learning and leadership maturity. ## The Business of Higher Ed Universities *are* businesses, whether we like it or not. Retention, graduation rates, and budgets are now key metrics. Every student who leaves affects reputation and revenue. Your dean is accountable for both. Corporate managers get trained to handle this complexity. Chairs don’t. You can’t fix the system overnight, but you can operate within it like a leader. ## The Shift That Matters Stop managing up. Start showing your work. You don’t need politics. You need partnership. You don’t need permission. You need visibility. Through proactive communication, show your dean that you: - Understand the institution’s challenges - Can break problems into actionable steps - Are ready to lead strategically, not just administratively Do this consistently: 1. Share your plans. 2. Share your progress. 3. Ask for feedback. Good work doesn’t speak for itself; it needs a voice. Make sure yours is heard. Want more help improving how to show your work as a department chair? [Let's talk](/lets-talk). *You're great at the work. Let's make it visible.*https://jessestaffordcoaching.com/blog/should-mix-up-one-on-one-locationshttps://jessestaffordcoaching.com/blog/should-mix-up-one-on-one-locationsEmbrace the flexibility of varying the locations of one-on-one conversations to foster a more open-minded and adaptable leadership approach. Talking to...Mon, 23 Sep 2024 00:00:00 GMTEmbrace the flexibility of varying the locations of one-on-one conversations to foster a more open-minded and adaptable leadership approach. Talking to your team members is the most important way to spend your time as a leader. However, if you always have those conversations at the same time and place, then you are likely only experiencing part of the information. This post is a follow-up to another titled [What does a good 1-on-1 look like?](/blog/good-one-on-one-look-like) Check out this guidance there to learn some tips on structuring the conversation. Where the one-on-one happens has an interesting impact on the types of conversations you will have. In this post, I’ll explore some options of places to host conversations and some of the pros and cons based on my own leadership experience. In general, in-office meetings tend to be more closed and problem-focused, outdoor meetings are often more happy and solution-focused, and virtual meetings depend on where your team member is sitting at the time. Additionally, more public areas will surface less specific and critical feedback. > *As a quick aside, try varying your location for one-on-ones for virtual conversations, even if your team member stays at their usual work location. You can also request that they go for a walk while talking to you.* ## **In your office** This is probably one of the most common places for one-on-one conversations. It is convenient to schedule and offers the opportunity to review materials before, during, and after the conversations. Depending on your relationship with the team member and their experience level, this can be one of the most challenging locations for a one-on-one for them. Getting called into the boss’ office can be a lot like visiting the principal in grade school. In this way, conversations hosted here will tend to be terse, shielded by fear of saying the wrong thing, and generally convey a more negative outlook. > *Look to get out from behind your desk. That surface and monitors between you can reinforce power dynamics, contributing to the tense feelings.* However, don’t avoid this location because there are essential things to learn here. It is more likely that critical feedback of others in the organization will come to light in this location. A view into the less favorable outlook is important for a well-rounded understanding of your team. **Pros:** - Comfortable and convenient place for you. - Access to your notes. - Access to materials to share for discussion. - Round out your view of the team with a less optimistic conversation. **Cons:** - Less comfortable for your team members. - More likely to get a negative, fearful, or muted conversation. - More likely to hear more critical feedback about others. ## **In a Conference Room** Also, a common location for one-on-one meetings and conference rooms will be similar to using an office. With conference rooms being more neutral and public, team members will tend to be a little more open with sharing. This will come from a sense that this room is less important. However, since this is an indoor location, discussions will tend to be more problem-focused. A bigger change is that feedback in this place will often be less specific to other people and more about the process or organization. Choose this location to engage in general and overarching feedback conversations. This is where you are likely to learn about hot spots in your organization or perspectives on what “other” people in the group might be thinking. **Pros:** - Easier to plan location. - More comfortable for your team members. - It is easier to take notes, and you can bring your laptop for materials. - Opportunity to uncover general hot spots or potential problems within your team or organization. **Cons:** - More likely to get negative viewpoints. - Less specific feedback. ## Indoor Open Space Look for areas like seating in the lobby or hallways of your building. While still indoors, these spaces' more public and open nature will start to spin your conversation away from negativity but still likely problem-focused. I would consider this probably the most neutral space on this list. Any discomfort here will be related to not wanting to be loud or share things that will upset people. Be ready to move to a closed room if the conversation needs to turn towards that directed and detailed feedback. In these spaces, you are likely to hear great updates on the progress of tasks/projects and more likely to hear kudos or general positive feedback. Look to dig into how they work with other groups in a neutral way here. Don’t expect to get into much personal or individual information in these spaces. **Pros:** - General positive-looking feedback while more problem-focused. - Generally a more comfortable location. - Less formal, easier to have open conversation. **Cons:** - It is more challenging to take notes or review materials. - Not an optimal place for sharing critical feedback. - More chance for people to overhear what is said. ## Outdoor open space Look for picnic tables or benches. Some office locations have courtyard areas or places where people can rest on a walking path. People tend to be more positive and solution-focused when outdoors. You can have similar conversations as in an indoor open space but with a more solution- or forward-looking slant. **Pros:** - General positive-looking feedback while being more solution-focused. - Informal and easier to have open conversation. **Cons:** - Very weather dependent. - More challenging to take notes or review materials - Not a great place for sharing critical feedback - More chance for people to overhear what is said. ## Walking Indoors or Outdoors We all tend to think and behave differently when moving. These conversations will tend to be positive and forward-looking; outdoors is better for this. You can expect to get information similar to the open spaces above but with a more open conversation. The activity will also help you get more movement into your day. One benefit of walking is that it is easier to understand when you are likely to be overheard and adjust your conversation accordingly. You can use this time to give specific feedback or have a more direct conversation. **Pros:** - Positive and solution-focused conversations. - Get some exercise. - Can still have direct conversations and provide feedback. **Cons:** - Difficult to take notes or review materials. - Less likely to receive critical feedback or uncover problems ## Coffee Shop or Restaurant These locations tend to offer a more dynamic atmosphere, which can be positive or negative, depending on the person you are meeting with. Ultimately, these public places are much less formal, and the conversation will tend to be more relaxed. This isn’t the place to get into a deep discussion about specific work or feedback. However, it is a great place to dig into general company and team culture or learn who they are outside of work. Use this time to learn more about them as a person and less about work. > *My personal favorite is choosing a smoothie or juice shop, for these one-on-ones.* **Pros:** - Positive and solution-focused conversations. - Great opportunity for general company or team environment conversations. - Great for learning more about who they are outside of work. **Cons:** - Difficulty taking notes or reviewing materials. - Can be an overwhelming environment for some team members. - Less likely to receive critical feedback or uncover problems. ## Wrapping It Up Varying the locations of one-on-one conversations can significantly impact the types of conversations you will have as a leader. Different locations, such as your office, conference room, indoor and outdoor open spaces, offer unique advantages and disadvantages. By embracing flexibility in the locations of these conversations, you can gain a well-rounded understanding of your team. Try hosting a 1-on-1 in each of these locations throughout the year. It's important to consider the pros and cons of each location and use them strategically to encourage open and constructive dialogue with team members. Also, check out these posts: [What does a good 1-on-1 look like?](/blog/good-one-on-one-look-like) [A Guide For Skip-Level 1-on-1s](/blog/guide-skip-level-one-on-ones) [One-on-Ones With My Manager are Kind Of Terrible](/blog/one-on-ones-my-manager-kind-terrible) If you are looking for help improving one-on-ones with your team, consider contacting me. [Let's talk about how you can improve this skill.](/lets-talk)https://jessestaffordcoaching.com/blog/managers-stress-yourshttps://jessestaffordcoaching.com/blog/managers-stress-yoursDo you find yourself dreading the start of the workday? Are you feeling tired or just plain overwhelmed with everything you need to get done?Tue, 18 Jun 2024 00:00:00 GMTDo you find yourself dreading the start of the workday? Are you feeling tired or just plain overwhelmed with everything you need to get done? Unfortunately, you are not alone. According to a recent [Work in America Survey](https://www.apa.org/pubs/reports/work-in-america/2023-workplace-health-well-being), 57% of us experience negative impacts of stress. You can reduce stress at work, even with a demanding manager or environment. Let’s examine how you increase stress by not getting clear on priorities, making assumptions, and protecting your reputation. ## No Priorities Is your to-do list a never-ending assortment of everything brought to your attention? Are you often overwhelmed with the sheer volume of work? You may find yourself jumping from task to task, never feeling like you've accomplished anything significant. Not having a defined direction leads to stress and pressure as you struggle to determine what should be done first. Additionally, without clear priorities, you may end up spending too much time on less important tasks, leaving you feeling pressured to catch up on the essential ones. This lack of focus and organization can significantly contribute to your stress. ### A Stress-Free Task List Getting clear on what you need to do and in what order will go a long way in helping you control your stress. Often, we feel overwhelmed by all the things that need to be done when we aren’t clear about their level of importance. Here are some steps to take in getting that task list under control. Start by ruthlessly prioritizing and then choosing things that just aren’t going to get done. #### Ruthlessly Prioritize Decide your focus for the day at the beginning of each week and each day. Be ruthless by only allowing a single task at each priority level. There can only be a single number one priority and a single number two priority. I like to use the [Urgent Important Matrix](https://www.thecoachingtoolscompany.com/coaching-tools-101-what-is-the-urgent-important-matrix/) to do this. **As a summary:** > **Important but Not Urgent**: Most of our time should be focused on this. We should create plans and work towards our longer-term goals, which should also help avoid Urgent tasks. > > **Urgent and Important**: These are crises. These require us to stop and handle the situation, no questions asked. We want to spend very little time here. > > **Urgent but Not Important**: These are interruptions. Remember to allow time for them, but not at the expense of important tasks. > > **Not Urgent and Not Important**: These are distractions. These should be delegated or not done at all. #### Choose Not To Destress your task list by removing things from it. This can mean delegating, delaying, or just not doing something. Using your urgent important matrix and priority list, identify what can be delegated or delayed. Actively look for and remove things from your to-do list. Yes, you can choose not to do tasks. If you delegate something, then walk away from it. Now, that task is someone else's to work on. When choosing something not to do, ask yourself, “When will someone ask for a follow-up on this?” If the answer is never or a long time in the future, then don’t do it. You can always add it to your list if someone requests an update. ## Assuming Do you know your boss will ask you to do that task? Are you waiting until you have finished that task before asking for feedback? What about that vacation your co-worker is taking? You may not realize it, but you are likely increasing your stress by doing things nobody expects of you. One of the most significant stress areas for teams is taking on extra work that the business doesn’t expect or need. These can take many forms, but here are a few scenarios I have witnessed: We believe our manager will ask us to pick up the slack for someone going on vacation or leaving the team, so we add their tasks to our list and start working. If someone asks a question or a favor, we know that it isn’t our job, but we can figure it out quickly and get back to work. Our managers are busy, so we don’t want to interrupt them with something incomplete. ### A Stress-Free Work Life You can reduce stress by showing your work and asking for more feedback. Use the information below to clarify what others need from you. #### Show Your Work This is about proactively collaborating with your manager on your plans and what they expect of you. Commit to intentionally overcommunicating what you are planning and where you are on projects. Also, ask your manager about their plans. Bring questions that allow you some insight into what they expect and share how you plan to meet those expectations. “I noticed that X is going to be on vacation. What is your plan for when they are out?” or “How would you expect us to handle questions from X team?” Check out this post for more details: [Stop Managing Up and Start Showing Your Work](/blog/stop-managing-up-start-showing-work). #### More Feedback Many of us can admit to perfectionism, which can drive a lot of stress. Perfectionism often keeps us from sharing our work before it is complete, leading to us doing more than is needed, taking time away from the next task, or causing rework when something changes. Unfortunately, with a lack of information and updates, people often assume nothing is happening. This perception can cause many managers to amplify the pressure to see progress. Combat this by proactively showing where you are and getting incremental feedback about what you are doing. It shows you are making progress and heads off many potential changes. Check out this post for ideas on asking for feedback: [Hey Boss, Feedback Please](/blog/hey-boss-feedback-please). ## Your Reputation Are you the person who always does what you say and is ahead of schedule? Are you the person your manager comes to for those important projects because they can trust you? I argue that you are influencing unnecessary stress by driving to maintain that Ironman reputation at work. The pressure to uphold the expectations you have set for yourself can create anxiety and doubt. Driving to prove yourself likely causes you to put in extra effort, sacrificing personal time. ### A Stress-Free Reputation Maintaining and improving your reputation and keeping your stress level in check is possible. Ultimately, you will be a better employee if you shed some stress. Here are two concepts to put into practice. First, get realistic about your time. Then, share when you can get something done. #### Budget Your Time Start treating time as currency and creating time budgets for your work, especially around recurring tasks and managing interruptions. Set aside dedicated time to plan what you will do each day of the week. Remove meetings you don’t need to attend, especially those double, and triple-booked slots. Then, allocate time slots to work on your top priorities. For those recurring tasks, set a time limit for how long you spend on them before moving on to something else. Be sure to leave some free time to take breaks and allow time to shift gears. Your goal for each day should be about being productive, not about keeping busy. I recommend committing to one and only one thing per day. Inevitably, someone will swing by and ask for a moment or a favor. You don’t have to drop everything for them right then. If you are in the middle of a task, take a quick look at your schedule and offer them a time when you will be available to give them your complete focus. Most people will appreciate you making any time for them, even if it isn’t immediate. #### Share Your Schedule Good customer service is about knowing what to expect, not being fast. Not everything that someone brings you is urgent. Let that sink in; not everything needs to be done right now. Now that you clearly understand your priorities and schedule, you can easily and quickly tell others when you can fit their request. Provide excellent customer service by telling people when to expect your time. This looks like saying, “I can get that done by next Thursday. Does that work for you?” or “I’m working on X right now; I can tackle that starting on Wednesday.” ## Wrapping It Up You can manage your workplace stress by defining clearly and ruthlessly prioritizing tasks. Try utilizing the Urgent Important Matrix to identify and focus on tasks that truly matter, delegating and choosing not to do less critical ones. Additionally, avoid assuming additional responsibilities or tasks not explicitly assigned to you. Instead, seek feedback and collaborate with your manager to ensure clarity and alignment on expectations. This proactive approach can help reduce stress and create a more balanced work life. If you could use some additional help figuring out how to take control of your stress, or you are looking for a new perspective on your career development, [reach out, and let's chat about how I might help.](/lets-talk)https://jessestaffordcoaching.com/blog/working-micromanager-devouthttps://jessestaffordcoaching.com/blog/working-micromanager-devoutWorking with a micromanager is often frustrating, stressful, and demotivating. Especially when that manager believes they are the only person in the...Tue, 04 Jun 2024 00:00:00 GMTWorking with a micromanager is often frustrating, stressful, and demotivating. Especially when that manager believes they are the only person in the organization capable of doing the job correctly. While this can be infuriating and demoralizing, there are things you can do about it. Use this information to understand what drives your Doer manager and how to adapt your communication style. Ultimately, Devouts micromanage because they desire control over the situation and outcome. If you haven’t yet, check out this overview of micromanager types: [It’s your fault you are being micromanaged](/blog/fault-being-micromanaged). ## The Devout Micromanager Most people fear the Devout micromanagement style. They enjoy micromanaging or believe that they must rule with an iron fist. I find them to be rare. They often show up in retail or food service, where speed of service is believed to be necessary. Many Devouts will be incredibly busy at work, with too much work on their plate to spend any time talking to you. While you often cannot do much about these micromanagers, there are ways you can adapt your communication and work styles to improve the relationship. However, it may be prudent to start looking for another job. There are several key drivers for devout micromanagers in leadership roles. These come down to control, reputation, and trust. ### Control These managers believe in the strictest idea of “The buck stops here.” Since they want to be certain of how the work gets done, Devouts often do work for their team instead of delegating, genuinely believing that they are the only ones who can do the task correctly and that training someone else will take too much time. Additionally, if they did allow you to do something, it is almost a given that they will redo the work after you are done. Or they will hover and follow you, correcting every misstep immediately. That micromanagement, you feel, is them pushing to be specific about how work gets done. ### Reputation Devouts are proud of their track record and want to ensure nothing tarnishes it. To this end, they will want to double-check every detail. They will also be agitated or angry when even the most minor mistakes are made. They may expect you to apologize and explain what you did to make the mistake. That micromanagement, you feel, is them protecting the reputation of the team and themselves. ### Trust One of the biggest drivers of relationships and minimizing micromanagement is trust. With Devouts, trust is a hard-won achievement. Many of these managers will expect the people around them to prove themselves trustworthy with every task. You may hear them say, “It’s hard to find good help these days,” and “They have not earned my trust.” What does this mean? To a Devout, it likely means you are not showing that you will make the decisions or take the actions they would take to meet their quality expectations. Trust is established after enough events to make your manager believe you will follow procedure and not make mistakes. That micromanagement, you feel, is their effort to show what will earn their trust. ## Showing Your Work with a Devout At this point, it seems like these are insecurities that your manager needs to move past, which is undoubtedly true but out of your control. You can, however, control how you communicate with your manager. By leaning on their expertise, let’s explore specifics around this communication that reflects your Devout’s ideals. Clarify their expectations, share your plans, and share your progress. ### Clarify the Expectations Start by clarifying the details of your project, focusing on the process or procedures already in place. Work to read any existing documents or outlines first. Then, schedule some time or a message with questions. Ask about anything they want changed compared to the current procedures and how they expect you to proceed. In this communication, lean on their expertise and desire for control. Be clear that you are here to make sure things work out how they expect. As you clarify the goal, remember that your manager has a very clear expectation for how you should proceed. Their answers will most likely be steps or directions for you to follow. However, their answers will be short and will directly reference the procedures. Be sure to ask clarifying questions about specific steps that are unclear. Getting clear answers about why those steps are essential will be difficult, so do your best to push those questions until later. Clarifying the goals this way will help reinforce to your manager that they are in control and build trust by clarifying that doing the right job is important to you. ### Share Your Plans Now that you have clarified the goals and corrected procedures take some time to share the steps you will take. Keep in mind that your manager will prefer succinct communication. Focus on the procedures you will follow at a high level, calling out any exceptions. Also, be clear about how long you expect it to take to complete the project. Be ready to receive some pushback, as your manager will likely think your estimate is too long. Your manager believes they can do it faster. Here is what is important: Stay at a high level where the documented procedures are correct, but get into specifics where changes are needed. Your Devout manager will appreciate your commitment to their time and attention to doing the right thing. Your Devout manager values correctness and timeliness above all else. Be careful not to spend too much time making or sharing this plan since the process is already clear to them. Offer to update the documentation for all corrections they have identified. Sharing your plans in this way will build trust by showing your readiness to follow their expectations. It will also give them a sense of control and respect for the reputation that they are seeking. ### Share Your Progress Finally, create a reminder to check in with your manager regularly, but also be ready to give an update anytime they stop by. Depending on the project, this could be daily, weekly, or biweekly. Devouts will value knowing the progress being made. I don’t recommend going longer than two weeks without a detailed progress update. Your manager has probably already given you insight into how often this should be. When do they usually ask you for updates? How frequently do they ask, “How is your project going?” In your update, share: > The tasks you have completed. > > The challenges you have overcome. With questions about what they would have done differently. > > Any challenges you have not overcome, with questions about how your manager would proceed. > > The work you have remaining in your plan. > > The tasks you will work on next, with details about how you will work through them. Reminder: stay direct and brief unless you need details about their expectations. Devouts want to keep moving and not waste time talking about a procedure that is already documented. Sharing your progress this way will consistently give your manager the update they want and the sense of control they want. This will also build trust by showing that you are delivering progress and are prepared to give updates when they ask. Lastly, it will respect their reputation by keeping your quality high. ## Wrapping It Up Working with a Devout micromanager can be challenging, but there are strategies to adapt your communication and work styles. Understanding their need for control, protection of reputation, and trust can help you navigate the relationship. By clarifying their expectations, sharing your plans succinctly, and demonstrating progress, you can reinforce their sense of control and build trust, potentially improving the working relationship. However, it's also important to consider whether finding another job may be necessary if the micromanagement becomes too overwhelming. For more information about communicating with your manager, check out these posts: [Stop Managing Up and Start Showing Your Work ](/blog/stop-managing-up-start-showing-work)[Working With Your Micromanager - The Doer](/blog/working-micromanager-doer)[Working With Your Micromanager - The Taskmaster](/blog/working-micromanager-taskmaster)[Working With Your Micromanager - The Amplifier](/blog/working-micromanager-amplifier) Also, check out this post about strengthening relationships at work: [Professional Relationships Drive Career Growth](/blog/professional-relationships-drive-career-growth) If you are looking for more help in navigating your micromanager, [consider reaching out to me](/lets-talk).https://jessestaffordcoaching.com/blog/working-micromanager-amplifierhttps://jessestaffordcoaching.com/blog/working-micromanager-amplifierWorking with a micromanager can be frustrating and demotivating, especially when they seem frantic or ask for things they don’t understand. However,...Fri, 24 May 2024 00:00:00 GMTWorking with a micromanager can be frustrating and demotivating, especially when they seem frantic or ask for things they don’t understand. However, there are things you can do to change the story. Use this information to understand what makes your Amplifier micromanage and how to adapt your communication style. Ultimately, Amplifiers want to be able to confidently relay status and progress up the chain, probably to someone who is micromanaging them. If you haven’t yet, check out this overview of micromanager types: [It’s your fault you are being micromanaged](/blog/fault-being-micromanaged). ## The Amplifier Amplifiers are often influenced by the dynamics within the organization, particularly in larger, multi-layered structures. They strive to avoid surprises in meetings and may hover until they obtain the information they seek, inadvertently amplifying the pressure they feel onto you. Understanding this dynamic can empower you to manage your relationship with them proactively. Amplifiers are driven by several key ideas: a drive to improve their own career standing, fear for their status or job, and pressure from their micromanager. ### Their Career We are often so focused on getting what we need that it is easy to forget that our managers and leaders are looking for opportunities to advance their careers. Sometimes, in this pursuit, a manager may put too much pressure on themselves to achieve an objective. In these situations, these managers will push their own aspirations onto you. Since many managers lack formal leadership training, they lack the skill set required to translate their aspirations into mentorship and coaching. Instead, they rely on working harder and expecting you to do the same with them. That micromanagement, you feel, is their attempt to show career growth. ### Fear This may seem counterintuitive, but the job becomes less clear as you advance in seniority. It becomes increasingly difficult to know what is expected and what the right decisions are. This can be scary and stressful for many managers, especially since the pressure to be a decision-maker can come from below and above. Also, the stakes get higher and higher. The more parts of a business you are responsible for, the larger the impact and price tag of every decision. These fears will cause managers to make safe or shielding decisions, attempting to protect themselves and their teams. The reasoning is that they need to protect the reputation of people on their teams and their own status. Additionally, there may be a worry about getting fired for making mistakes. That micromanagement, you feel, is their attempt to protect both you and them. ### Pressure A common trigger for the Amplifier is pressure from their leadership chain to accomplish a goal. In these situations, a manager likely isn’t clear on precisely what needs to be done or doesn’t know how to motivate their team towards the goal. It is also likely that the managers are micromanaging themselves. Often, their micromanager will be a Taskmaster. That micromanagement, you feel, is them being micromanaged too. ## Showing Your Work with an Amplifier Now, it seems like more training or stress management for your manager could solve much of this, which is undoubtedly true but out of your control. You can, however, control how you communicate with your manager. By leaning into their needs and fears, let’s explore communication specifics that match your Amplifier’s needs. Share your plans, share your progress, and check in when finished. ### Share Your Plans Before starting the project, take some time to clarify the steps you will take. This is probably the most challenging part. You will likely want to start working and figure many things out as you encounter them; resist this. Document the steps and how long you think it will take to accomplish them. Here is what is important: stay above the weeds, and do not get too detailed about how you will do the work. However, do stay detailed enough that they can see your thought process in breaking down the problem into manageable chunks. Your Amplifier likely doesn’t, or wants to, understand the day-to-day details of how you do your work, but they will want to know the outcomes or milestones they can use to communicate progress. Share your plans using the phrase “I plan to” and avoid “Is it okay if.” Be sure to ask for feedback about whether this direction makes sense. Allow them time to communicate the plans with their leaders, and offer to be available for questions. Sharing your plans in this way will help alleviate their fears by showing them that you have it handled. It will also give them a way to communicate what to expect, allowing them to work with their micromanager. This should enable them to show confidence, helping them with their career goals. ### Share Your Progress Next, create a reminder to check in with your manager regularly. Depending on the project, this could be daily, weekly, or biweekly. Amplifiers need to be able to share the progress being made. I don’t recommend going longer than two weeks without a detailed progress update. Your manager has probably already given you insight into how often this should be. When do they usually ask you for updates? How frequently do they ask, “How is your project going?” **In your update, share:** > The tasks you have completed. > > The challenges you have overcome, with the information about delays. > > Any challenges you have not overcome, with questions about how your manager would proceed. > > The work you have remaining in your plan. > > The tasks you will work on next, with information about how long it will take. Reminder: be detailed about milestones and outcomes at all levels of this plan. Share any impacts from challenges or new information. Make sure they don’t get surprised by learning something from someone else. Sharing your progress this way will consistently give your manager the information they need to share. This will allow them to feel confident and prepared for their leadership. That confidence helps reduce fear and pressure they feel. ### Check-in When Finished Finally, as you wrap up the project, create a summary for your manager. Share with them any lessons you learned and any areas in which you could use their support. Be sure to ask for feedback, asking them what they are hearing about the project. Be sure to share your plans for what is next. Remember, “I plan to”. Checking in at the end will clarify that you have completed the work you know about satisfying their need for confidence and fear of the outcome. Asking for feedback and clarifying that you need their support in understanding what is being asked helps them know that you are supporting their goals and that they can trust you. ## Wrapping It up Working with an Amplifier can be demotivating, but it doesn't have to be. By understanding their concerns and adapting your communication style, you can turn this challenge into an opportunity to build trust and achieve common goals. Don't let micromanagement get you down, use these strategies to take control of the situation and work effectively with your micromanager. If you are working with an Amplifier micromanager, support their career goals and reduce features by proactively sharing your plans and communicating progress. Help them communicate up by asking what information they need and are being asked for, and tailor your communication to those asks. For more information about communicating with your manager, check out these posts: [Stop Managing Up and Start Showing Your Work ](/blog/stop-managing-up-start-showing-work)[Working With Your Micromanager - The Doer](/blog/working-micromanager-doer)[Working With Your Micromanager - The Taskmaster](/blog/working-micromanager-taskmaster) Also, check out this post about strengthening relationships at work: [Professional Relationships Drive Career Growth](/blog/professional-relationships-drive-career-growth) If you are looking for more help in navigating your micromanager, [consider reaching out to me](/lets-talk).https://jessestaffordcoaching.com/blog/working-micromanager-taskmasterhttps://jessestaffordcoaching.com/blog/working-micromanager-taskmasterWorking with a micromanager can be a stressful experience. Especially when the manager constantly asks for updates and pushes you to meet that next date.Wed, 08 May 2024 00:00:00 GMTWorking with a micromanager can be a stressful experience. Especially when the manager constantly asks for updates and pushes you to meet that next date. While this can be distracting, aggravating, and demotivating, there are things you can do to make it bearable. Use this information to understand what drives your Taskmaster and how to adapt your communication style. Ultimately, Taskmasters micromanage because they are uncomfortable with uncertain timelines and outcomes. If you haven’t yet, check out this overview of micromanager types: [It's Your Fault You're Being Micromanaged](/blog/fault-being-micromanaged). ## The Taskmaster Taskmasters are one of the more common micromanager traits. These managers need to know the plan and how much progress has been made. If they don’t see every step the team takes, the project's outcome is not certain enough to satisfy them. Taskmasters hold many meetings and impromptu check-ins to get updates on short-term progress. Taskmasters are battling some key concerns and fears around feeling a need to contribute, lack of control, and status information. ### Need to Contribute Many managers eventually find themselves in a position where they are not qualified to contribute to their team's accomplishments, which leaves them feeling less than useful. Taskmasters will lean on their organization and planning skills to create an impact. Since many managers do not have formal leadership training, they don’t have a skill set to translate their skills into mentoring or coaching. Instead, they rely on trying to do this planning and reporting for you but don’t have enough details to work independently. That micromanagement, you feel, is their attempt to get some of the work off your plate. ### Lack of Control Before their leadership role, your Taskmaster was probably used to working solo or within a small team where they had strong authority. In these situations, they were used to taking on and owning a project independently. Success usually comes when they do what it takes to accomplish the goal. Now that they cannot do the work on their own, these managers do not know how to add certainty to the outcome. Leading through goals and motivation is a skill that takes time to hone and perfect. These managers do not have the ability to communicate the goals clearly. Instead, they push you to overplan and drag information out of you. That micromanagement, you feel, is a manager striving to push you toward a successful outcome. ### Information about Status Taskmasters pride themselves on accurately describing the current status and timelines. In manager roles, knowing the progress of every project and task often requires more time than is available. Since many managers have minimal training, Taskmasters don’t know how to ask for what they need to feel confident explaining risks and projections for a project. That micromanagement, you feel, is their attempt to make sure they know the current status of your project. ## Showing Your Work with a Taskmaster Now, it seems like more training for your manager could solve much of this, which is undoubtedly true but out of your control. You can, however, control how you communicate with your manager. By leaning on their strengths and needs, let’s explore specifics around this communication that matches your Taskmaster’s goals. Share your plans, share your progress, and check in when finished. ### Share Your Plans Before starting the project, take some time to clarify the steps you will take. This is probably the most challenging part. You will likely want to start working and figure many things out as you encounter them; resist this. Document the steps and how long you think it will take to accomplish them. Here is what is important: stay above the weeds, and do not get too detailed about how you will do the work. However, do stay detailed enough that they can see your thought process in breaking down the problem into manageable chunks. Your Taskmaster won’t understand the day-to-day details of how you do your work, but they will want to know the outcomes or milestones they can use to measure progress. Be careful not to underestimate how long each step will take; it is probably better to estimate a little long and deliver a little early. Share your plans using the phrase “I plan to” and avoid “Is it okay if.” Be sure to ask for feedback about where they would do something different. Make sure you accept and integrate that feedback. Sharing your plans in this way will satisfy their need for control by showing them that you have it handled. It will also give them a script about what to expect, fulfilling their desire for status information. It may also help with their need for control, assuming you integrate their feedback. ### Share Your Progress Next, create a reminder to check in with your manager regularly. Depending on the project, this could be daily, weekly, or biweekly. Taskmasters desire to know the progress being made. I don’t recommend going longer than two weeks without a detailed progress update. Your manager has probably already given you insight into how often this should be. When do they usually ask you for updates? How frequently do they ask, “How is your project going?” In your update, share: > **The tasks you have completed.** > > **The challenges you have overcome, with the information about delays.** > > **Any challenges you have not overcome, with questions about how your manager would proceed.** > > **The work you have remaining in your plan.** > > **The tasks you will work on next, with information about how long it will take.** Reminder: be detailed about milestones and outcomes at all levels of this plan. Taskmasters want this level of information to know how the project is progressing and when they can expect to see progress. Share any impacts from challenges or new information. Make sure they don’t get surprised by learning something from someone else. Sharing your progress this way will consistently give your manager the information they want before they feel the need to ask for it. This will allow them to feel in control because you proactively show them what is happening. In the same way, it will help them have the information they need by allowing them to have status information to share with others. ### Check-in When Finished Finally, as you wrap up the project, create a summary for your manager. Share with them any lessons you learned and any areas in which you could use their support. Be sure to ask for feedback, asking them what they would have liked to see you do differently. Be sure to share your plans for what is next. Remember, “I plan to”. Checking in at the end will make it clear that you have completed the work you know about satisfying their need for control and status information. Asking for feedback and clarifying that you need their support in specific ways will help them feel like they are contributing. ## Wrapping It up Working with a Taskmaster can be frustrating and stressful, but it doesn't have to be. By understanding their concerns and adapting your communication style, you can turn this challenge into an opportunity to build trust and achieve common goals. Don't let micromanagement get you down, use these strategies to take control of the situation and work effectively with your micromanager. If you are working with a Taskmaster micromanager, give them opportunities to contribute by asking for feedback and provide them with a sense of control and knowledge by sharing the detailed plans they are after. Do this by sharing your plans, sharing progress, and checking in at the end to demonstrate your commitment to the project's success. For more information about communicating with your manager, check out these posts: [Stop Managing Up and Start Showing Your Work ](/blog/stop-managing-up-start-showing-work)[Working With Your Micromanager - The Doer](/blog/working-micromanager-doer)[Working With Your Micromanager - The Amplifier](/blog/working-micromanager-amplifier) Also, check out this post about strengthening relationships at work: [Professional Relationships Drive Career Growth](/blog/professional-relationships-drive-career-growth) If you are looking for more help in navigating your micromanager, [consider reaching out to me](/lets-talk).https://jessestaffordcoaching.com/blog/working-micromanager-doerhttps://jessestaffordcoaching.com/blog/working-micromanager-doerWorking with a micromanager can be an unfortunate experience. Especially when that manager used to do the same job as you, they can get quite...Sun, 05 May 2024 00:00:00 GMTWorking with a micromanager can be an unfortunate experience. Especially when that manager used to do the same job as you, they can get quite controlling or directive about how to get the work done. While this can be frustrating and demotivating, there are things you can do about it. Use this information to understand what drives your Doer manager and how to adapt your communication style. Ultimately, Doers micromanage because they are uncomfortable with not knowing the daily details about how the work is getting done. If you haven’t yet, check out this overview of micromanager types: [It's Your Fault You're Being Micromanaged](/blog/fault-being-micromanaged). ## The Doer Micromanager One of the most common micromanagement styles is the Doer. These are the managers who were once good at their team's job. More often than not, these people were promoted into management for their talent at getting the job done and struggle with letting go. These micromanagers will usually give you detailed steps and checklists. They know what is happening because they tell you exactly what to do. There are several key concerns or fears that Doers are balancing when in leadership roles. These boil down to reputation, trust, and information. ### Reputation These managers are proud of their accomplishments and want to see that trend continue in their new role. In many cases, this reputation was hard won, and they probably believe they achieved most of these accomplishments through their skills and motivation. Since most managers receive little training on motivating others, setting goals, and communicating expectations, they don’t know how to empower you to build your reputation and excel as a team. This means the only tools these managers have for success are the skills and experiences they gained before management. Those skills and experiences are about getting their hands dirty in the weeds of the work. That micromanagement, you feel, is their best attempt at showing you the way to success. ### Trust One of the biggest drivers of relationships and minimizing micromanagement is trust. With Doers, trust is a hard-won achievement. Many of them will expect the people around them to prove themselves trustworthy. You may hear them say something like, “They have not earned my trust yet.” What does this mean? To a Doer, it likely means they have not seen enough of your day-to-day decisions or actions to know you will uphold their reputation. Trust is established after enough events to make your next steps known to your manager. That micromanagement, you feel, is their effort to show what next steps will make you trustworthy. ### Information Doers pride themselves on knowing exactly how everything under their authority works. In manager roles, knowing how every project and task is working often requires more time than is available. Since many managers have minimal training, Doers don’t know how to ask for what they need to feel confident explaining what is happening with projects. That micromanagement, you feel, is their attempt to make sure they know how your project works. ## Showing Your Work with a Doer Now, it seems like more training for your manager could solve much of this, which is undoubtedly true but out of your control. You can, however, control how you communicate with your manager. By leaning on their expertise, let’s explore specifics around this communication that plays to your Doers' strengths. Clarify their goals, share your plans, and share your progress. ### Clarify the Goal Start by clarifying the details of your project, focusing on the outcome. Prepare a meeting request or email message with questions. Ask for specifics about how the project is expected to work, what it should look like, what expectations they have about the project, and what expectations their manager has. Most importantly, lean on their expertise by asking how they would do the work. Dig into the details, and let them flex their problem-solving skills with you. As you clarify the goal, remember that your manager is better at problem-solving than goal-setting. Their answers may likely be steps or directions for you. Be sure to ask clarifying questions about what makes those steps important. Focus on questions that start with “What” and “How,” as these questions foster deeper collaboration and show trust in their answers. Avoid questions that start with “Why,” as these will likely come off as challenging or disrespectful. Here are some ideas starters: > **How does that help achieve the right goal?** > **What problem are we avoiding by doing that way?** > **What concerns do you have about trying to \_\_\_\_\_\_?** Clarifying the goals in this way will help reinforce to your manager that you respect their reputation and build trust by making it clear that doing the right job is important to you. ### Share Your Plans After you have taken the time to get clear on goals and before you start doing work. Take some time to clarify the steps you will take. This is probably the most challenging part; you will likely want to start doing work and figure many things out as you encounter them; resist this. You have a great starting point already. Your manager likely already shared a plan and many of the steps with you. Document those in your own words and flesh out details where you see opportunities based on the goals you learned in the previous step. Here is what is important: get into the weeds by being specific and detailed. There is no need to stay high-level or vague for a Doer; they want to discuss the details and will be happy to find someone who will. Also, share these using the phrase “I plan to” and avoid “Is it okay if.” Be sure to ask for feedback about where they would do something different. Make sure you accept and integrate that feedback. Also, your Doer manager likely values progress over many other things, and spending time on a plan after they told you what to do could be a difficult sell. Please do not spend too much time making your plan. It will stall your trust building. Sharing your plans in this way will build trust by showing how you think about the problem. It will also give them the information they want about how the project will work. Finally, asking for feedback respects their reputation. ### Share Your Progress Finally, create a reminder to check in with your manager regularly. Depending on the project, this could be daily, weekly, or biweekly. Doers will value knowing the progress being made. I don’t recommend going longer than two weeks without a detailed progress update. Your manager has probably already given you insight into how often this should be. When do they usually ask you for updates? How often do they ask, “How is your project going?” In your update, share: > **The tasks you have completed.** > > **The challenges you have overcome, with the details about how.** > > **Any challenges you have not overcome, with questions about how your manager would proceed.** > > **The work you have remaining in your plan.** > > **The tasks you will work on next, with details about how you will work through them.** Reminder: get into specifics and details about the tasks at all levels of this plan. Doers want that level of information so they know what is happening and how. Share how you handled the solutions you are proud of and where you would have done differently if presented with a problem again. Sharing your progress this way will consistently give your manager the information they want before they feel the need to ask for it. This will also build trust by showing that they don’t need to check in on you and that you are still delivering progress. Lastly, this respects their reputation by asking for guidance on problems you foresee. ## Wrapping It Up Working with a micromanager can be frustrating, but it doesn't have to be. By understanding their concerns and adapting your communication style, you can turn this challenge into an opportunity to build trust and achieve common goals. Don't let micromanagement get you down, use these strategies to take control of the situation and work effectively with your micromanager. If you are working with a Doer micromanager, acknowledge their reputation, take steps to build trust, and share the detailed information they are after. Do this by clarifying their goals, sharing your plans, and showing progress, demonstrating your commitment to the success of the project. For more information about communicating with your manager, check out these posts: [Stop Managing Up and Start Showing Your Work ](/blog/stop-managing-up-start-showing-work)[Working With Your Micromanager - The Taskmaster](/blog/working-micromanager-taskmaster)[Working With Your Micromanager - The Amplifier](/blog/working-micromanager-amplifier) Also, check out this post about strengthening relationships at work: [Professional Relationships Drive Career Growth](/blog/professional-relationships-drive-career-growth) If you are looking for more help in navigating your micromanager, [consider reaching out to me](/lets-talk).https://jessestaffordcoaching.com/blog/fault-being-micromanagedhttps://jessestaffordcoaching.com/blog/fault-being-micromanagedAre you frustrated with managers' over-involvement in your projects? Do they check in on your status too often?Sun, 21 Apr 2024 00:00:00 GMTAre you frustrated with managers' over-involvement in your projects? Do they check in on your status too often? Does your manager think they know more about the work than you do? What about those times when they redo your work for no reason? All of this is your fault; follow along to learn how to get your manager off your back. You have to wonder with how busy our managers must be, how do they find so much time to control everything? ## The Micromanagers To answer this question, we need to explore why different managers end up micromanaging. Over time, I have observed various kinds of micromanagement, each with distinct ways and reasons for managers to get over-involved. These are not one-size-fits-all situations; at some point, every manager will probably exhibit each of these personas. ### The Doers  One of the most common micromanagement styles is the doer. These are the managers who were once good at their team's job. More often than not, these people were promoted into management for their talent at getting the job done and struggle with letting go. These micromanagers will usually give you detailed steps and checklists. They know what is happening because they tell you exactly what to do. These managers micromanage because they are uncomfortable with not knowing the daily details about how the work is getting done. ### The Taskmasters  The next most common micromanager is the taskmaster. These managers need to know the plan and how much progress has been made. If they don’t see every step the team takes, the project's outcome is not certain enough to satisfy them. Taskmasters hold many meetings and impromptu check-ins to get updates on short-term progress. These managers are uncomfortable with uncertain outcomes. ### The Amplifiers These managers are being pressured by other people in the organization. They are more likely to show up in larger organizations with many layers. They want to avoid being surprised by new information coming up in meetings, tending to hover until they get the information they seek, amplifying the pressure they are feeling on you. Amplifiers want to be able to confidently relay status and progress up the chain, probably to a taskmaster. ### The Devout Devout micromanagers are special. They enjoy micromanaging or believe that they must rule with an iron fist. I find them to be rare. They often show up in retail or food service, where speed of service is believed to be necessary. You cannot do much about these micromanagers; I suggest promoting them to ex-boss by finding a new job. Or get good at playing to their egos. Since you are this far in, it might be worth finishing. These ideas may help you with your next manager. ## A Common Thread I know that at this point, these still seem like problems they need to solve for themselves. However, in almost every case above, these managers feel like they don’t know what is going on and don’t know how to ask for what is missing. Or because nobody seems to be stepping up to ensure things are organized. The common thread, causing you to be micromanaged, is that these managers are looking for more information and team members who show they don’t need to be told what to do. You can do this for them! ## It’s Time to Break Habits You must break some habits before you start getting your manager to back off. 1. Only sharing when the work is complete, or you need a new task. 2. Asking permission. 3. Being worried about their time. ### 1\. Lift Your Head and Share Stop putting your head down and only coming up for air when the work is complete. Many of us find it easy to get focused and work through the problems and tasks in front of us right to the end. This is one of the things that causes your manager to get uncomfortable and causes micromanagement. It is easy to believe that since our managers assigned us a task, then they know what we are doing, but no news is not good news to a micromanager. ### 2\. Don’t Ask Permission to do Your Job “Sorry to bother you, but can I work on my weekly report tomorrow?” When you ask permission, you tell your manager that you cannot progress without their approval. You are telling them you are stuck, and they must stop what they are doing to get you moving. The micromanager hears you say, “You have to own the next steps and tell me what to do; I am not accountable.” Many of us were taught from a young age to respect our elders and those in authority positions. However, there are ways to honor these values without encouraging the micromanagers around us. ### 3\. Your Manager is Not Too Busy It is your manager's responsibility to manage their own time. Frankly, if they have the time to micromanage you, they have time to receive your information. You do not need to worry about how busy they are; if your manager wants more information, GIVE IT TO THEM! Overcommunication is not possible in a professional environment. Think about how often you feel like too much about a project is being shared with you. Share everything that can be shared. ## Build A New Habit It's time to build a new habit around proactive communication. I like to call it showing your work. Just like back in school when your math teacher wanted to show all the steps, showing your work lets your manager know how you plan to solve the problem (Doers), how much time you think it will take (Taskmasters), and when you will follow up on the status (Amplifiers). The difference between now and school is when you show your steps. In the professional world, you must explain the steps before doing the work, not wait until you get the correct answer. ### I Plan To “I plan to finish my weekly report tomorrow. “I intend to work with the marketing department to ensure they have all relevant information.” Showing your work starts with sharing your plans. This is not asking. When you say “I Plan To” or “I Intend To,” your manager hears: “Hey, I am going to do this unless you stop me.” You are telling your manager you will do this, and now is the time to provide guidance or course correction. It shows that you are ready to own this project. Here is a leadership secret: this is what initiative looks like. ### Update Update Update Create a reminder to regularly and proactively share your progress: what is going well, what has been unexpected, where you could use guidance, and the next steps in your plan. If you ensure these updates are consistent and thorough, you will keep your manager fed with enough information to keep them at bay. They will have what they need to be comfortable with the project in your hands. ### Share When You Are Done Finally, check in with your manager when you are done. Show them the completed work, tell them what you learned, and share what you are working on next. Remember, “I Plan To.” ## Wrap It Up Micromanagement is your fault because you don’t share enough with your manager. This causes them to crave more information to the point of needing to micromanage. Stop waiting for them to give you tasks and for them to ask for updates. Start proactively showing your work. I plan to, share your progress along the way, and ask for feedback at the end. Begin replacing the words “May I” with “I Plan To.” Then, reflect on how that changes your own perception of your autonomy. **Check out these related posts:** [Stop Managing Up and Start Showing Your Work](/blog/stop-managing-up-start-showing-work) [Hey Boss, Feedback Please!](/blog/hey-boss-feedback-please) [Hey Boss, Stop Solving the Team's Problems](/blog/hey-boss-stop-solving-teams-problems) If you want more help improving how to show your work, [consider reaching out to me](/lets-talk).https://jessestaffordcoaching.com/blog/stop-managing-up-start-showing-workhttps://jessestaffordcoaching.com/blog/stop-managing-up-start-showing-workBuilding a strong, collaborative, and trusting relationship with your management is critical to career development and a healthy work life. However, we...Sun, 14 Apr 2024 00:00:00 GMT## Do you find yourself struggling to manage up? Are you frustrated with the idea of managing your manager? Building a strong, collaborative, and trusting relationship with your management is critical to career development and a healthy work life. However, we should not do this by managing up. Do it by showing your work. Let’s talk about what we get wrong when we try to manage up and how showing your work will lead to better results. ### Don’t Manage Your Manager It’s time to change our language around this critical career skill. Nobody expects you to manage your boss; ultimately, it doesn't make sense. It is not your job to manage your boss. Your job is about doing great work and ensuring people know what is happening. Let's review how managing up creates the wrong relationship dynamic and where we miss the point. #### The Relationship Dynamic We often don’t think about how much information our managers are working to keep track of daily. Many people mistakenly believe their managers should know what they are doing and working on. The reality is that your manager is keeping track of the work of everyone on their team, plus the tasks their manager has assigned them. Like you, they are also trying to navigate their careers and relationships with peers and managers. If, for example, your manager has 10 direct reports, then we are talking about a minimum of 10 projects and 10 careers for direct reports alone. Add to that their 1-5 projects and their career. We are discussing at least 25ish topics your manager juggles at any given time. That is less than 2 hours a week per topic. This expands quickly as they move up the ladder to lead other managers. > > **“A dialogue leads to connection, which leads to trust which leads to engagement.", Seth Godin** In a managing up world, relationships between managers and reports often lack the communication necessary to create a high-functioning environment. We assume that our managers know things we haven’t shared, so they don’t have enough information to ensure the decisions they are involved with make sense. This leads to products making slow or backward progress, and ultimately, team members disengage. #### We Are Missing the Point Many people mistakenly believe that managing up is about sucking up or brown-nosing. As we choose not to stoop to manipulation or flattery to get ahead, we also choose to stop short of sharing everything our managers need to support us fully. Since managers track a large amount of information, they often do not pay attention to what is not said. No news is good news, but is it? Additionally, most people don’t have adequate one-on-one conversations with their managers. Many times, these conversations do not happen frequently enough, causing important topics to fade away or get superseded by the fire of the moment. Or we don’t take time to plan what to share during a one-on-one, causing these conversations to devolve into scattershot updates, venting about issues, and other topics that happen to be front of mind that day. The adage “Bring Solutions, not problems” that many people bring to the management table prevents some conversations from happening. Often, in this environment, people who are genuinely stuck and don’t know how to reason about a solution to their problem will silently suffer through it. There are problems that your manager is uniquely qualified for or has the connections required to get traction. It is true that your manager doesn’t want to hear people complain about every problem and shouldn’t be providing detailed steps for every situation, but sometimes we need a little kickstart. ### What you Should be Thinking About We should start by understanding and building collaborative relationships with our leaders. This isn’t about flattery or manipulation; it is about sincerity, honesty, and making the right decisions. Being a key part of your manager’s success can significantly impact your career growth opportunities. You can support your manager’s success by considering situations from their perspective. How can you help bring information and take on tasks to reduce their burden? Remember that our managers have a lot of information to keep track of and are focused on allocating attention and energy to the right places. Time is your manager's most precious resource; you should think about ways to help them make the most of it. Given that more initiatives and people-related topics are going on than your manager can reasonably give productive attention to, they are focused on looking for trends, patterns, and commonalities across the team and business. You should consider sharing enough information to make this task easier. What does your manager need to know? What would you want to know if you were in their position? You could even look to take things off their plate. > **"I believe that the more senior you become, the more you are brought in for your ideas rather than what you can do. Articulating how you think is probably more important than what you do."** **, ** **[Joanna Bloor](https://joannabloor.medium.com/are-you-showing-your-work-96f4efc133fe)** Assuming you also want to advance your career and believe you have more to offer your manager and the business. Ultimately, this means operating beyond your current assigned tasks and level. Decisions that affect your career are often made when you are not in the room. You should think about how you can prove your value and how ready you are for the next level to your manager. You should be thinking about showing your work! ### Show Your Work Instead We are often expected to solve problems and complete work in our professional lives. Our managers seldom ask us to show our work, and many will not recognize that this is part of the job. However, as your career advances, you undoubtedly participate in more longer-term strategy discussions. These topics are more about sharing your thoughts and less about achieving a specific task. #### Math Homework Remember your school days? Your teachers likely often asked you to show your work. It was always important to share your steps for homework, especially math or science. Why did they do this? It wasn’t about getting the correct answer. They wanted you to show that you understand the thought process, how to break problems into smaller parts, and the fundamental problem being solved. This same concept applies to work. Aim to demonstrate that you understand how the business operates and the problems that must be solved. You should show that you can help simplify the problem into parts that can be solved by the people and resources available. ### Overcommunication A quick word about communication: many people worry about their manager's time and are reluctant to share things their manager may not need to know. You probably think, “They are busy, and I don’t want to waste their time with this.” There is no such thing as overcommunication. Stop and think about this for a bit. How often do you receive too much communication at work? Compare that to how frequently you hoped to receive more communication about something. > **"Whether they read it or not, flood your \[boss\] with information that is documented, projections, evaluations, reports on progress, and status updates."**, Bill Walsh - The Score Takes Care of Itself You can’t always know what your manager wants to know or should know. Strive to ensure they are not surprised by something you could have given them a heads-up about. If you share too much information and your manager doesn’t want or need all of it, they will let you know. ### Showing Your Work at Work Communication is the focus when showing your work as part of your job. Share what is going on, both good and bad. While sharing what you have done is important, communicating what you think about what needs to be done is more impactful. Showing your work is not helpful after the fact; once the project is complete, your only option is to react. Unlike your math homework, here you want to show your work before starting the problem and as you progress through it. Proactive and early communication allows everyone around you to respond to the options and contribute to the best possible solution. Work to become familiar with your manager's strengths and blind spots. Adjust your communication to allow them to utilize their strengths and give them insight into things they may be overlooking. Below is my three-step process for showing your work. #### 1\. Share Your Plans When you ask your managers questions, they will feel compelled to answer them. They are focused on making sure you are as productive as possible. High-impact employees on a growth trajectory do not ask permission to do their jobs. This means when you ask questions about what you should do, they will probably tell you. Avoid questions that start with: > Can I/we > Am I allowed to > Should I/we Instead of asking if you should do what you know needs to be done, tell them what you plan to do and how you intend to work through the steps. A straightforward way to approach this is to start with the words “I plan to” or “I intend to.” > “Bringing your manager high-quality, well-defined problems is actually far more important than bringing them lovely but ultimately irrelevant updates about all the things you’ve already solved or easily can yourself.” **, ** [Saumil Mehta](https://medium.com/@saumil/three-simple-hacks-to-manage-your-manager-de59da535b35) When you share your plans, you give your manager an opportunity to help you make adjustments. Course correct beforehand instead of needing to redo work. You also help your manager know you are ready to own the project, allowing them to feel comfortable focusing their time and energy elsewhere. Most importantly, “I plan to” tells your manager you will do this unless they give you a reason not to. This is their opportunity for feedback. You are not overstepping here; you are taking the initiative. Here is an example: > Hey, manager, I plan to create a report about the number of defects our team is letting through. It seems like we have been letting more through recently, and it would be good to understand the scope. I will start by getting with the leads to understand what they track already, and then I will bring you an example of the report I want to build. #### 2\. Share Your Progress Step two is to update update update. Proactively track topics to share about the project. Create a reminder to share your progress and important topics. These shares should happen in multiple ways. I recommend sharing using a text medium like email or direct message and using your voice in a one-on-one or team meeting. Use the BLUF (Bottom Line Up Front) model for this communication to be considerate of your manager’s time and give them a choice about how much information they want to consume. This means starting with the main point and then following that with the details and extra information. Many people will only read the first 2 – 3 sentences of your message and then decide how much more they will consume. > When making a status update, think about these questions: > What is going well? > What is not going as expected? > Where could you use feedback? > What will you work on next? Remember, I plan to #### 3\. Ask for Feedback Step three is proactively sharing when you have completed the task/project. Check-in with your manager to see if they have any feedback about the outcome or how you could operate differently during the next project. As part of this communication, share your plans for what is next. ### Wrap It Up It’s time to stop thinking about managing up and start showing your work. Realistically, you should not be expected to manage your manager. You should also not lean on flattery or manipulation to advance your career. Focus on building a collaborative, mutually beneficial work relationship with your boss. Do this by returning some school lessons; it is time to show your work. Through proactive and comprehensive communication, show your manager that you fully understand the problem, how to get it done, and that you are ready to lead the way. Follow these three steps: 1. Share your plans with “I plan to”, 2. Share your progress by proactively sharing information about the project to help your manager fully understand the current status; 3. When you complete the project, ask for feedback and share what you will do next. Check out these related posts to help round out some of the discussion: [Professional Relationships Drive Career Growth](/blog/professional-relationships-drive-career-growth) [Hey Boss, Feedback Please!](/blog/hey-boss-feedback-please) [One-on-ones with My Manager are Kind of Terrible](/blog/one-on-ones-my-manager-kind-terrible) If you want more help improving how to show your work, [consider reaching out to me](/lets-talk).https://jessestaffordcoaching.com/blog/hey-boss-stop-solving-teams-problemshttps://jessestaffordcoaching.com/blog/hey-boss-stop-solving-teams-problemsThis is a weird situation. You were likely promoted into leadership because you excelled at problem-solving and getting things done.Sun, 07 Apr 2024 00:00:00 GMTThis is a weird situation. You were likely promoted into leadership because you excelled at problem-solving and getting things done. You have naturally used those skills to help your team succeed, but at what cost? Do you want a vacation, but your team stalls when you are not around? Are there projects you can’t get done because you are busy answering questions for your team? Have you been overwhelmed by the number of decisions you have to make? How well does your team accomplish goals without you consistently following up with them? What’s the common factor in all those questions? That’s easy, it is you! Your choices and actions keep your team from sharing the burden of problem-solving. There is hope, though. You can start changing how you interact with your team to help them run smoothly, even if you cannot be immediately available. ## Your Job Is Not to Solve Problems First things first, it is time to acknowledge that your job is no longer about solving problems. You are supposed to create an environment that empowers your team to solve problems. You have a team of intelligent people who are more than capable of taking on these challenges. All they need is for you to get out of the way. Your job is to be clear about what the team must accomplish, but not how they do it. As a leader, you should clarify outcomes, define boundaries, and share information.  ### Clarify Outcomes This is about ensuring your team understands what needs to be delivered as they support business goals and updating that direction as information changes. As a goal moves through levels of leadership, it starts relatively vague, and each leader adds the details needed for their team. This is where you do your work; make sure to understand the required outcome, and then add a layer of details for your team. Think of it like sharing on a map and describing the finish line of a race, but not the way racers should travel the course. Maybe they choose to walk, run, roller-skate, drive, or fly. Ultimately, deciding how to travel the race most effectively is where your team should be experts and make decisions. At some point, at higher levels of leadership, there may be a point where the role is about finding problems with systems that appear to be working. Then, convince the team that a problem should be solved and help define it. This is a topic for another time. ### Define Boundaries This is about clearly communicating what rules the team should follow. These can be about the number of people available, budgets, business requirements, customer timelines, or processes. The fewer rules you put in place, the more your team’s creativity will flow. Using the race analogy, add information about the course's route after you have shared the location and description of the finish line. Where are the turns? What is the general direction in which they should start? Some situations may require you to define very narrow boundaries. These may be laws, regulations, or policies that must be followed. Sometimes, we need to live with these but be flexible elsewhere. ### Share Information What data can you give the team to help inform their decisions? I believe that most people will make the same decision given the same information. As a leader, you are in a position to have more direct and indirect access to information to help the team accomplish its goals. Use your extra information to help your team understand the bigger picture. Be sure to consistently update this information as you learn more and the project evolves. Things to think about: > **Metrics the project must achieve. > Information about past projects. > Expectations of customers. > Expectations of leaders above you.** Bringing back the race analogy, describe things about the race and course to help them decide how to travel the course. These would be topics like: Is the path paved or dirt? Will the race be conducted during the day or night? Will there be spectators? How long is the course? Is it going to be summer or winter? ## What to Pay attention to Before you can successfully empower your team to solve problems, there are some things you should learn to recognize. These situations look like solving problems before assigning work to your team and solving problems when your team asks you to. ### Solving Problems Before Your Team Surprisingly, these will be the more straightforward situations to recognize and change. Many of these will happen when working with your boss or peers to determine which problems should be solved. Other times, they will come up when setting longer-term strategies and visions for your team. As these situations evolve, you will likely have an idea about how your team should work through the problem, and that is OK. This is often part of the process we follow in clarifying the racecourse. You should begin questioning this process when you get to the level of defining steps and outline a process that must be followed. These are the how parts of the problem; let your team define those. ### When Your Team Asks These are the most difficult problem-solving situations to avoid. In these cases, your team will come to you with questions about what they should or can do. Your natural tendency will be to keep them from being stuck and quickly answering their question. You can recognize these situations by listening for these kinds of questions: > **Am I allowed to ….? > Do I/we ….? > Can I/wen…? > What should I/we do …? > How should I/we …?** ## Making a Shift When you notice a situation in which you are following your natural tendency to problem-solve, it's time to pause and take a different approach. Take a moment and remember that you are here to define the finish line and racecourse. The team should be figuring out how they will tackle the race. Follow these two steps to shift problem-solving back to the team. 1. Reiterate the goal/outcome. Ask an open-ended question about the next steps. ### Step One - Reiterate Respond to each situation by reiterating all or part of the project's goals/vision and sharing some information that may help them understand the context. This step can quickly become frustrating for many leaders. Repeating goals and visions can start to feel quite tedious over time. Remember that your team is responsible for solving problems and accomplishing the critical tasks in front of you; this means that, over time, the vision and goals will “leak.” You must take every opportunity to top off the bucket to ensure that the team stays on track and is empowered to solve problems. Know that once you have repeated yourself so many times that you cannot fathom saying it one more time, you are probably about halfway there. ### Step Two – Open Ended Questions Great open-ended questions start with What, How, When, Where, and Who. I prefer to focus on What and How questions because they often get teams to start offering solutions. Here are some idea starters: Based on our goal of \_\_\_\_: > **What do you think makes sense here? > How do you think we should move forward? > Who can we chat with to get more information? > Where should we start? > Where does this fit into the process? > What needs to come first?** Remember that the outcome is essential, not the how. If the answer given will lead to the right outcome, then gracefully get out of the way and let your team do what they do best. If you have doubts about the answer given, then share some extra information that may not have been considered and see what changes. Repeat these two steps until you are reasonably satisfied with their plan. ## Problems You Should Solve OK, this post hasn’t been completely honest about problem-solving. There are problems that are important for you to tackle and should be a focus for you. These problems typically relate to Human Resources, such as compensation, conflict, hiring, performance management, and company politics. Unfortunately, many of these are parts of the job leaders dread needing to solve. Remember that your job is to create an environment that empowers your team to solve problems. The topics listed above are critical environmental factors that need to be balanced. I would also encourage you to find a project not directly related to your team’s responsibilities to tackle on the side. Use this as a way to flex your problem-solving muscles and keep yourself engaged with the business. ## Wrapping Up Your primary job for your team should be to create an environment that empowers them to solve the business problems in front of them. You should clarify outcomes, define boundaries, and share information as they work through the course. Pay attention to the times when you start defining steps and outlining the processes that must be followed. Also, pause when your team asks questions about the steps or process. These are unintentional traps where you will fall into problem-solving mindsets. Bring them into the conversation by reiterating the goal, sharing information, and asking open-ended questions. If you are looking for extra support in developing this critical leadership skill, [consider contacting me](/lets-talk).https://jessestaffordcoaching.com/blog/professional-relationships-drive-career-growthhttps://jessestaffordcoaching.com/blog/professional-relationships-drive-career-growthAre you a university student worried about securing a job after graduation? Or are you a leader finding it difficult to receive adequate support from...Sat, 30 Mar 2024 00:00:00 GMTAre you a university student worried about securing a job after graduation? Or are you a leader finding it difficult to receive adequate support from other teams or departments? You may also be searching for something to help you stand out for your next career growth opportunity. Many people misunderstand the value of having and building professional relationships. Building relationships can improve your career in many situations. However, you must start now! Professional relationships work best when you have them before you need them. Nobody likes hearing from you only when you need something. Think about that friend who only calls when they are moving 😊. You're being held back because you haven’t yet invested enough in professional relationships! ## Value of Professional Relationships Over years of supporting people’s careers, I have observed that people on upward trajectories have something that sets them apart. In school, being smart or working hard will often set you apart. At some point, it takes both; you’ll need to be smart and hard-working to stand out. By the time you get neck deep into your career, everyone around you will likely be smart and hardworking, so what is next? Professional relationships will help set you apart from the other hardworking, smart people around you. Ultimately, your ability to learn from and work within these relationships will increase your value to the business. ### A Word About Teams This is probably a good place to explain my perspective on teams. Your team is anyone you must work with to get your project from start to finish. This means people who may report directly to you, your peers (the people who report to the same manager as you), and people who may not be in your reporting chain but are part of getting the project out the door. It takes many people to complete a project, and they are all on your team. Especially in technology projects, it is less and less likely that any one person will do an entire project on their own every year. ## From your Current Seat Let’s explore how professional relationships can help you in your current position. Career opportunities can be thought of as a combination of skills and luck. Many say luck is mostly about being in the right place and at the right time. I think it is more about being on someone's mind when an opportunity comes up. Building professional relationships before you need them can significantly increase your chances of being the first name on the list for new opportunities. These relationships can also help add value to your current team and projects.  #### Value to Your Team & Projects Whether you are a leader or not, building solid relationships both inside and outside your current team often has an outsized effect on making things go smoothly and reducing frustration. First, making negative assumptions about others' intent is natural and common when we don’t know them. Strong relationships with people who are part of or related to your team and project will help you understand what drives their decision-making. This will allow you to have open conversations about what will make the best course correction or compromise in each situation. Next, with knowledge of other people's or teams’ processes and priorities, you can adjust your work, priorities, and expectations to make things move smoothly from one step to the next. More importantly, you can help those around you make the same choices because you can bring information they may not be aware of. The more you know about what people expect from you and your team, the easier it is for you to deliver things to them or work with them when exceptions need to be made. Especially when that other person might be in a place of authority over you 😉. #### Skill Building & Feedback There are many discussions out there about being a [T-shaped or V-shaped employee](https://www.linkedin.com/pulse/unlocking-secrets-t-shaped-v-shaped-employees-how-position/) and how that adds value. Realistically, you become T-shaped or V-shaped by building relationships with people who work outside of your current skill set. Building a set of broadening knowledge by learning from others is a great way to increase your chances of being the right person for that next project or opportunity. It also means you can better represent different viewpoints and explain why they are important when working through your projects. When you consider other people's interests, expectations, priorities, and backgrounds, you can provide more effective feedback. This feedback can help validate a decision or direction and suggest ways to adjust work habits to better align with others. #### Promotions or Internal Transfers Many internal promotions and transfers are decided based on existing connections and relationships. Learning about other groups and how they work can significantly help if you want to move to another team or into leadership. With connections across your organization, you will have more opportunities to share your interests and career goals. When a high-profile project or new position becomes available, you are more likely to be the person they are considering. This is how you create lucky career opportunities. ## When it is Time to Change Seats When the time comes that you are ready for a career or company change, your relationships provide a valuable service. They help you get your foot in the door. Why not ask someone you know about how the career or company works? Learn the pros and cons before getting fully committed. When you decide to apply for that next role, your connections can help you get to the front of the interview line. Or they can help you create contacts and opportunities as you grow your new business. ## A Moment Before We Take Action Consider this quote from a post by Rodolfo Anes Silveira, PhD. > “Being helpful and paying it forward can make an impact and open doors you never imagined.” - [It’snot about Collecting Business Cards or Adding Contacts on LinkedIn](https://medium.com/be-open/its-not-about-collecting-business-cards-or-adding-contacts-on-linkedin-44689a41a5d4) Don’t make the mistake of allowing professional relationships to be only about you. If you expect someone to help you, it helps immensely when you offer your knowledge and skills to them. This means that you need to do the work to open doors and make yourself useful to them in some way. What you offer doesn’t necessarily need to be tangible or direct. Maybe they need information about how your team makes decisions or someone outside their org tree to chat with. Personally, I always get joy from helping people improve their careers. If someone reaches out to me genuinely wanting to learn, you are increasing my happiness, and that is often enough for me to help you the first time. Be thoughtful about where you limit what is offered to others. Sometimes, what is needed isn’t part of your job description or the official process. Look for an opportunity to learn something or grow your skills while fostering a great relationship. Avoid, “That is not my job!” ## Where do You Start? By this point, I hope you are sold on the need to build professional relationships. However, you might have some questions and limiting thoughts. **What will I talk about?** **I don’t want to bother them.** **What if they are busy?** **I don’t want to waste their time.** Here is a guide for getting started building relationships across your organization. Start with a plan, schedule some time, and go meet with them! #### Plan A Little, but not Enough! As with all things, start by making a plan. But don’t wait until the plan is complete or you are ready. Relationships take time to build and sooner is better than later. The old saying goes, “The best time to plant a tree is 20 years ago. The second-best time is now.” Building relationships is a skill that will compound over time. I encourage you to start small and with curiosity. Start with a couple of people who are close to your position and work your way out. Make time to think about what you would like to learn and who can best help you understand that topic. Do your best to approach all these conversations from a perspective of learning what they do and why it is important from their perspective. It is easy to get distracted by your assumptions about their job, making it challenging to truly learn about the business. **Here are some idea starters:** - **Who is responsible for input to your team?** These people can help you learn how they create what you depend on. Understanding how they work can help you and your team work with them better. Consider what you can off them. Do they do something you never use? Can you offer a more straightforward solution to what they do? - **Who receives the product your team produces?** These people can best be considered your customers, even if they are not the final customer of the product. Learn how these teams process or use what you make. Understanding how they work can help you and your team optimize what you do to help them. Consider what you can offer them. Knowledge about how your work is produced. A way to work differently to make their job easier? - **Who is in a role you are interested in?** These people can help you understand the ins and outs of places you want to grow. Look for areas to focus on to improve your skills and create opportunities to take on new projects. Also, look for things you don’t like and should change directions about. Consider what you can offer them. Is there work you can do for them? Can you make their job easier? As you grow these relationships expand beyond them to the next layer of the business and beyond. #### Nothing Left but To Do It! This is probably the most challenging part. It's time actually to talk to some people.  When I first realized the importance of reaching out and talking to more people, I procrastinated. I overcame my block by scheduling time on my calendar that said, “Stand up and go talk to John!”. When these times came up, I would swing by their desk and ask if they had time to answer some questions. Over time, it became easier to chat with people, and I stopped needing the calendar reminders. My curiosity was enough to get me moving. Here is my advice: **"Cold call” them.** You would be surprised at how willing people are to talk to you, especially when you ask about them and their work. People like to talk about what they do. If you take the first step and show up with a curious attitude, you will make progress. Schedule a specific time to reach out. Walk to their desk, schedule a meeting, email them, or send a direct message. If you do not have their contact information, connect with them on a social network or ask another connection to introduce you. Offer to treat them to coffee, lunch, or drinks. You may find getting people to open up away from their desks is easier. Here is where your planning comes in. When you reach out, share with them what you would like to learn and how you think they can help. ## Wrapping it Up Professional relationships can accelerate your career. Knowing more about the people and teams around work will improve your ability to collaborate and make decisions that support everyone’s goals. Knowing more about how the business runs will help put you in the right places at the right times to get you high-visibility projects and move you to the front of the line for promotions and career opportunities. Get started by applying your curiosity to learn about the teams that support you and those you support. Start by specifically scheduling some time and cold-calling the people you can learn from. You will be surprised how many would happily share what they do with you. Remember, build relationships before you need them. Then, when you need support, they will be more willing to help. For some additional insight consider checking out this post for more ideas: [One-on-ones with My Manager are Kind of Terrible](/blog/one-on-ones-my-manager-kind-terrible) Also check out: [Stop Managing Up and Start Showing Your Work](/blog/stop-managing-up-start-showing-work) If you are looking for more help in improving your professional relationships, [consider reaching out to me](/lets-talk).https://jessestaffordcoaching.com/blog/guide-skip-level-one-on-oneshttps://jessestaffordcoaching.com/blog/guide-skip-level-one-on-onesAs you climb to higher management levels and begin leading other managers, keeping in touch with your team's pulse can become difficult. Understanding...Sat, 23 Mar 2024 00:00:00 GMTAs you climb to higher management levels and begin leading other managers, keeping in touch with your team's pulse can become difficult. Understanding what is happening at the lowest levels can help you wrap context around what your team brings you. You may also need to build stronger support for your goals and direction. Introducing skip-level one-on-ones can be an effective way to increase your engagement and understanding with your whole team. The most important thing you can do with your time is communicate with your team! ### How to start If you are serious about strengthening your connection with your team through skip-level one-on-ones, you should start with a plan. It is critical to be clear about what you want to achieve with these conversations, or you may cause stress or conflict within your team. ### **Clarify Your Goals** Start by setting aside some dedicated time to consider what you want to achieve with these one-on-ones. Here are some questions to answer to help you. - What information are you missing from your team? How can working 1 level past your directs help get that information? - What are some things you can learn about the business from individual contributors on your team? - How can you clarify business objectives for your team? - What goals or objectives can you accelerate by sharing more with the next level? - What are some goals you can reinforce for your directs? - Who can you help mentor or coach? I use skip-level conversations to keep sight of the topics the team is concerned about or struggling with. Challenges the team is excited to tackle. Answer their questions about the business. Reinforce and clarify team objectives. If requested, I offer mentorship or coaching around their interests. ### **Understand Your Time** Thoroughly review your calendar and schedule. How much of your week/month do you want to dedicate to these one-on-ones? How are you going to fit these extra conversations in? What do you need to give up to make this possible? Once you have answered those questions, decide who and how frequently you will schedule time with. Are you going to meet with everyone? Only team members at a certain level? Only people you can mentor? Only team members working on specific projects? Keep in mind that one-on-ones need to be regularly scheduled with enough time for you and your team members to prepare. For some extra insight, check out [this one-on-one guide](/blog/good-one-on-one-look-like). ### **Communicate & Gather Support** Now that you have your plans and know how this will work. There is one more critical step before you start putting invites on the calendar. It is essential that you proactively share your plan for skip-level one-on-ones with your directs. Please do not put them in a situation where they are surprised by something you shared with someone in their reporting structure. As part of these manager-level conversations, ensure you share your goals for the conversations and how you believe the managers can support you. Share who you plan to meet with and the frequency of your conversations and ask that these people get a heads-up before you schedule a meeting. Then, solicit feedback from your team's managers. What would they like you to commit to or avoid during skip-level one-on-ones? ## **An Agenda** Armed with clear goals and buy-in from your management team, it might be tempting to start chatting and see where things go. However, you must define an agenda for skip-level conversations to ensure your team and you get the most from this time. Additionally, consider sharing some of your questions with them beforehand. Here is an example of my one-on-one agenda: 1\. **Their topic**: I always start by listening to what is important to them and having a conversation about that topic. I ask probing questions to understand what makes it important today. I offer direction where I can, but only after hearing them out. They should speak the most during this time. **Some questions you can ask**: - What is on your mind today? - What has been frustrating? - What are you excited about? 2\. **Something I'm Curious About**: A fantastic way to build strong, trusting relationships with your team is to make opportunities for them to be experts and teach you something. I try to bring something I want to learn in every one-on-one. They should speak the most during this time. **Some ideas for you**: - How is their direct manager supporting them? - How is their project tracking? - What technical aspect do you want to understand better? - What process can they offer advice about? 3\. **Topics They are Curious About:** Since messages often get distilled or muddied as they work through the organization, take some time to clarify things they are unclear about. If they have nothing, share something others have asked you about. You will probably speak the most during this time, but leave room for them to expand on their question. **Some questions to get started**: - What is something that doesn't make sense to you? - Is there a topic that I can help explain? - What are you curious about? - What have you been worried about? 4\. **My Goals:** I like to close out each one-on-one by reiterating or clarifying a goal I have for the team. Do your best to make this a two-way conversation about the goals. **Some lead-in ideas**: - I've been talking to everyone about a goal I have... - How do you feel we are progressing on ...? - What would help us make more progress on ...? - Tell me what you think about our goal of ... Here's one more agenda idea: If this is your first skip-level one-on-one with someone, start by explaining your goals for the conversation. This will help them feel comfortable sharing with you. Also, consider taking some time to share about your background and hobbies. People tend to appreciate understanding how you got to your position, and it helps them understand how and why you make decisions. Here is an example of how I start a first skip level: > *Since this is the first time we’ve had a one-on-one, and I know these can be a little weird, let's start by chatting about how these work and what you can expect. First, I want you to consider this your time to share things with me. If you ever feel like you don’t have something to discuss or there is a pressing priority, just let me know. We can always reschedule or cancel. You are not wasting my time either way. Next, I will not get upset by anything you share with me, so please be honest, and I’ll do the same for you. I may want to discuss things with your manager after we chat, but it will be raised as something I’m concerned about, not something you brought up. Finally, I’m not going to share anything that I haven’t already talked to your manager about, and there may be things that come up that I’m not prepared to discuss. In those cases, I’ll just let you know that I’m unable to answer. What do you think?* ## **Things to Keep in Mind** There are a handful of other key things to be aware of around skip-level conversations. ### **Be Consistent** Always share a consistent message/direction/strategy with everyone you talk to. It is a bad look to appear to change your opinion based on who you are talking to. For example, if you agree on a direction with one person, do not change that direction when talking to the next person. Always be consistent in describing the team’s objectives and outcomes, and do not purposefully or inadvertently give two people or groups conflicting directions. ### **Do Not Surprise Anyone** You and your team's managers should share a consistent message. You should avoid sharing something that conflicts with what their direct manager is saying. It is critical to refrain from sharing news, feedback, or assigning tasks during a skip-level discussion you have not previously discussed with their direct manager. Also, follow up with their direct manager to share anything they need to follow up on or provide support after your skip-level conversation. Don’t let these things wait until their manager finds out from someone other than you. ### **Do Not Waste Time** The last thing we need is more time preparing for and participating in meetings, which do not add value. If you consistently do not get valuable conversation from a skip level, cancel the one-on-one series. Don’t spend either of your time on something that isn’t helping. This can take several forms. For example, can you consistently tell that they are saying what they think you want to hear? Are the conversations always met with short answers or no curiosity from them? Lastly, if they consistently miss the meeting time, then it is not valuable to them. Do your best to avoid missing the one-on-one without advanced notice. Likewise, try to avoid canceling or rescheduling at the last minute. Sometimes, it is necessary, but communicate what is happening and offer to reschedule. ### **What not to include** Some topics are not for skip-level conversations. I suggest not bringing these up or redirecting the conversation to their direct manager. Improvement or disciplinary feedback that their manager still needs to provide directly to them. These topics are best handled and followed up with their direct manager. You are likely going to be missing some crucial context or information to be able to give good feedback. If you have feedback for this person, work through their manager to deliver it. However, you can reinforce feedback their manager has given them by offering mentorship or guidance on the topic. ## **Wrap it Up** Skip-level one-on-ones can be a great way to increase your connection with your greater organization. They can also be a valuable source of understanding as you set direction and share up the organization. Set clear goals and agendas for your skip-level conversations. Do not surprise anyone on your team with these discussions. Lastly, reflect on your skip-level conversations over time to ensure you are not wasting anyone’s time. If you found this insightful, check out these other posts. [What Does a Good 1-on-1 Look Like?](/blog/good-one-on-one-look-like) [One-on-ones with My Manager are Kind of Terrible](/blog/one-on-ones-my-manager-kind-terrible) [When Candid Communication Isn't Enough](/blog/candid-communication-isnt-enough) If you want to improve your leadership skills or want to talk more about improving your one-on-one conversations, [consider connecting with me](/lets-talk).https://jessestaffordcoaching.com/blog/stop-optimizing-pasthttps://jessestaffordcoaching.com/blog/stop-optimizing-pastI have had the fortune of learning a lot about development processes and how people approach work. It is always amazing to understand what excites...Sat, 23 Mar 2024 00:00:00 GMTI have had the fortune of learning a lot about development processes and how people approach work. It is always amazing to understand what excites people about work and how they see their role in creating our products. I find great pride in helping people evolve their practices to improve how products come together. Let's explore some observations I have made about what drive people to optimize, and some ideas on how to move to a different way of thinking. ## What drives optimization? I have noticed a typical driver in how many groups and companies define their development practices. These practices start by working to prevent pains the team has encountered in the past. We build our documentation, processes, and automation around avoiding things that have happened to us before. “This happened once, three years ago, and in response, we implemented a rule to prevent it from happening again.” I will share a scenario from my experience. One of the teams I work closely with adapts products from one market for other sales opportunities. This team traditionally operated 2-3 years behind the rest of the company in terms of software libraries and improvements. Developers on this team have built deep, ingrained expertise in navigating our company’s legacy code and are well-versed in the pains that go along with that. All their documentation, tasks, and methodologies are designed to find and navigate problems in those legacy products. They maintain numerous versions of software and tools that have been designed to overcome every fathomable scenario. Fast-forward to today. This team is now trending about 6 – 12 months behind the rest of the company, and their mindset is still about preventing hardships around 3-year-old code. They are optimizing for a problem that doesn’t often occur anymore. ## Why do teams focus on the past? In the simplest form, our teams tend to optimize for the past because that is what they know. We do not really know what we will encounter. Also, if we look for data about where issues occur, it will always point to work we have completed. When looking for opportunities to improve, it is easiest to look at the tasks and processes that were most difficult to accomplish in our most recently completed projects. Additionally, we naturally look to prevent pain and discomfort. This could also be described as a fear of failing or making a mistake more than once. You only need to grab a cactus once to learn that touching anything with spines sticking out will likely hurt. The next time you encounter anything with spikes on the side, most of us proceed with caution and a different approach. However, experience with cactus doesn’t teach you that fire will hurt. This combination of a deep understanding of our prior work and natural tendencies carries over to projects and process improvement. ## Overcoming The Past Overcoming our inclinations to prevent pain is ultimately more difficult than it sounds. Our natural tendencies are a potent force. Begin this process by: 1. Identifying the largest past pain points. (What Hurt the Most?) 2. Review the upcoming roadmap and priorities. (What will be common?) 3. Figure out what pain points will likely exist in upcoming projects. 4. Plan efforts around upcoming projects. (Optimize for the Future) ### What Hurt the Most? Start the conversation by acknowledging that past problems must be part of the conversation. Ensure that the team knows they can factor those lessons into our future projects. Bring the information and data from those lessons as you start planning future projects. Review your data and look for the places where the team put the most effort. Collaborate to clearly identify the key factors that cause those scenarios. ### What Is the Roadmap? Openly share the product plans and requirements with them. Allow time for the team to review and think about the challenges they foresee with those projects. Be available to answer any clarifying questions they may have. ### What will be common? Next, look for common elements of your future projects. Create an opportunity for the team to identify if we will encounter any of their large pain points in future projects. Prioritize these for optimization and tie metrics to the projects that will benefit from the improvements. Find a way to understand if the team improved. > *As an aside, it is important not to optimize for every possible pain point, even if it will occur in future projects. I often ask my team to solve the problem for only 51% of situations we will encounter. Using this definition, we can say anything else is an outlier and should be considered a special case. It is not possible to reliably optimize for special cases. For special cases, encourage your team to focus on the situations they will encounter more often and optimize for those.* ### Optimize for the Future! Next, it is time to start talking about where you can optimize the process. Be sure to remind everyone that the projects in the upcoming plans must take priority in deciding where to optimize. They must explain where a concern will likely exist in a future project before we can tackle solving it. If none of the future projects likely include our pain points, then it doesn’t benefit us to solve a problem we are not likely to encounter. ## Span of Control and Sphere of Influence One last area to consider is that as you and your team work through the solutions to the problems they are likely to encounter, ensure they are looking to solve the root of the problem as much as possible. Often, the pain points our team voices are related to inputs or outputs to the team. If your team depends on information from someone else who provides unreliable timing, does it make sense to solve the problem with internal processes? ## Things We Just Live With Avoid falling into the [learned helplessness](https://en.wikipedia.org/wiki/Learned_helplessness) trap. Look for opportunities to re-evaluate the intent of rules or assumptions that are in place. There may be decisions that were made in the past about our products that are no longer important or have a different goal now. If something takes a large portion of time, it never hurts to ask if doing that is still important or if there is a different way to accomplish it. In the worst-case scenario, you continue as is. ## Wrapping Up We are naturally wired to prevent pain, especially things we have encountered before. Battle this tendency by embracing where those lessons can apply to upcoming work. Review upcoming work with the team and analyze it against what they are most concerned about and what will be most recurring. Solve the problem for 51% of situations. All other situations are special cases that must be handled as they come up! Frequently remind your team of these ideas as they plan where to optimize. Watch for a tendency to optimize for situations that are unlikely to occur in future work. Avoid solving problems with inputs by adjusting internal processes alone and occasionally question time-consuming requirements. If you are looking for someone to help you identify ways to improve processes at your company, [consider connecting with me](/lets-talk).https://jessestaffordcoaching.com/blog/candid-communication-isnt-enoughhttps://jessestaffordcoaching.com/blog/candid-communication-isnt-enoughJust about every problem I work through in my role boils down to needing to communicate more and more often. Early on, as an engineering leader, I had...Sat, 16 Mar 2024 00:00:00 GMTJust about every problem I work through in my role boils down to needing to communicate more and more often. Early on, as an engineering leader, I had to tackle a strange communication problem. I led a small team of 3-4 engineers who supported our production development teams. This team had fully embraced a Scrum mindset, and due to rapid prototyping requirements, the team worked in one-week sprints. This means we had planning, standups, retro, and demos every five days. Between standups and other ceremonies, they collaborated daily, looking for peer reviews and technical support. They were proud of their ability to be direct with each other, not needing to "sugarcoat" the message. Yet there was still a problem. The team was always working in drastically different directions and at various technical levels, constantly bickering about what needed to be done. One-on-ones with me were full of complaints about other team members and were always heated. How could there be such a big problem with a group of engineers who were always so open about the work? ## **Candid and Frank** I took some time to observe their interactions, choosing a place to sit where I wasn't immediately visible but could still hear the conversations. What I heard was a lot of very candid discussions. ### "Your idea just isn't going to work; you need to pick a different way." ### "If you do that, everything will break!" **"What were you thinking when doing that?".** Why would direct, candid conversation on a team not be positive and proactive? I can sum up the answer with one word, "FEELINGS." If you are an engineer reading this, you may be thinking. "Feelings don't belong at work." "There aren't feelings involved here, just facts." While technically correct (not the best kind of correct), you must remember that even though everything said may be accurate or fact-based, the thoughts and words still need to be humane. We (humans) are primarily driven by emotion. As team members were working with each other, their conversations held no regard for the emotional position of the other person. One would get frustrated and say something factual in a "mean" way and upset the other. The conversation would continue to go on and devolve into a full-blown argument, with both people ultimately being angry with the other one. Nothing would get resolved. This means that other team members or I would have to choose a direction, ultimately alienating one of them. #### **Some Definitions:** **Candid**: *truthful and straightforward; frank.* **Frank**: *open, honest, and direct in speech or writing, especially when dealing with unpalatable matters.* Candid and Frank have very similar definitions, and ultimately, this is how we want our teams to communicate. However, these definitions miss accounting for the emotional components of communication. In my experience, many engineers work based on the literal definition of most things. This means that when asked to have candid or frank conversations, they will take this to mean they can say anything as long as it is open, honest, and direct. **NOT TRUE!** **We need a way to communicate that is Respectful and Frank.** ## **Frank but Respectful** **Sugarcoat**: *make superficially attractive or acceptable.* Or *make excessively sentimental.* Many people, especially in engineering, believe that asking them to be aware of people's feelings is the same as telling them to sugarcoat the situation. "Sugar coating is something managers do when they don't want to tell us the full truth." This is tantamount to asking the engineers to lie to each other. Why would we want them to lie to each other? **Cordial**: *warm and friendly.* We don't want anyone to lie. We want everyone to be cordial. Being frank in communication doesn't require us to be mean or disrespectful. This means that we must be aware of the feelings and emotional position of the person we are talking to. (As an aside, to many engineers, this also means that there must also be mutual respect. The topic of respect will be covered in a future post.) This means that we shouldn't say things that will upset each other. Also, if we unintentionally upset someone, we must understand how to recognize that and figure out how to lower the tension. This often means backing down from a point or taking a break in the conversation. Both of these things mean we must form new communication habits. These things are usually referred to as Soft Skills. ## **Advice and Tips** I want to go over some ways I worked with my team to mitigate the problems with our communication. This didn't get better overnight. There was a lot of pent-up resentment toward each other. Don't relent on this topic; it is the most important thing you can do for a healthy team. ### **Be a Team First and Foremost** Let's go back to some things my team said to each other. ### "Your idea just isn't going to work; you need to pick a different way." ### "If you do that, everything will break." **"What were you thinking when doing that?".** Do you see why those comments above might be a problem.? They are directed at an individual. The word "you" is the problem. We are a team. Look to adopt this mindset: "If one of us has a problem, all of us have a problem." Do not allow a team to fault a single person. Directing our statements toward a single person is like attacking them, triggering the fight-or-flight response in most people. The opportunity is to stop using the word "you." It doesn't belong on a team. It is easy enough to replace the word "you" with "we," "us," "our," or "this." The better option is to remove people from the conversation entirely. This means that all conversations should be directed at the project or task. Projects are emotionless. Taking the statements above and rephrasing them to be less emotionally charged. ### "This doesn't seem like it will work; let's find a different solution." ### "Doing that will cause problems with the <project or feature>." ### "This isn't a good practice; it would be better this way." ### **If I'm Frustrated** It is important to remember that communication requires two people. If you get frustrated in the conversation, the other person will likely be, too. We need to learn ways to deal with this quickly before it escalates into anger and resentment. - Just because they attacked you doesn't mean you should attack back. Retaliation always escalates the situation. - Everyone is trying to make the projects successful. Please don't allow yourself to think that they are intentionally trying to upset you or be difficult. - Walking away to calm down and think about the problem is always an option. However, close the conversation before leaving: "I would like to take some time and think about this more." "Perhaps now is not the time to solve this problem." "I have some other things to get done. Let's pick this back up later." ## **Communication is Everyone's Problem** Everyone involved needs a coaching session when a team has a communication problem. Don't make the mistake of singling someone out. This legitimizes the other person and brings one team member down more. Make it clear that everyone is being held accountable for improving this situation and that they are all having the same conversation, though individually. When discussing these situations, give specific examples and explain what went wrong. Always suggest how it could have been handled differently. Staying alert to the communication happening around and within a team is crucial to being a strong leader. We can only perform at our best if we communicate clearly and effectively. Keep in mind we are shooting for “**Frank but Respectful**.” If you could use some additional help improving communication within your team or your own communication style, [reach out, and let's chat about how I might help.](/lets-talk)https://jessestaffordcoaching.com/blog/we-learn-ranchershttps://jessestaffordcoaching.com/blog/we-learn-ranchersSome of my youth was spent around farms and ranches, which has left me with interesting perspectives. I could talk/write about these perspectives for a...Sat, 16 Mar 2024 00:00:00 GMTSome of my youth was spent around farms and ranches, which has left me with interesting perspectives. I could talk/write about these perspectives for a while. I will focus on one area in this post: reusing old tools to build new ones. ## Not Developed Here Many software engineers are keen to borrow others' ideas or snippets of code. They are often on board with using an entire library or program that does everything they need. Getting them to use something they didn't create can often be challenging, as it may not directly meet their needs. Or sometimes, they think they can build a better mouse trap so every other one out there won't suffice. We hear things like, "That's not how it should be done.” “What they did doesn't make sense,” and “I can build what we need faster than integrating that system." These are all forms of saying, I didn't make this, and I know I can do a better job, so I won't use it. I've personally done this many times. It’s easy to believe that we have the better answer. One of the most prominent examples of this I've seen in my work was related to building a deployment system. We had a clear, reliable system of continuous builds but didn't have an excellent way to deploy those builds to target hardware for demos and testing. After investigating, we believed that creating a deployment system seemed straightforward, and my team started planning. One day, we learned that someone else was working on something similar. It could deploy but didn't support notifications and scheduling. Then we realized that another team was working on the same thing but required someone to choose what was deployed to each piece of hardware manually. Did we work together and find a standard solution each of us could build to meet our requirements? Of course not; we built three solutions to essentially the same problem. ## The Scrap Pile  There has always been one very common thing on every farm or ranch I've seen: a big scrap pile. This is a pile of things that have been broken through use or replaced with newer equipment. They keep these because they are a valuable source of parts and future tools. What does a random pile of parts have to do with software development? Sometimes, we build or replace software that doesn't meet our needs. Does that mean it isn't useful? Sometimes, we write useless code, but sometimes, there is another use. One time, I was working on a project to create a more efficient library for one specific area of our product. I built a lightweight, fast event system that I thought was neat. However, it didn't work or make sense when I applied it to my problem. Instead of deleting the library and moving on, I stashed it in a folder on my PC and forgot about it. Sometime later, a co-worker tried to solve a different problem and casually mentioned needing a fast event system. I pulled this library out of my random folder, and we saw a 5x speed improvement in the feature they were working on. This useless pile of code was a huge improvement to our system. ## The Hyster Hay Squeeze [./images/we-learn-ranchers/03.jpg](./images/we-learn-ranchers/03.jpg) When I think about reuse, I always remember this one hay farm I worked with. They had this interesting piece of equipment called squeeze to move and load stacks of hay. These are expensive, specialized pieces of equipment. As of this writing, a 10-year-old used model sells for well over $100,000. The farmer I was working with couldn't afford/justify the purchase of a hay squeeze for their needs. He found a used 5-ton forklift, turned the forks on their side, and added a hydraulic ram to build his version. For around $10,000, he had a fully functioning hay squeeze that he built out of a tool that didn't quite do what he needed and a scrap pile. It doesn't look as good, but it does the same job.  ## A Head Start == Money in the Bank Starting with a library, project, tool, or feature that isn't quite what you need should be considered a head start on meeting your goals. Even if that library has an associated cost, the savings are probably worth it. In my story above, the farmer saved at least $90,000 by starting with an existing tool and modifying it. Considering salaries and operating costs in the market, it is hard to imagine that we can justify spending weeks or months rebuilding something that mostly exists today in another form. Putting our pride and egos aside and putting our energy into extending or adapting the existing tools to meet our needs makes more sense. It will usually be at least as good and cheaper in the end. ## Solving the Right Problems It is important to stop and reflect on what we are working on. We should always focus on building software directly related to our problem domain. If you are building a SAAS service for Veterinarians, will you spend your time implementing a scalable web server? No, buy a scalable web server and make the parts that are specifically needed by your veterinarian customers. Take the parts and pieces that can be used from other areas and adapt them to meet your needs, just like our local farmers do.https://jessestaffordcoaching.com/blog/winninghttps://jessestaffordcoaching.com/blog/winningThere is one question that I ask very frequently. "Are you winning?".Sat, 16 Mar 2024 00:00:00 GMTThere is one question that I ask very frequently. "Are you winning?". When I ask this, I often get an awkward smirk in return and some kind of "What do you mean?". ## The Race A large part of my early life was dedicated to sports and athletics. With most sports, there is always a clear winner. I would like to argue that there is rarely a clear loser. Many world athletes participate in activities like track and field, cross country, ski racing, marathons, and more. Most of these people focus on improving their skills, abilities, and results. Anyone who has shown improvement or set a personal record will walk away from the event feeling a sense of accomplishment that is hard to replicate anywhere else. These people feel the true meaning of winning. ## Are you Doing Better Today than Yesterday? This is the real question, isn't it? You win if you have learned something new, completed that difficult task, or helped a co-worker get unstuck. I consider it winning if you are happier today than you were yesterday. We should feel like winners anytime someone leans on us for expertise. There may be days when we don't feel like winners, and there will likely be days when we aren't doing better than before. Especially as we grow into leadership roles, sometimes it can feel like more bad things are going on than good. ## Choose to be Winning Are you winning? Take some time to ask yourself each day. Take some time to ask someone else each day. Take some time to focus on what it means to be winning for yourself and those who depend on you. If you can't say you have won today, you owe it to yourself to bring a better attempt the next day. If you can't find a way to win at something, it's time for some hard reflection about what needs to change so you can make that next goal. We have to choose to be a winner each day. This can take many forms, but finding something to feel good about each day is extremely important. Today, I wrote this, and I am winning!https://jessestaffordcoaching.com/blog/one-on-ones-my-manager-kind-terriblehttps://jessestaffordcoaching.com/blog/one-on-ones-my-manager-kind-terribleDo you find yourself dreading those one-on-ones with your manager? Are you not sure what to tell them?Mon, 11 Mar 2024 00:00:00 GMTDo you find yourself dreading those one-on-ones with your manager? Are you not sure what to tell them? Are you not sure how to get good feedback from them? One-on-ones should be your time to get advice on your career and goals. Share your accomplishments from your perspective. Also, discuss anything you are concerned about or afraid of in your job or future. Instead of waiting for your manager to figure it out, take the lead and make this time valuable to you. Use this post for some ideas on how to get the most out of this time with your manager. You can turn these conversations into something you look forward to by working through some high-level steps. 1. Think about how you want to grow/improve. 2. Drive the conversation based on your goals. 3. Follow up and ask for feedback. ## A Little Background on Your Manager Before we get too far, let’s explore a little bit about why they might not be good at this. Most managers started as people doing the work, probably a similar job as you. Often, they were promoted because they were one of the best at that job. Unfortunately, people usually move to management roles with minimal training. Remember, they are people doing their best, just like you. They probably don’t have good examples of one-on-ones to lean on for experience. One more idea to keep in mind. Your manager likely has many responsibilities, including the others who report to them, the projects they are responsible for, and working through their career goals. As a result, they may not spend much, if any, time thinking specifically about coaching feedback for you. Likely, they don’t have any feedback for or about you. ## Start With a Plan I assume that if you are reading this, you are looking for some kind of improvement or career growth. It is easier to get the most out of a one-on-one when you start with yourself. That could be about learning and development or feedback for your manager. Either way, make some dedicated time to think about what you want to discuss during your one-on-one. As part of this process, take some notes or make a list of topics for your manager.  ### Opportunities for Learning and Growth This is your opportunity to get advice about leadership opportunities, a role change, or a raise. Your goal for a discussion with your manager is to be genuinely curious about what they see as ways for you to improve. Ask questions that show you are eager to make progress. Here are some things to think about: - Where do you feel like you are not giving your best? - What skills do you want to use at work? - What skills do you have no interest in using at work? - When do you feel least enthusiastic about work? - When do you feel most enthusiastic about work? - Do you feel challenged at work? What would a challenge look like? - What does your manager do well, and would you like to improve yourself? - What recent interactions do you think you could have handled better? - Would you like more leadership opportunities? - Are you looking for a promotion? Also, check out [Hey Boss, Feedback Please!](/blog/hey-boss-feedback-please) ### Feedback for your Manager Sometimes, you may not be ready for learning, or there may be something else you need to see change to improve your satisfaction. In this scenario, look to calmly bring facts to a conversation with your manager. Often, these situations can have a big impact on your day-to-day life or, in some way, carry a fair amount of emotion for you. As you take notes about this topic, think about how to structure good feedback. Take some time to look at the [SBI Feedback Model](https://managebetter.com/blog/sbi-model-feedback-examples) or the [STAR Feedback Model](https://trainingcoursematerial.com/free-training-articles/coaching-feedback/star-feedback-model). There are many ways to structure input, and I find success with these. Following a structure will help your feedback get a meaningful response from your manager. Here are some things to think about: - What are things you appreciate about our manager? - What habits does your manager have that bother you? - What are some things you are concerned about or worried about? - What are you excited about or looking forward to? - Are there members of your team doing a great job or did something you appreciate? - Are there members of your team who are not meeting your expectations? - Are you feeling too busy or overwhelmed? - Where do you feel like you are excelling? - What company/team processes are in your way? ### Other Topics to Think About Sometimes, what you need isn’t about any of the topics above. In these cases, your manager can still offer valuable insight. - Do you have questions about benefits? - Can they walk you through a company process? - Do they have insights about the team’s or company’s future? ## Have the Conversation Now that you are prepared, it's time to share your thoughts and questions with your manager. This is probably the hardest part because it requires you to express your thoughts in an understandable and meaningful way. Depending on the feedback in your notes, you may be questioning if you should “bring that up” with your manager. Your brain is fantastic at bringing worst-case scenarios to the forefront. Please remember that these conversations are always more difficult in your head. Lean on your preparation and share your thoughts. After that, let the conversation happen. Remember these quotes from Susan Jeffers as you prepare for that next one-on-one. > “Remember that underlying all our fears is a lack of trust in ourselves.” > ― Susan Jeffers, [Feel the Fear and Do It Anyway](https://susanjeffers.com/books/feel-the-fear-and-do-it-anyway-revised-and-updated/) > “If you always do what you’ve always done, you’ll always get what you’ve always got.” > ― Susan Jeffers, [Feel the Fear and Do It Anyway](https://susanjeffers.com/books/feel-the-fear-and-do-it-anyway-revised-and-updated/) ## A Final Thought Sometimes, one-on-ones don’t need to have a clear purpose. If you are happy and things seem to be working the way they should, then it is ok for this time to be a simple conversation. Sometimes, just talking about life or your shared interests is just as good. It never hurts to strengthen your relationship with your manager. If you are curious about other points of view about one-on-ones, check out this guide for managers: [What Does a Good 1-on-1 Look Like?](/blog/good-one-on-one-look-like) If you could use some additional help figuring out how to get more out of your one-on-ones, or you are looking for a new perspective on your career development, [reach out, and let's chat about how I might help.](/lets-talk)https://jessestaffordcoaching.com/blog/hey-boss-feedback-pleasehttps://jessestaffordcoaching.com/blog/hey-boss-feedback-pleaseAre you looking to level up or improve at your job but struggling to get good feedback from your manager? This post will explore how you can take the...Sat, 02 Mar 2024 00:00:00 GMTAre you looking to level up or improve at your job but struggling to get good feedback from your manager? This post will explore how you can take the lead in getting great feedback from your manager. ## **Walk A Minute in Their Shoes** Let’s start with a little perspective from your manager’s point of view. Most managers started as people doing the work, probably a similar job as you. Often, they were promoted because they were one of the best at that job. Unfortunately, most of the time, people are moved to management roles with little to no training. Remember, they are people doing their best, just like you. Likely, they don’t receive good feedback or have a mentor available either. Know that feedback is difficult to give, especially negative feedback. Our brains always jump to the worst-case scenario, making us scared to deliver information we know people need. For many people, giving feedback can be worse than public speaking. Without training, many managers will avoid sharing feedback until the situation is so extreme that they have no choice. One more idea to keep in mind. Your manager likely has many responsibilities, including the others who report to them, the projects they are responsible for, and working through their career goals. As a result, they may not spend much, if any, time thinking specifically about coaching feedback for you directly. It is likely that they just don’t have any feedback for or about you. ## **You Can Do Something About This** It is rare to find a manager who is unwilling to help someone interested in improving. Improving helps you and your manager. Ultimately, you will need to take the lead and initiate the conversation.  ### **Do Your Prep Work** Take some time to think about specific areas you would like to improve. It is easier to get feedback when you can be specific about what. Think about these questions. - Where am I not doing my best work? - What situations are difficult for me? - What projects would I like to take on? - What new skills do I want to be part of my job? - Am I looking for a promotion? Next, make sure that you are ready to receive feedback. Do not start the conversation if you are having a bad day or frustrated with something at work. Remember that feedback is hard to give; you want to make it as easy as possible. Your attitude will significantly impact the quality of feedback you receive. Finally, be prepared to be patient. Your manager will likely need some time to think about your request. ### **Start the Conversation** In a one-on-one or other private conversation with them, tell your manager that you are looking to improve yourself and would like feedback on areas to focus on. Share some of the specific areas from your preparation. Share that you are happy to give them time to think about it. Follow up with an email or other written message to say that you look forward to receiving their feedback. Remind them of the specific areas you would like to improve. Here are some more specific questions that I find helpful when asked: - “What is a goal you have for me?” - “What more can I do to achieve that goal?” - “I would like to take on a personal challenge. Do you have any suggestions?” - “What could I have done better on my last project?” - “What is something I can work on to prepare me for my next promotion?” ### **Receive the Feedback** When your manager is ready, ask for their feedback. Remember to make sure you are prepared to receive feedback. Receiving negative feedback is difficult. You must receive it well, or you will make it more difficult for them next time. Even if you disagree with the feedback, just say “Thank you” and “I will work on that.” DO NOT try to explain or justify why you did or do what they are giving feedback on. DO ask follow-up questions and ask for their help in improving in those areas. This will let them know you are listening and clear on what they are saying. - Do you have any advice on steps I can take to work on that? - How do you handle situations like that? - Do you have suggestions on training material? ### **Follow Up** Take time and truly work to build new habits around their feedback. After some time, follow up with your manager. Share what you have been doing based on their feedback. Ask if they are seeing any change. “I have been trying … to work on your feedback. Have you noticed any improvement? Can you think of something else I could try?” ## **Wrap It Up** Unfortunately, your manager probably doesn’t have great training. They also likely don’t spend as much time thinking about you as you believe, which is probably good. For most people, if their manager is focused on them, it is not for good reasons. You can take the lead in asking for feedback. Take some time to prepare, making sure you know what areas you would like feedback about. Make it easy for them to give you feedback by asking specific questions and giving them time to think about it. Receive the feedback well by saying “Thank you” and no more. Finally, follow up with them to see if your changes are working. If you could use some additional help figuring out how to ask for feedback, or you are looking for a new perspective on your career development, [reach out, and let's chat about how I might help.](/lets-talk)https://jessestaffordcoaching.com/blog/good-one-on-one-look-likehttps://jessestaffordcoaching.com/blog/good-one-on-one-look-likeI have been talking about one-on-one discussions with other leaders more often lately. Nowadays, people can easily switch teams and companies, making...Fri, 01 Mar 2024 00:00:00 GMTI have been talking about one-on-one discussions with other leaders more often lately. Nowadays, people can easily switch teams and companies, making building a solid relationship between managers and team members more crucial than ever. Have you been wondering how to encourage your team to open up more about what's happening? Are you concerned you're losing touch with your team's day-to-day activities? Or are you aware of what they are working on but don't have enough information to determine if they're making the right decisions on the ground? You may have also noticed that your team members' skills aren't improving as they should. Regular and well-structured one-on-ones can be a great way to establish better relationships and more robust communication channels with your team. Throughout my career as a leader, I have held regular one-on-ones with over a hundred individuals and found the timing and structure that works well for me. ## A one-on-one is not! Let's talk about what a one-on-one is not. A one-on-one is not when you casually stop by their desk and ask, "How's it going? Are there any issues?" Your team member will often give you the old thumbs up, and you move on to the next desk. These flybys are positive. I believe a manager should talk to everyone on their team daily, which is a great way to keep on top of daily issues or celebrate successes. They don't replace a good one-on-one, though. Similarly, having an open-door policy is not a substitute for a one-on-one. Your team knows they can talk to you, but if a strong relationship doesn't exist, you will only see them once the problem is too severe. Understand that your team thinks you are always busy and will not want to interrupt you with things that are not important. No leader in their right mind would say they have a closed-door policy. Don't be the person who leans on your open door as a replacement for good communication. Communicating with your team is the most essential and best use of your time! ## A one-on-one is! Good one-on-ones are regularly scheduled and recurring discussions. They also have a good structure, allowing both of you to feel comfortable saying what needs to be said and leave feeling heard. ### **Regularly Scheduled** Regularly scheduled one-on-one meetings are on your and your team members' calendars, with sufficient preparation time. Don't surprise people with a last-minute one-on-one if you can avoid it! Last-minute meetings often cause team members to stress leading up to the meeting, which may set the relationship back for some of the conversation. They should also be scheduled at a frequency that allows you to talk comfortably to each other and cover everything that needs to be said in the time allotted for one-on-ones. Some team members may need these more frequently, and some may need them less. You should never go more than 4 weeks without a good one-on-one conversation with your direct reports; skip levels may differ. I always recommend starting with every 2 weeks and adjusting more or less frequently over time. After 3-6 months, you can identify if some team members could use more frequent conversations or less. The frequency may not remain consistent over time but depends on each relationship. ##### **How do we decide who needs more frequent touchpoints?** Determining how often to meet with team members can be challenging, as there is no concrete answer to this question. However, there are some trends that you can look out for to help you decide. If your one-on-one discussions consistently run over because they bring a lot to the meeting, this is a key sign that they could use more of your time. High-potential team members should get more frequent touchpoints so you can help them navigate the career ladders at your company. Additionally, if a person is working on a high-priority or high-stress project, don't neglect your top performers because you don't have much feedback. On the flip side, if a team member often doesn't have anything new to cover or you get through everything well before the end of the meeting every time. This is a sign that you aren't pushing them hard enough, but that is a different topic ;). It is also a sign that reducing frequency would probably be OK. Be wary if you always end a one-on-one early, especially when first starting out. This can be a sign that you don't have a good relationship with the team member yet. Or it could mean that they are already disengaged from the team. I recommend sticking with a frequency for 3-6 months before deciding. ### **Well Structured** A consistent format or agenda for one-on-one meetings with team members can help them prepare for the conversation and avoid surprises. While you should encourage your team members to take the lead in the conversation, it will be up to you to set the agenda since you are their leader. These meetings aim to discuss their experiences and career growth within your company. Ultimately, you should decide on a structure and agenda that works best for you and your team. Here's an example of a structure that I commonly use in my one-on-one conversations:  Notice that only 2 of the 6 topics are primarily driven by me. ### **Some Tips and Guidelines** Since one-on-ones can be broad conversations, practicing boundaries for yourself when leading a one-on-one is good. Below are some practices and guidelines I've developed for myself and recommend: - One-on-ones are not project status updates. If your team member wants to discuss what is going on with the project, that is fine. However, you should primarily be getting progress updates in another way. This does depend on frequency and level. My current manager-level discussions cover a lot of project status because we also meet 1-2 times a week. - Show and practice active listening. Dig into what they said by asking directed questions to get more information. Rephrase what they said to you. Put the digital distractions away! - Ask more questions! Great leaders are curious; this is your opportunity to learn something from them. How are they doing mentally? How is their workload? Are they working towards or achieving team and department objectives? What are they doing to achieve those? What could work better? What has been frustrating? What is going great? What are they looking forward to? - Start with them. I often open my one-on-one meetings with a variation of "What is on your mind today?" Then, I follow up with additional questions to explore why that is important or how it affects them. - What are their goals? How can you clear roadblocks or make opportunities for them? - Focus on open-ended questions. Start questions with "How," "What," "When," or "Where." Yes / No questions will usually get you exactly that, a brief answer. "Why" questions tend to subconsciously put us on the defensive. Don't inadvertently derail the conversation by making them wonder about your intentions. - Location is important. Where the one-on-one happens has an interesting impact on the types of conversations you will have. Try meeting in different places or going for a walk. I'll cover more about this in another post. ### **Have the whole conversation!** Finally, one-on-ones are essential for building relationships. Don't let them end early! I know everyone is busy, and there are other things all of us could be doing. Ending the discussion early will often indicate that one or both of you are disengaged, and this is a concern that needs to be resolved. If you run out of work-related topics, start learning more about each other's interests outside of work. The most important thing you can do with your time is communicate with your team! ## Wrapping It Up One-on-one discussions are critical for the success of any leader in today's business world. Ensure you set aside regular dedicated time to meet with your team one-on-one. Have a consistent schedule set well enough in advance that both you and your team can prepare. Define a consistent agenda focused on them and their careers, then lead them through that agenda. Get out there and fill your calendar with opportunities to communicate with your team! Also, check out this [guide for skip level one-on-ones](/blog/guide-skip-level-one-on-ones). If you are looking for help improving one-on-ones with your team, consider contacting me. [Let's talk about how you can improve this skill.](/lets-talk)