Three leadership lessons (in theory)
Photo credit: Thomas T via Unsplash
I have learnt most about leadership from people and practice: from working for and observing people who are good leaders (as well as some bad leaders) and attempting to do more (or less) of what they do.
Most large enterprises attempt to supplement or accelerate this practical experience with theory: with leadership frameworks, principles and objectives which attempt to express what a good leader should be. These theoretical constructs exist in companies of all shapes and sizes: start-ups, global giants, banks, tech companies and consulting firms. They are usually well-intentioned, sometimes banal, frequently obvious - and generally less useful than what can be learned from seeing leaders lead.
However, there are some exceptions: in all the various systems I have come across, there are three things that have stayed with me. They all come from the same company (I’ll leave you to do the detective work on my CV to figure out which one) which, for a period, invested in research to discover what leadership attributes were predictors of future success, for the individual, for the teams they were part of and for the whole organisation. Naturally, the expectation was that, as aspiring or actual leaders, senior people in the company would attempt to acquire and embody these attributes.
I have tried to make the attempt, and hope that I have sometimes succeeded - especially as I believe that these attributes are particularly relevant for technical leaders: people who set direction, build capabilities and lead teams, and whose job also demands that they retain technical and professional expertise in their field.
The three attributes (in the version which exists in my head, and which may have become mangled over the years) are:
Tolerance of ambiguity: the ability to deal with situations which are uncertain and volatile, where information may be incomplete or misleading, and, nevertheless, to make decisions, to set direction, and to convey confidence to the team.
This is particularly relevant for technical leaders, who have to deal not only with the ambiguity that others can see, but the ambiguity that only they can see. For example, in the development of a new system, non-technical business leaders may imagine that time, effort and cost are uncertain, but that their intent is clear, while technical team members may imagine that requirements are uncertain, but their ability to get things done is not in doubt. The technical leader realises that the business leaders don’t really know what they want, and that newly formed technical teams have not yet established their practices and delivery rhythm. Everything is unknown, yet they must provide enough clarity and direction to get started, otherwise nothing would ever start.
To me, tolerance of ambiguity does not just mean adaptability and flexibility: it means a certain type of calm which it takes practice to acquire.
Influencing in the absence of positional authority: the ability to get people to follow you, to do the work that needs to get done, to take the decisions that need to be taken, whether they report to you or not.
This is particularly relevant for technical leaders, because such leaders never have everyone reporting to them that they need to get the job done: they are always dependent on others. This is true even if they are programme managers with large teams: whatever they are delivering will not get delivered without changes to business practices, the support and buy-in of business leaders and the work of their external partners. It is especially true if they are in architecture or strategy roles where, however grounded and practical their vision is, that vision will never be realised without the work of others.
To me, influencing in the absence of positional authority means more than charm, charisma and emotional strength: it means a level of confidence, good faith and trust which it is hard to build and easy to destroy.
Being the node in the network: the ability to be the person who ignores the lines on the org chart, breaks siloes, and reaches out to all the people they need to work with, wherever they may sit, making connections which last and leaving the organisation more cohesive than they found it.
This is particularly relevant for technical leaders, because it is rare for the change they drive to touch only a single part of the organisation. Even within the bounds of a technology organisation, any meaningful change will have an impact on software, on infrastructure, on security and on interfaces. And few meaningful changes will be confined to the technology organisation: most technical leaders will find themselves having to make a lot of new friends across the whole company. If they let themselves be constrained by formal structures, or worry too much about who they are ‘allowed’ to speak to, they will be lost.
To me, being the node in the network means more than being friendly, open and collaborative: it means having a healthy disregard for hierarchy, and an joy in making connections - in spotting when this person should be talking to that person - even when it has nothing to do with your work.
I have learnt to value these leadership attributes through people and practice as well as theory: they mean most when you see them in real life. But I have found that the tendency of theory to label things has been helpful: they are easier to spot, emulate and aspire to when you can give them a name. Not all management theory sticks, but these three concepts have stuck with me.
