I manage a team that is spread across Los Angeles, Eastern Europe, and Southeast Asia. Some people are in our office. Some have never set foot in it. On any given Tuesday, I might have a developer submitting a pull request at 7am in one timezone while a project manager is wrapping up end-of-day notes twelve hours away. They are both on the same product. They have completely different needs from me as a leader. And for the first couple of years of running this kind of team, I was largely guessing at what those needs were.
The guessing cost me.
Good people got less support than they needed when they were struggling. Capable people got micromanaged when they were ready to run on their own. And the worst part was I had no idea it was happening, because the signals I would normally rely on to tell me which was which – body language, tone, the way someone pauses before answering a question – were not there.
All I had was a Slack message.
That experience is what made me take situational leadership seriously. Not as a framework to put in a deck, but as a practical problem I needed to actually solve.
What Situational Leadership Actually Means in Plain Language
Situational leadership, developed by Paul Hersey and Ken Blanchard, is built on one deceptively simple idea: there is no single best leadership style. The right approach depends on the person and the task. Someone new to a role needs clear direction. Someone who has done something a hundred times needs to be left alone to do it. Someone in between – capable but uncertain – needs encouragement more than instruction.
Most managers intellectually agree with this. The problem is execution. Adapting your style requires reading where someone actually is right now – not where they were last quarter, not where they are on other tasks, but on this specific thing, today. And that reading is hard enough in an office. In a distributed hybrid team, it becomes a genuinely different kind of challenge.
Gallup data from mid-2025 shows that only 47% of employees strongly agree they know what is expected of them at work, and just 31% say someone at work actively encourages their development. Those numbers suggest that most managers are not adapting their style at all – they are applying one mode broadly and hoping it lands.
The Signal Problem Nobody Talks About
In a traditional office, reading a team member’s development level is partially unconscious. You see hesitation. You notice someone getting quieter in meetings about a topic they used to speak confidently about. You catch the look on someone’s face after a piece of feedback and know whether they absorbed it or just nodded.
In an async distributed environment, those signals vanish. What you get instead is text. And text, stripped of tone and body language, tells you almost nothing about whether someone is quietly struggling or simply heads-down executing.
A 2025 remote work survey of over 1,000 organizations found that only 30% of employees believe their manager is equipped to lead remote or hybrid teams, and only 18% have weekly one-on-one check-ins with their manager. That gap between what distributed teams need and what they are getting is not a technology problem. It is a signal-reading problem.
If you cannot read where someone is, you cannot lead them situationally. You just lead them how you prefer to lead, which is almost certainly wrong for somebody on your team right now.
Four Shifts That Actually Helped
Here is what changed the way I lead across a distributed team. None of it is revolutionary. All of it required changing habits I had built in a single-location environment.
Reading the texture of updates, not just the content. When a developer’s async update shifts from specific and confident to vague and hedging, that is a signal. Not that they are slacking – usually, that they have hit something they are not sure how to handle and do not want to surface it directly. In an office, that person might knock on your door. On a distributed team, they go quiet. I started reading updates for texture – what the writing feels like, not just what it says – and it changed how often I caught the need to shift from delegating to coaching before something stalled.
Structuring one-on-ones to surface the development level explicitly. I stopped opening one-on-ones with status updates and started opening them with a single question: what part of what you’re working on feels least clear right now? That question does not threaten anyone, and it consistently reveals whether someone needs direction, coaching, or just acknowledgment that they are on the right track.
Separating task-level development from person-level development. A senior developer on my team might be fully capable on one technology stack – D4, delegatable, hands-off – and completely new to a different one, which means they need direction on that specific task, even though they are experienced overall. Distributed teams make this harder to track because you are not watching work happen. I started keeping informal notes by person and task type, not just by person, which sounds like more work than it is. It takes two minutes, and it changes what you say on the next call.
Watching for proximity bias in the other direction. This one surprised me. I noticed I was over-directing the people in my Los Angeles office – defaulting to S1 directing because I could see them – while remote team members who actually needed coaching were getting S4 delegating by default because they were out of sight. Physical visibility was distorting my assessment of development level in both directions. The people I saw every day were getting too much of my attention. The people I never saw were getting too little. Neither was right.
What Actually Changed
The Center for Leadership Studies noted in their 2026 leadership trends research that leaders must develop a deeper understanding of their team’s performance readiness for specific tasks while considering personal circumstances that affect engagement and ability. That is not new thinking – it is the core of situational leadership applied to the distributed reality most managers are now navigating.
When I got more deliberate about reading development level across my team, two things happened that I did not fully expect.
First, people started bringing problems to me earlier because the one-on-one structure made it safe to surface uncertainty without it feeling like an admission of failure. Second, the people who were ready to work with more autonomy actually got it, which made them more engaged and reduced the communication overhead on both sides.
Neither outcome required new tools or a different organizational structure. It just required leading each person the way they needed to be led, which is what situational leadership has always been about. The distributed hybrid environment made that harder. It did not make it optional.
About the Author:
Daniel Haiem is the CEO of App Makers USA, a mobile and web application development company based in Los Angeles with a globally distributed team spanning multiple continents and time zones. He writes about leadership, building distributed teams, and the practical realities of running a modern tech business. appmakersla.com