Are You a Transactional or Developmental Leader?
In the fast-paced world of tech, leadership styles can make or break an organisation’s success. Are you driving growth with a developmental mindset or merely maintaining the status quo with a transactional approach?
One of the best books I’ve read recently is Gene Kim and Steven Spear’s Wiring the Winning Organisation. It distils many great leadership theories into clear, actionable concepts. At the very end of the book, in Appendices A and B, they talk about the differences between transactional and developmental leadership. This is something I think about a lot but didn’t know the precise terms for until reading these sections.
Transactional vs. Developmental Leadership
Transactional leaders focus on managing existing processes and resources (both people and tools) to maintain stability. They often rely on established procedures and immediate problem-solving. In contrast, developmental leaders emphasise continuous improvement and innovation. They design and enhance the “social circuitry” that allows teams to apply their creative energies toward new and better ways of working.
While the transactions may be many, the mindset is not sufficiently dynamic. Rather, the developmental approach requires designing and improving the social circuitry by which people can best apply their creative energies to find new and better things to do with their time and the resources they have, and by developing new and better ways to do so.
— Wiring the Winning Organization: Liberating Our Collective Greatness through Slowification, Simplification, and Amplification by Gene Kim, Steven J. Spear
This resonates strongly with me. I’m an avid believer in finding new and creative ways to achieve more by working smarter, not harder. I’m convinced that it doesn’t take much effort to identify areas for improvement in most organisations, especially those that build software. Code review processes, build pipelines, and test runs are common areas that can and should be optimised. But it doesn’t stop there - just take a look at the processes before and after these areas as well - requirements gathering, UI/UX design, system design, content sign-off, release processes, patching, vulnerability management, and incident management. There are countless areas where small tweaks can yield significant improvements.
Identifying areas for improvement is just the beginning though. To truly benefit, you also need to be willing to make changes — whether it’s your thinking, your processes, or your structure.
Practical Examples of Developmental Leadership
This is where being a developmental leader comes in handy. Having the belief that what you’re lacking is knowledge, not additional people or tools, allows you to optimise processes so that existing individuals and teams in your organisation can work smarter. This is how developmental leaders can reach for “new frontiers,” as Gene and Steven put it.
Instead of always looking to add more people or tools, developmental leadership focuses on enhancing the creativity and problem-solving skills of the current team first. By doing so, any new hires brought on board will integrate into a more dynamic and effective environment, rather than just continuing the same old patterns.
For example, in a previous job, our unit tests were starting to take too long. Granted, we had about 1000 unit tests, but 20 minutes was too long to wait. We refactored our tests to remove any dependencies between them (which shouldn’t have been there to start with) and were able to run them in parallel, cutting the time to run them down to under 5 minutes, which was far more manageable.
In another instance, we discovered that development wasn’t starting until UI/UX designs were fully complete. After some negotiation with our design team, we decided to start with some simpler wireframe designs that allowed some boilerplate development to start earlier while the finer, pixel-perfect details were being finalised. This allowed development to start earlier and even allowed for better quality outcomes as developers were able to provide useful feedback to the design team about how the feature felt once it was being developed.
Transactional leaders are more likely to reach for more resources, in whatever form they feel is lacking, to continue to work in the same manner as the existing setup. In some cases, it may require trading off one demand for another, but in many cases, it just means adding more to the equation.
There will also be cases where adding more people or tools is really the only option, but this should be the exception, not the norm. Consider the fact that adding more tools or people comes at a big cost - not just the initial financial outlay, but the costs of onboarding new people or incorporating new tools into your processes, not to mention the ongoing increased costs like salaries and maintenance.
For me, there is something incredibly satisfying about optimisation and improved efficiency. It’s a bit like solving a puzzle. It starts with acknowledging that things aren’t perfect and then mapping out your processes so that you can break them up into smaller parts that are easier to understand. You need to engage with the people involved at each step, and truly listen to what they have to say. Perhaps you can do more in parallel, or perhaps you can remove some redundant steps. Maybe you discover that information is missing at key points in a process, causing delays downstream. Experiment a little and be open to failing and trying again. You often learn more from your failures than from your successes anyway!
Reading Wiring the Winning Organisation has reinforced my commitment to leading with a developmental mindset. It’s not just about optimising processes and boosting efficiency; it’s about cultivating an environment where creativity and problem-solving thrive. This approach is now something I deliberately look for in companies I choose to work with, as it aligns perfectly with my own leadership philosophy.
So, would you say you have a developmental mindset, and are you applying that mindset at work? If not, what would need to be true for you to give it a go?