## Builder, Strategist, Coach + Rigour, Structure, Pragmatism Recently, I've been thinking about _style_ - in particular, my personal _style_ (or "approach") to the craft of engineering and building products with teams. (Inspired by senior leaders I look up to writing down their _leadership styles_) A lot is changing at the moment, and it's becoming more important to maintain a set of guiding principles that you can use to steer yourself in these uncertain waters. Importantly, one should note that these principals are probably only true at an intercept (and maybe have relevancy for 8-12 months). That is, this is subject to change. Anywho, let's dive into how I think about this. To describe my style, I've picked three words that **describe me** and the things I think I am good at, and three words that **describe the guiding principles** that I want to endeavour to apply to the three descriptions of myself. #### Note This builds on ideas I've had over the years, but as of October 2025 - this is most up-to-date and mature distillation of my personal style. Other Ideas: - 2022 - [When To Care About Code?](https://blog.shivan.dev/writing/post/when-to-care) - 2022 - [Working In Public With Teams](https://blog.shivan.dev/writing/post/working-in-public-teams) - 2022 - [Be Less Technical](https://blog.shivan.dev/writing/post/be-less-technical) - 2025 - [Map Making, Hiking & Software Architecture](https://blog.shivan.dev/writing/post/hiking-maps-and-architecture) ## Personas ### Builder At heart, I am still a builder. I enjoy the craft of software design & programming and the hands on creation of software. Visualising the way data flows through a system, thinking of the edge cases and ways something can break, grappling with challenging problems with multiple constraints and making trade-offs to balance delivery output with quality are some of my favourite things to do day to day. ### Strategist Hand-in-hand with my love of building, is my equal love of running the mental simulation of navigating a problem over the course of it's lifecycle. I think of this like taking a deep breath between stints of building. To me, being a "strategist" boils down to trying to be predictive of behaviour in complex systems, and nailing down tactics that can nudge system behaviour in a desirable direction. That is; not being solely occupied with the nature of the software systems. And instead, applying a systems thinking lens to the broader context - i.e. the organisation, the people, the relationships & the market dynamics. This "world model" is very interesting to me, and I get a deep sense of fulfilment when I establish a pillar or directive that serves as guiding when this complex world model changes. > I've been thinking about this actively since 2021/2022, I wrote [Attribution & Code](https://blog.shivan.dev/writing/post/attribution-and-code) > where I explored how complex systems fail. ### Coach Being a good builder and strategist are very central to the things that give me fulfilment, but the trifecta isn't complete without *this* factor. I endeavour to be an **enabler** of others who have their own styles, and their own self descriptions. The greatest satisfaction doesn't come from having done something alone. It comes from having played a small part in enabling someone else (or a group of someone else's) to get it done. I like to think of the "coach" aspect of myself with two sentences: - **In Service Of Another**: I am here, and I am available - how can I help *you* achieve the thing you're trying to achieve? - **In Service Of Us**: We are doing this together, how can _we_ develop and structure our thinking to achieve what we're trying to achieve? I strive to not frame myself as a coach or guide for the sake of doing so just because it's "the next step of my growth". Rather, I hope I can act as a coach *because* I have something that is genuinely valuable to offer, and flexible enough that I can offer it broadly. To sum it up, the ***coach*** version of me actively wants to commodify the ***builder*** and the ***strategist*** - by greatly increasing the impact others can have with my input, where it matters. ## Guiding Principles To "give it my all", I started to think about how do I can underpin these three personas with rules that I can lean on to guide myself. (lest I fall into the trap of doing it all haphazardly) The first rule came easily, because it was evident from doing this thought exercise. ### Apply Rigour Or more accurately (the irony of clarifying the definition immediately is not lost on me) - <u>thinking with rigour, instead of thinking lazily</u>. I have often surprised myself with how effective 15 minutes of careful, rigorous thinking can unstuck a problem when compared to a few hours of meandering around it. That's guiding principle #1 - catch myself being lazy with my thinking, and **apply Rigour**. If you're following along closely - your next question might be: > "Well how do you apply rigour? How do you decide when and how to 'think better'?" That neatly brings us to our next rule. ### Enforce Structure Building my own mental models (like this one!) are a large part of what I think will let me execute across different persona types effectively (*hopefully*). These form factors for applying principles help me "catch myself". Some examples: - *Rigour* applied to *building* may take the form of ensuring you build against a problem, and with controlled scope so that you Do Things That Matter. - *Rigour* applied to *Strategy* may take the form of grounding your strategic pillars in the mechanical aspects of day-to-day operations (i.e. how things are actually done), to ensure that you don't end up in an [Ivory Tower](https://en.wikipedia.org/wiki/Ivory_tower). But alas, not everything is neat and orderly in practice, and as such - we have my last guiding principle. ### Be Pragmatic Some rules are meant to be broken. Treating these frameworks and personas as gospel is likely a recipe for failure when faced with new challenges. Being flexible & adaptive in the face of complexity is of the differentiators when trying to quantify effectiveness across these personas. Ultimately, my forcing function for pragmatism is my own gut. Do I feel like I am shoe-horning something into a framework or structure? An over reliance on my own mental models when I feel adrift with a problem or situation is usually a good signal that I need to step back, *and apply rigour* pragmatically. >Ask myself the question - Is there a new mental model I need to develop, or an old one that needs updating? The intuition of when to ignore the structure is a muscle that I believe can be honed and improved through practice and some hard-fought victories. ## What's next? This articulation of my style gives me a starting point to seek out the work at the intercept of what I am good at, and what I enjoy. That's what I'm working on right now, at [Luno](https://luno.com) and on [nights & weekends](https://github.com/cishiv) Want to chat about this? Drop me an email: mshivanc [at] gmail [dot] com