If you are:
a developer aspiring to become a software architect,
a software architect aspiring to become an executive,
an executive of any ilk looking for a different perspective on technology leadership,
a non-technical executive trying to partner effectively with technology,
or a technical executive trying to partner effectively with the business…
please, read on.
Preface
If I could take a step back in time and speak to myself 22 years ago - when I first started my professional software career - I’d have a lot to say to myself. In the interests of sharing my journey and experiences, I wish to present an essay series from that perspective.
If I could step back in time, this is how I’d want to tell my story; what worked, what didn’t work, and how people work. Most especially, I’d talk about what I had to change about my own mind and perceptions, and my own personal development both on and off the field to become effective, and how to become a respected voice.
I think it’s important to describe my journey in an honest and intimate way, and I don’t want this to feel like a cerebral read. I mean for this series to feel accessible to readers at all career levels. I share this openly with the reader because although yes, of course my career is framed within the context of my technical background, it has been the discovery-of-self within this context that has enabled the higher levels of function to which I have aspired, not my technical acumen, and to omit the personal side of my story would be to dishonour and diminish its contribution and causality to my professional development. My experience cannot be wholly unique; I hope at least some parts of this story strike a common, deeper chord.
I do not present this essay series with the intention of positioning myself as an expert – I don’t purport to be. I am also not intending for this series to be a complete compendium of all things with which a technology executive must concern themselves. This series is about street-smarts not book-smarts and is entirely sourced from my experiences from years of boots on the ground. These are the things that have mattered most to me as I’ve crafted myself and my teams. To the extent possible, I’ve tried to examine the various situations in which I’ve found myself from multiple dimensions from causality to effect and from people to technology, and will provide what I hope is meaningful guidance on how to prevent, recognise, or remediate difficult situations. Nothing herein is an attempt to be steadfastly prescriptive; feel free to incorporate what you like, and disregard what you don't.
On a final note, before getting started – I’m Australian, and as this is a personal essay I’m sticking with my native spelling. If you see an “s” where you’d expect a “z” it is likely not a spelling mistake.
How This Essay Series is Structured
Although a lot of the content in this series relates to how to manage development of a software platform, I’m going to begin this series with a focus on people – not just because this is a more broadly applicable topic, but because it will establish the tone for the essay on the ways in which I see that people, practices, and technology can integrate.
I’ll start first with leadership broadly and leading remotely, followed by sections on managing managers, managing engineers, and managing offshore staff. I’ll then change tack and get more deeply into considerations in managing technical debt and code quality. This will be followed by my thoughts on the architecture function of a software department and its role in managing technical debt, code quality, and functional extension of a platform. Not everything is about code, so I’ll zero in on some practices in Scrum and the relationship between the Technology and Product functions of the organisation. Finally, I’ll finish up with some thoughts on management of self as a technology executive.
- My Personal Journey
- Leadership, and Leading Remotely
- Managing Managers
- Understanding and Assessing Engineers
- Managing Vendor Resources
- Managing Technical Debt
- Code Quality, Entropy, and Bugs
- The Architecture Function is the Departmental Glue
- Platform Security and Sleeping at Night
- Lessons in Scrum
- Technology and Product as Partner Organisations
- Management of Self and Conclusion