Tips on leading without authority

Having had the opportunity to lead software engineering activities before having ‘Lead’ in my job title, here are some things I found challenging and how I approached those challenges.

Firstly, software development provides a great culture for leading without authority, as it’s a given that the entire product can’t be delivered by an individual and therefore you must work together, so if you’re an engineer looking to develop leadership-related skills you’ll find it hugely beneficial to take the plunge and take on some extra responsibility/accountability for a deliverable to see how it goes!

Photo by Blake Wheeler on Unsplash

Organisational culture

• You might already know some business colleagues (e.g Product Owner), but your network will widen (e.g Marketing, Legal) and people will have their own perceptions and expectations of you when you are introduced to them. Irrespective of your prior experience, find some initial areas where you can bring demonstrable value to gain trust in the group; you’ll need this later on no doubt! A couple of things here: get your actions from meetings done on time and if you just don’t know something, it’s better to be up-front with this than to either remain silent or make it up!
• Another quick-win can be to ensure that all actions/tasks are assigned to someone in the group by the end of meetings. For example, during meetings discussion points will tail off and identifiable actions missed, this is a good opportunity to raise those tail-ends and be seen as a having an eye for detail (this can, in some but not all circumstances, build your trustworthiness in the group), you don’t need any knowledge or context to get this done either.
• Read all pre-meeting material, so that you can make the most of the face-to-face time (either physical or virtual!). Not only will it mean you shouldn’t feel side-swiped by any agenda items but it also gives you the chance to see whether you can add value by assisting others. For example , if your Product Owner is accountable for signing off something highly technical, you can take an educated guess that they might turn to you in this instance, being up-front and messaging them beforehand the relevant evidence/justification/reasoning (whatever the situation dictates) will go a long way to boosting your standing in the group.

Reliance on personal technical ability

• If you are considering taking point then you’ve probably got some experience providing estimates and understanding why these are always wrong, so I’m not going to teach you to suck eggs but just be mindful that even though you might not be taking all the responsibilities of a lead, you will have less time for hands-on delivery and you might not be writing all (or any!) of the code yourself. While previously you might have started earlier or finished later on a couple of days, to get something over-the-line, you can’t fall back on that now. Focus on your relationship, and split of responsibilities, with your Product Owner for the benefit of the team as well as activities you can perform to deliver sooner (e.g make sure acceptance criteria are updated as requirements change, write that ‘How To’ guide on something you think might trip a fellow dev up later on, prepare the test/canned data in advance, be disturb-able and quick in response to colleague queries).

Listening and being heard

• To get the most out of the experience, be open to leading on areas outside your deep technical experience (e.g lead a feature with UI components if you feel safest with back-end technologies or vice-versa if you’re a front-end wizard). This will make it easier to focus on developing active listening skills and clear comprehension because you can’t fall back on doing it yourself, the only path is to work together and make sure everyone has a common understanding and trusts their peers to deliver collaboratively.
• On being heard, depending on your existing relationships within your team, you may feel uncomfortable being asked for ‘final say’ during conversations around unresolved unknowns, large complexity or choosing an approach from multiple options. These are points in time where ‘the room’ expects you to be heard and may be waiting for you to make a tactical choice, I’d advise a clear description of any constraints, caveats and supporting information that forms part of your view towards a decision, enabling others to see that you are adding value to the conversation and creating space for you to ‘be heard’ if/when you need to be further down-the-road.

Motivation

• Previously you might only have been concerned with your own motivation, and found strategies to assist in this area, but now you need to think about how to initiate and maintain peer motivation. This will vary in magnitude depending on the individuals around you and the existing relationships you have but there’ll always been times when motivation dips (we are all human after all!).
• There are two levels at which it might be easiest to influence motivation without hugely changing the dynamic of your existing relationships: big picture vision and hands-on assistance. Reiterating the big picture vision for a colleague, whether it’s customer value or purely technical quality benefits, might reignite/trigger their self motivation to kick in. Alternatively, arranging a pair programming session and putting your laser-focussed developer hat on might increase peer motivation through knowing they aren’t alone and seeing someone else wrestle with the problem (it’s also likely that by stepping back slightly to explain the issue to you, they are then in a head-space to see it differently and the solution comes to them naturally— this is not about solving the issue for them or taking the issue away to fix yourself!)

So there we go, some tips and tricks to adjust to bearing some technical lead responsibilities without the authority on paper. Hope you enjoyed the read and found something to take away and action in your own portion of the world, see you again soon!