Roles & Responsibilities of Software Leadership

Java? Backend? “Senior Engineer”? CTO? A formula for leading software projects.

My last blog was nearly 18 months ago, and remembering where I was then it feel like a generation has passed. Then I was a budding Data Engineer with a couple of minor projects; interested in everything and involved in too much. Now I’m leading a team of twelve of the most impressive professionals I’ve ever worked with, solving a very clear problem that will define the make of our FinTech unicorn.

Doing justice to the responsibility of leading a team selected from the world’s best universities, poached from software’s most recognisable brands, connected from four continents, above the 90th percentile of a professional IQ test and tasked with building the future of Financial Technology, has lead me to dedicate a substantial number of mental clock cycles to optimising leadership. Two books have been particularly influential:

• “The Art of Action” - Stephen Bungay
• “The Five Dysfunctions of a Team” - Patrick M. Lencioni

Leadership is an art, which Bungay distinguishes from a Science as an innately human skillset which the species is incapable of positively correlating with time. Julius Caesar was subjectively a better leader than many - probably the majority - of 21st Century leaders. But you would be pressed to contrast his ability of a military general and imperial leader with that of, say Elizabeth I, known more for her lasting influence as a cornerstone of protestant Britain than her military prowess. Was Churchill more powerful than Mandela? Or Ghandi more influential than Jobs? My conclusion is that leadership is vitally contextual and frustratingly immeasurable. But where does that leave a mathematically oriented programmer looking for the emotional equivalent of Dijkstra to chart the shortest path for a flock of individual geniuses to dovetail towards the successful conquest of European FinTech?

With the great help of Bungay, I have concluded there are six key responsibilities which must be exercised with different weights during the lifetime of a software project:

1. Directorship
   • Interpreting the high level problem and creating strategy
   • Frequency: Periodically requires review
2. Leadership
   • Inspiring people to move harmoniously together
   • Creating an effective team
   • Multi-directional: you can lead downwards, upwards, inwards & outwards ¹
   • Frequency: All the time, every day
3. Management
   • Administering groups of people
   • Ensuring tasks are clear, ordered and prioritised
   • Reporting upwards and keeping individual contributors (ICs) aligned with managers
   • Frequency: constant at varying intensities
4. Product
   • Understanding users & customers
   • Creating solutions to business problems
   • Frequency: constant
5. Architecture
   • Designing solutions to business problems
   • Building scalable & efficient processes
   • Frequency: periodically requires review
6. Engineering
   • Implementing code that will last
   • Running & maintaining systems
   • Frequency: constant at the same intensity

To match these responsibilities, I have identified five roles that span the majority of the web of job titles one can find in software, and mapped them to the above responsibilities in order of priority:

• Director/CTO
  1. Directorship
  2. Leadership
  3. Management
• Product Owner / Product Manager
  1. Leadership
  2. Management
  3. Product
  4. Architecture / Design
• Lead Engineer
  1. Architecture
  2. Leadership
  3. Product
  4. Engineering
• Senior Engineer
  1. Architecture
  2. Engineering
  3. Product
• Mid / Junior Engineer
  1. Engineering
  2. Architecture

The emphasis here is the order of priority. You will notice that Engineering is bottom of the priority list for a Lead Engineer. This might sound strange, but is in fact the defining feature of that role as a Lead, not a Senior. If the Lead IC prioritises their own delivery over the Architecture of the system or their influence over their team, you will find beautifully efficient and masterfully crafted modules of code integrated into a platform that either feeds data seamlessly into the hopelessly thrashed and poorly optimised downstream modules, or that are forever condemned to their cell within an impossibly rigid architecture. In contrast, it is the role of the Senior Engineer to be tasked with the most advanced algorithms and optimisations of the platform, and deliver the breakthroughs and gold-plated modules that form the bedrock of innovation within the platform.

Likewise, you will notice that Management takes a higher precedent than Product or Design for the Product Owner. In a similar vain to their code-committing counterparts, the highly creative Product Owner with their Russell-Group business degree may spend their days neglecting the administration of their team in favour of the perfect wireframe mock-up with the accessible colour scheme, or the cost-optimised architecture diagram that masterfully unshackles the organisation from the chains of their old licensing fees. This PO will have the jaws of the board on the floor talking through their plans for the platform that flaunts the competitors and delivers a return before it has passed its Alpha test. But the pomp and circumstance will be short-lived when the engineering staff leave for “better growth opportunities elsewhere”, the project team present a purchase order for a 2 year license that cannot be used for the next 12 months, and the CFO finally pulls the plug on funding because the promise of a 20% RoE within 6 months has not been satisfied and the agile iterative roadmap does not sufficiently demonstrate a path to profitability.

My thoughts are taken from projects built, lead and implemented by me with my head in code racing towards the next relay point, only to find the team had decided to run a different race, and from participating in teams with no clear purpose & direction, all happily tapping away on whatever project pops into their head as they order their morning matcha latte for months on end. I’ve now been given the opportunity to tie all this together and see if the probability of success in this abstract art of designing and building software that people actually care about really can be improved by sparing a few bits or fetch operations for the widely used term: leadership.

I’ll let you know how I get on.

1. Taken from another recommendation: “Co-Active Leadership: Five Ways to Lead” - Henry & Karen Kimsey-House ↩