Technical Leadership Katas - 002 Basing on credibility

Introduction

For lots of us our tech roles feel vocational. We have that moment where we realise that we can actually get paid for doing the things we enjoy such as coding, tinkering with servers or designing things.

So when we consider management it is often viewed as a fork in the road on our careers.

• Route one - do we become more technical, exploring routes like architect or "Senior" {insert role her}, Principle Consultant those kinds of things.

• Route Two - do we become managers. Scaling that hierarchy. Leading people and managing their mindset.

The problem with this is we tend to take approaches of reduction based decision making in deciding which route is right for us. As a result, route one and route two become:

• Route One - "I can continue learning and get better at {insert skill here}"

• Route Two - "I don't want to manage people's holidays"

This kata is here to debunk that myth and provide an exercise around how you can base your technical leadership on technical credibility. Tips to continue your technical development whilst acknowledging that you'll have further human responsibilities.

Past experience and how it played out

Around 12 years ago I was interview when asked where I saw my future going and if I wanted to lead people. Which I answered with a definite NO - I just wanted to code.

Fast forward and things look a little different now. Much of my work involves management in some form, whether that be decision making or developing our existing engineers.

But...I always wanted to remain credible. I didn't (and still don't) want to lose those technical skills. Being an engineer whether that be in Software Development or more recently platform engineering was part of my identity.

For a period of time I noticed my engineering work declining. I also felt those pangs of not knowing certain aspects - I remember one specific time when I'd not refreshed my Java skills and seeing one of our team had implemented a function using Lambda Expressions and I hadn't encountered that type of syntax before.

Don't confuse that feeling with ego. That feeling is one of "How can I lead people if I don't have credibility"

At that point I put in to place some action to ensure I had a level of knowledge that I was comfortable with around the tools/languages/practices being utilised.

Kata instructions

Step 1

Admittedly your time will be more restricted. Create a table to highlight areas where you want to be Aware and Efficient.

This will help you highlight where time needs to be spent. Efficiency will take longer time to achieve than awareness.

This will be a working document and change over time. If you do it in markdown it means you will be able to add links to items.

Here's an example below

Step 2

Moving in to leadership means becoming comfortable with your calendar no longer being your own. People will need your support and that means you will have slots in to provide that support in whatever form it takes.

Counteract that with calendaring your focus time. Some examples I've seen work are 1 hour before things get "busy" or "1 hour after lunchtime", "1 hour at the end of the day". You'll know what is the best time for you (your mindset) and what is realistic for your working environment.

IMPORTANT Make sure to highlight your focus time as BUSY in your calendar software.

Step 3

Pick a project. Tapping in to the "Purpose" aspect of Dan Pink's great book called Drive we all need a purpose to a work. If you said go new Java 16 language features without giving a purpose you'd likely have a peak of motivation but then it would wane.

In step 3 identify a project that you could code, research, create that will improve your life and align that project with your "Efficient" topics.

Some candidates for this might be automating things that take your (or the teams) time up, researching and implementing new processes.

REALLY IMPORTANT Do NOT pick up a project that should be implemented by one of the teams. Everyone hates a leader that goes into their coding hole and then emerges with a brand new tool or process that they suddenly expect people to use.

If anyone wants advice on this one please do drop in the comments!

Step 4

Earlier steps highlighted that time is now at a premium so you need a few cheats when it comes to staying up to date on technical practices and tools.

Newsletters can be one of those cheats.

Using your aware/efficient table - Sign up for a few newsletters from the following link.

I particularly like DevOps Weekly and my favourite cheat is the ThoughtWorks Tech Radar.

Step 5

Identify which calendar slots you'll dedicate on working on your project and which ones you'll use to update yourself via your newsletters.

Submission process

The following write-ups should be recorded in your GitHub repo within the corresponding kata directly.

1. Your Aware/Efficient markdown file

Create a file called PERSONALDEVELOPMENTFOCUS.md and create your aware/efficient table.

2. Your project

Create a markdown file that identifies and explains the project you'll be working on.

3. Your focus time

Create a markdown file called FOCUSTIME.md that outlines your calendar plan and how that time will be spent. Apply the information from this file to your personal calendar.