|
| 1 | +--- |
| 2 | +title: The Outward Mindset: How One Question Changed the Way I Think About Leadership |
| 3 | +authorName: Salipa Gurung |
| 4 | +authorAvatar: https://avatars.githubusercontent.com/u/53458341?v=4 |
| 5 | +authorLink: https://github.com/Salipa-Gurung |
| 6 | +createdAt: August 06, 2026 |
| 7 | +tags: |
| 8 | +banner: https://blog.jankaritech.com/src/assets/PythonCopyFileWithShutil/images/python_copy_file.png |
| 9 | +--- |
| 10 | + |
| 11 | +When I started reading _The Outward Mindset_ by the Arbinger Institute, I expected to learn more about leadership and teamwork. What I did not expect was how much the book would challenge the way I look at my own interactions with people. |
| 12 | + |
| 13 | +This book made me put it down and just sit there for a minute, because it asks a more uncomfortable question than most leadership advice bothers with: how am I actually seeing the people around me? |
| 14 | +Not managing them. Not communicating with them. Seeing them. The book puts it almost as a challenge: am I seeing the people around me as people, or am I only seeing them based on how they affect mu goals? That question applies to nearly every workplace interaction I could think of: how I collaborate with teammates, how I handle disagreements, how I approach problems that aren't strictly mine. |
| 15 | + |
| 16 | +That distinction sounds small when you first read it. It didn't feel small by the end of the book. So here are my honest, somewhat unfiltered notes on what stuck with me. |
| 17 | + |
| 18 | +### Mindset before Behavior |
| 19 | + |
| 20 | +The book opens with a model that's almost too simple to take seriously at first: mindset drives behavior, and behavior drives results. In many workplace, when something is not working well, the first response is often to change processes. We set the target results, then try to engineer behaviors directly through KPIs, mandates, tighter process. Arbinger's argument is that this skips right past the thing that's actually doing the work underneath: mindset. You can tell someone what to do all day long, but if the way they see the situation hasn't changed, the behavior doesn't hold. The book made me reflect on something important: a process change alone does not always create lasting improvement. Real improvements happens when people understand its purpose. |
| 21 | + |
| 22 | +### Push vs. Lead: Two ways to try to change people |
| 23 | + |
| 24 | +There's a distinction early on between what the book calls the Behavior Push Approach and the Leading-With-Mindset Approach, and it landed for me harder than I expected. |
| 25 | + |
| 26 | +The push approach is the default almost everywhere: tell people what's expected, train them on it, reinforce it, measure it. The book pictures this almost literally as a wall, you're pushing behavior as a target, but the current mindset is standing in the way, so the push either stalls or the change doesn't stick once nobody's watching. The leading-with-mindset approach flips the order. Address how people see the situation first, and the behavior tends to follow on its own, because now it actually makes sense to them. |
| 27 | + |
| 28 | +This pattern is common when teams introduce new ways of working. A new tool, new review standard, or new process may be adopted as quickly at first because everyone's been told to. However, the change often fades over time when the underlying mindset has not changed. the instruction changed, but nothing underneath it did. |
| 29 | + |
| 30 | +The book also highlights a more subtle version of the same problem, teams that say the right things in meetings, follow processes as expected, and appear to be working well together, but still struggle with genuine collaboration. On the surface, the behavior checks every box. Underneath, people are still protecting their own turf, quietly blaming each other, treating teammates as things to get around rather than people to work with. Behavior is the symptom. Mindset is the source. That reframed, for me, what leadership development is even about, it can't just be teaching people what to do, it has to touch how to touch how they see. |
| 31 | + |
| 32 | +### The Shift from "Me" to "Others" |
| 33 | + |
| 34 | +Here's the core of the whole thing, stated about as plainly as it can be: |
| 35 | + |
| 36 | +An inward mindset says: I focus on _my_ results, and other people become objects in relation to that: vehicles I use, obstacles I blame, or irrelevance I just tune out. Others don't matter like I matter. A teammate becomes the person who is blocking our progress. A request becomes another task to complete. A disagreement becomes something we need to prove ourselves right about. |
| 37 | + |
| 38 | +An outward mindset says: I focus on _our_ results, and other people stay people: with their own needs, goals, and challenges that I actually factor in. Others matter like I matter. Instead of only asking: "How can I finish my work?", we start asking: "How does my work affect others?", "What does this person need from me?", "How can we achieve a better outcome together?". |
| 39 | + |
| 40 | +What I liked is that the book doesn't turn this into a morality lecture. It's not saying inward-mindset people are bad. It's saying that under pressure, deadline looming, inbox full, your own metrics on the line, almost everyone drifts inward without noticing. A teammate's blocker starts to feel like an inconvenience to you rather than a shared problem to solve. |
| 41 | + |
| 42 | +This shift does not mean ignoring our responsibilities. It means understanding that our success is often connected to helping others succeed. |
| 43 | + |
| 44 | +### People, Not Objects |
| 45 | + |
| 46 | +There's a related idea in the book that I think deserves its own space, separate from the inward/outward split itself: the difference between seeing someone as an object versus seeing them as a person. |
| 47 | + |
| 48 | +Nobody consciously decides to treat coworkers like objects. It happens quietly, through categorization. A colleague becomes "the person who's slowing down my ticket". A customer becomes "a request in the queue". A manager becomes "the person who assigns work". In software specifically, it happens fast: a developer becomes "the person who introduced the bug", a colleague becomes "the one who delayed the release", a manager becomes "the person who keeps moving the deadline". Once someone gets rduced down to their function relative to you, it's a lot easier to justify being annoyed with them, or blaming them, or just tuning them out. When we see people only through these labels, we lose sight of the fact that they are individuals with their own experiences, pressures, and perspectives. |
| 49 | + |
| 50 | +Seeing someone as a person does not mean avoiding accountability or accepting poor outcomes. It means approaching situations with understanding before making assumptions. A problem becomes something to solve together rather than something to blame someone for. |
| 51 | + |
| 52 | +### The S.A.M. framework: A practical way to apply the mindset |
| 53 | + |
| 54 | +One practical framework from the book is S.A.M.: |
| 55 | + |
| 56 | +**See others, Adjust efforts and Measure impact** |
| 57 | + |
| 58 | +See others means genuinely trying to understand what people actually need instead of assuming we already know. Adjust efforts means changing our approach based on that understanding. Measure impact means holding yourself accountable for what your work actually does for other people, not just whether you personally got something done. |
| 59 | + |
| 60 | +I like this framework because it's usable, not just inspiring. You can run it in a one-on-one, a retro, a code review. Did I actually understand what this person needed before I responded? Did I adjust based on that, or did I just do what I was already planning to do? And the sharper question, am I measuring whether my work actually landed for someone, or just whether I shipped it? It's easy to say "I closed the ticket".It's a lot harder and more honest to ask whether closing it actually made things better for others. |
| 61 | + |
| 62 | +For example, as developers, we often think about whether we completed a feature or fixed a bug. But another useful question is: |
| 63 | +"Did this make someone else's work easier?" |
| 64 | +A piece of code can technically work and still create problem for the next person who has to maintain it. Completing a task and creating value for someone else aren't automatically the same thing, and this framework is really just a way of not letting yourself forget that. |
| 65 | + |
| 66 | +### A Question I Want to Remember |
| 67 | + |
| 68 | +After reading this book, I started paying more attention to one question: |
| 69 | +**Am I seeing this person as a person, or as an obstacle?** |
| 70 | +It is a simple question, but it changes the way you approach conversations. |
| 71 | + |
| 72 | +Before responding to a disagreement. |
| 73 | +Before writing a review comment. |
| 74 | +Before assuming someone made a mistake. |
| 75 | + |
| 76 | +Taking a moment to understand the other person's perspective can completely change the outcome. |
| 77 | + |
| 78 | +### Don't Wait on Others to Go First |
| 79 | + |
| 80 | +There's a small diagram in the book that carries more weight than its size suggests: two people stuck in mutual inward mindsets, each waiting for other to move first, produce nothing but a standoff. The outward move breaks that and the key detail is that it's unilateral. You don't need the other person to go first. The moment one side actually starts seeing the other as a person, the whole shape of the interaction shifts, even before the other person has caught up. |
| 81 | + |
| 82 | +This might be the most quietly radical idea in the book. We tend to treat mindset change as something that needs reciprocity, I'll be more understandig once they are. |
| 83 | +Arbinger basically says that's the trap itself. Somebody has to go first and you're the only mindset you actually have control over, so it might as well be you. |
| 84 | + |
| 85 | +This was the part I found personally hardest. In leadership it's tempting to think, I could do better here if that team communicated more clearly, or if people were more responsive or if others just took more ownership. The book quietly takes that excuse away. I doesn't mean going soft on real performance problems. It means starting from a different question: am I actually helping the people around me do their jobs better or am I mostly trying to get what I need out of them? Not a comfortable question. Worth asking anyway. |
| 86 | + |
| 87 | +### Final Thought |
| 88 | + |
| 89 | +The line that's stayed with me most isn't a technique at all. It's the closing thought the book leaves you with: |
| 90 | + |
| 91 | +**Inward mindset people and organizations do things. Outward mindset people and organizations help others to be able to do things.** |
| 92 | + |
| 93 | +For leadership specifically, that's worth sitting with longer than it takes to read. It's the gap between managing a team so tasks get checked off and leading one so people are actually equipped to do good work. |
| 94 | + |
| 95 | +This isn't a long book and it's not trying to dazzle you with a new framework or trendy jargon. It offers something quieter: a different way of thinking about performance as something that comes out of how people experience each other, not just what gets produced. |
| 96 | + |
| 97 | +If there is one thing this book changed in the way I think about leadership, it is this: leadership is less about being the center of the story, and more about helping other people suceed in theirs. This book is worth reading for anyone in a leadership role who feels that the next improvement may not come from another process or tool, but from changing the way they see and work with the people aroud them. |
0 commit comments