Tech Leadership - A Process For Non Managers

TL;DR - Learn the fundamentals of a new skill really well; teach it to a colleague using a project; both of you run a workshop off the back of that project; resulting in one new advocate and 3-8 more people ready to experiment for themselves.

I returned from 10 weeks out of my job recently. Whilst I was away, a technique I’d piloted reduced some processing time from twelve hours down to just two.

This post explains a piloting/leadership process I’ve been through a few times; it works for me right now, as a non-manager with some freedom to find solutions. So far, I’ve used this process on: parallel processing in SAS; Windows scripting in SAS; XML; JavaScript unit testing and Incident Response methodology.

Leadership vs Management

If you weren’t aware, there is a very well discussed difference between leadership and management. I picked this up from my favourite motivational speaker, but a quick Google will tell you the same thing. Leadership seeks out change, taking risks and motivating people through passion and trust; a leader doesn’t require organisational authority. Management seeks out stability, maintaining the status quo and motivates subordinates because they are, the boss.

This isn’t saying that people who manage don’t lead, but that the two concepts are separate; doing one doesn’t mean you’re doing the other.

With leadership and management as separate concepts, we open up a great topic of conversation: what can you do to lead, when you don’t manage? This is a favourite topic of mine, because it turns out you can motivate people and instigate change even without being the boss.

Put in the Hours

A tech leader will often be the first person to get over the hump with a particular skill; they’ve mastered the basics and know enough to make the skill useful. Getting to this stage in a group with no experience of a technology is difficult. Be prepared to put in some serious work to complete all but the simplest of examples. Remember though, the leader doesn’t have to be a complete expert; just competent enough to boost a beginner’s understanding.

Pilot and Build The Advocate(s)

With a colleague, undertake a project using the new skill . It doesn’t have to be revolutionary in itself, but it should clearly demonstrate advantages of the new knowledge. Favour a project that is about to start or someone is struggling with, it will be more relevant to people in your organisation. They’ll also get company specific examples of how to use what you’ve learnt.

Invest lots of time explaining the new knowledge to the colleague you’re working with. Get this right and you’ll start to build an advocate who can help you answer other people’s questions. Full disclosure - getting more people who could help others, freeing up some of my time, was the first motivation for this process.

Demo It

When you’ve got the project working, make some noise about it! I like to have the advocate present at a department seminar. They have the deeper business understanding of what we’re trying to achieve, I’ll be there to add some more technical context. Selection of pilot project counts; if the project is typical for the department, the demo will show lots more people how they could benefit.

Workshop

This is where the investment in your advocate starts to pay off. Book a training room to fit eight for a day, around four weeks after demoing. Structure the workshop for the technical knowledge you want to get over, but encourage the advocate to build as much of it as possible.

I like a lot of slides that work with or without a presenter, mixed in amongst exercises that get progressively more complex. By this point you might still have a firmer grasp of the fundamentals than your advocate, but preparing materials for the workshop will help solidify the knowledge in their mind. Nothing motivates people to learn knowledge more, than the possibility of being asked questions on it!

Focus on creating a workshop that will get people over the hump. If you’ve ever spent a whole week getting something simple to work, you’re aiming to stop everyone else in the workshop also doing that. Get the ball rolling for your attendees, you don’t have to make industry experts in 6-8 hours.

At the very least, get the message out about what’s possible. I’ve had lots of users approach me with requests to help them, because they were made aware of possibilities through this process.

Finish and Repeat

Hopefully, you’ve produced at least one solid advocate for a technology, as well as 3-8 people ready to start experimenting for themselves! Be prepared for your attendees to need some support, but don’t be surprised if some suddenly overtake your level of knowledge. Don’t feel obliged to keep up with them, creating a network of knowledgeable people within a team is a great idea; being the sole point of expertise for a technology gets tiring very quickly.

Now repeat the process, find a new technology that will help your company and get putting in those hours! Note: for a group of around 50, with some churn in staffing, you should be able to repeat the process for each technology in around a year. Longer for smaller/more consistent teams or shorter for larger/more variable teams.