fix typos

Author: Salipa-Gurung

src/assets/TheOutwardMindset/the-outward-mindset.md

@@ -1,5 +1,5 @@
 ---
-title: The Outward Mindset- How One Question Changed the Way I Think About Leadership
+title: The Outward Mindset - How One Question Changed the Way I Think About Leadership
 authorName: Salipa Gurung
 authorAvatar: https://avatars.githubusercontent.com/u/53458341?v=4
 authorLink: https://github.com/Salipa-Gurung
@@ -17,17 +17,17 @@ That distinction sounds small when you first read it. It didn't feel small by th
 
 ### Mindset before Behavior
 
-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.
+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 workplaces, 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 Key Performance Indicators (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 happen when people understand its purpose.
 
 ### Push vs. Lead: Two Ways to Try to Change People
 
-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.
+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.
 
 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.
 
-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.
+This pattern is common when teams introduce new ways of working. A new tool, new review standard, or new process may be adopted 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.
 
-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.
+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 change how they see the people around them.
 
 ### The Shift from "Me" to "Others"
 
@@ -45,7 +45,7 @@ This shift does not mean ignoring our responsibilities. It means understanding t
 
 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.
 
-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.
+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 reduced 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.
 
 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.
 
@@ -57,11 +57,11 @@ One practical framework from the book is S.A.M.:
 
 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.
 
-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.
+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.
 
 For example, as developers, we often think about whether we completed a feature or fixed a bug. But another useful question is:
 "Did this make someone else's work easier?"
-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.
+A piece of code can technically work and still create a 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.
 
 ### A Question I Want to Remember
 
@@ -79,19 +79,19 @@ Taking a moment to understand the other person's perspective can completely chan
 
 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.
 
-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.
+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 understanding once they are.
 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.
 
-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.
+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. It 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.
 
 ### Final Thought
 
-The line that's stayed with me most isn't a technique at all. It's the closing thought the book leaves you with:
+The line that has stayed with me most isn't a technique at all. It's the closing thought the book leaves behind:
 
 **Inward mindset people and organizations do things. Outward mindset people and organizations help others to be able to do things.**
 
 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.
 
 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.
 
-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.
+There is one thing this book has changed about 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 succeed 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 around them.