What skills should I develop?

Recently I had the pleasure of spending time with some postdocs from my old university, helping those of them considering leaving academia to prepare for job interviews and generally think about how they can position themselves for success in their future careers. The conversation got around to the core skills that everyone should develop, and they expressed some surprise at the things I pulled out - the same reactions I've had from software engineers when having the same conversation - so I thought it worth writing them down. In no particular order, these are they.

Writing

Like it or not, we end up writing a lot and I've found this only gets more true with seniority. Whether it is the ever-growing mountains of email, papers laying out a plan or strategy, or presentations we're going to be writing something down and we need to be both good at it and fluent enough to knock out quality documents at speed. The brutal truth is that people will judge you if your writing is incoherent and / or full of spelling and grammatical mistakes - developing a writing style is one of many tiny ways we can position ourselves as competent and helpful.

Writing at speed is key. Workloads just keep growing and, assuming you want to stay ahead, you'll need to move "writing a strategic document" from the sort of task where you put aside a month of thinking time to something you just do between other work. In more detail, that means having a writing process (and being able to deal with a blank page) and getting a feel for what "good enough" looks like for the different types of docs. This only comes from experience so I always recommend practising writing to everyone, whatever career stage they are in. I write this blog and I've kept a one-post-per-month routine since 2016 as a discipline to force me to keep writing and thinking about how I lay out my thoughts. Is it annoying? Yes, of course. But, while there is definitely much room for improvement, I feel much more confident writing quickly these days. In fact, I wrote a post about why I write a blog a few years ago.

Presenting

Second in the list of skills people don't want to develop but really should, we have presenting. Presenting comes in two forms - putting forward an idea to a room full of people (ie some variation of speaking to a PowerPoint) and something more freeform (ie speaking off the cuff to a room of people). These are different skills and both need practising. You will, at some point, need to present and ideally the first time you do this you aren't trying to secure funding from the investment board or explaining to the trustees / shareholders your five year vision. Like any skill, this takes practise to improve.

Earlier in my career I ran a fortnightly Show & Tell event which was a low-stakes way of getting people to do presentations and we all learned a great deal of confidence and technique through this. Again, I wrote a post on why Show & Tell really helped some years ago and I stand by all of that.

Talking off the cuff can be harder to practise, but when you end up chairing meetings or just the most senior person in the room you can be sure people will look to you to fill time when other people are setting up. Ideally we learn to stop using crutch or filler words and then we just sound ... smooth? I gained experience by chairing Show & Tell for many years - I think there is a useful lesson there about forcing oneself out of the comfort zone to develop new skills.

Storytelling

This one underpins both writing and presenting. When we reach out to people, we are usually either conveying information or attempting to persuade them of something. In either case we, presumably, want them to listen and understand what we are saying so we need to learn how to be compelling. We need to be able to tell a sensible, well-structured story understanding our audience and how to reach them. This is a hard skill to develop and really only comes through practising the above, and getting feedback. Alternatively, you could run some Dungeons & Dragons. Seriously!

Reading

Rather obviously, if we want to get on we need to be able to read. However, less obviously, as one climbs the hierarchy the amount of reading just goes up and up. Whether it's board papers, strategy documents or yet more email the torrent never ends and I've found that the more senior I get, the more people think that long = good. Reading fast and accurately is a skill that like everything else needs developing. Of everything on here, I find this one hardest. I find focusing on piles of tedious papers next to impossible so I have had to develop various skills to take a run at it. For me, I find the best approach to maintain focus is to take notes - or ideally annotate the papers. I've been using a Remarkable as an alternative to unending printing. I need a semi-controlled environment, with no alerts or distractions and some appropriate music and if these are updates I need to add a narrative to make me lock into the information - ie ask and answer "why am I reading this?" beyond "because I have to".

You can also ask an appropriate AI to summarise papers but don't come to me the first time it gets it completely wrong.

Basic numeracy

Believe it or not, numbers are important. Sorry. Far too many people haven't developed basic mental arithmetic skills and this creates situations where they are pulling out calculators to add two numbers together. While this is slow, and burns time you likely don't have, there is a more important aspect to basic numeracy. We all need a basic feel for numbers to be able to spot mistakes in budgets or other detailed documents. We need to be able to see 143 x 6 = 1200 and immediately get that mental nudge that says something isn't right even if we don't know what "right" is.

Again, practice makes perfect. I typically add up my shopping as I walk around the supermarket and see how close I am when I scan at the till - this helps keep me fluent at juggling numbers in my head. As a child I learned my multiplication tables and some of the simple tricks for approximating sums. For example, here 143 is approx 150, and that multiplies easily so in my head I go 143x6 => 150x6 => 300x3 = 900 so I'm expecting something a bit under 900. Thus 1200 is immediately a warning bell that someone has math'd wrong or something isn't right in the spreadsheet formulae. I cannot stress enough how many budget errors I've caught this way.

Using your tools - Word / Excel

Computers are a pain, but they are an essential pain. Do we know how to use PowerPoint? Or Word? Do we know when we should be using each tool? Similarly, learn the keyboard shortcuts. They help so much, both within an application and also when moving information between them. Don't forget Excel - and learn to use simple formulae for managing data. If it helps, using formulae will make maths mistakes less likely!

There is an even more basic computer skill. Can we type fast and accurately - and ideally touch-type? There are "proper" ways to touch-type and ways to learn these techniques, however personally I learned to type via brute force playing online games in the late '90s where you communicated by text and either typed fast or stayed silent. This is no longer an option, so instead get writing those blog posts (from "writing" above).

If you're in Tech you're likely thinking this section is really easy buuuut I know a lot of software engineers who stick to code and don't really develop these basic skills then find themselves very slow when asked to do "normal" things.

These days I will argue that getting familiar with AI and interacting with a prompt in something like ChatGPT is also a core skill. This is more vague, and your workplace will no doubt have policies around this, but like learning Excel / Word / PowerPoint it comes down to having some idea of the capabilities of your fingertips.

Interview technique

Everyone sane hates interviews. I'll be honest, I hate being on the other side of the table too. However, we all need to learn the basics of interviews. Learn what a competency question is and the mystic secrets of STAR answers and we have a framework for preparing for an interview. Then we learn to talk off the cuff and learn to tell a story (both above!) and we can fill in the gaps. Then get a job you like so you don't have to do them very often...

And lo, this is my list of the absolute basics. When I go through this list with people, most folk start with "yeah that's really obvious" then some slow enlightenment dawns as we drill in to each point. There are specific skills here, and we need to develop them with some deliberate action. There are also books on most of these areas (while I list these as "basic" I'm well aware that they all have the potential to be incredibly skilled and I don't mean to diminish the experts in these spaces) and there are certainly a couple missing (eg basic design - that is making your presentations / documents look not-horrible). I also skipped anything about basic time management or leadership skills as, for me, these are beyond the absolute basics. In my experience, we all neglect at least one (and likely many) of these areas and this will create issues. So I encourage everyone to deliberately practice writing, speaking, reading, telling a story, counting, computering and interviewing. It's an incredibly basic list, and that is why we often don't think about them.

Failing upwards

Humans are fascinating aren't they? Everyone is different, behaves differently, thinks differently... and before looking at others we can spend a lifetime just understanding our own minds and thought processes. I try to spend a lot of time reflecting (often I then write those thoughts down here) and one area I find very interesting is how I learn. I blame my mother for this - she's a teacher and embedded in me an interest in the different ways people learn and understand.

Like many others, one of the ways I learn is experimentation around the boundaries. If I know how a system or a situation is supposed to work, I will sometimes see what happens one step beyond the stated limit. This is particularly useful with computers where one can watch log outputs and understand the complex system while modifying variables. However, it's also useful exploring options and testing perceived limits in the office. One of my first decisions as a senior leader was around a change in recruitment policy which nobody could work out how to sign off. I just ... did. Mostly to see if anyone would tell me I'd overstepped.

That was some five years ago, and as far as I know it was never reverted. Importantly, I discovered that the actual limit to my authority in this role was way beyond where people mentally placed it, and it moved the moment I challenged. So, armed with this knowledge, I then had a whole new space to explore what could be done.

Before moving on, I fully acknowledge that this is hardly sophisticated. While I like to think I've learned some more finesse over the years, "pushing boundaries" is what what two year olds do to try to understand the world. They push the parents to see how far they can go before getting put back in their place. But they do say we lose our inquisitiveness and bravery as we grow older...

Anyway, the reason for this post (other than outing myself as a 6' child) is reflecting this into the workspace. At work, I spend a lot of time developing people and a vital part of that is thinking about how they can push their own limits and move further forward. I've seen very smart people stunt their own growth through their fear of failure - unwillingness to push themselves forward and potentially be wrong.

This is problematic in general, but lethal if an individual's aspirations are to reach the highest levels of an organisation. At that point, there is no manual and you're thinking on your feet the majority of the time. You have to be able to see where you are being limited - by yourself, by the org processes, whatever - and seek ways to push through and improve the situation. For those of us in leadership, that means giving people the space to explore into an area where they might fail and then allow them to find their own way through, even if this isn't quite as clean or direct as we'd necessarily like. Clearly we should help where needed (after all, not all failures are equal) but it's no use constantly being training wheels as this will never build confidence. Worse, it might lead individuals to see the problem as "what makes Tom happy" rather than "what needs to be done to make this situation better" at which point I'm doing all the thinking and that is neither helpful nor sustainable.

Obviously what I'm talking about here is managing the fear of failure (not necessarily by removing all the consequences) and building a psychologically safe environment. If individuals can push the limit of what they can do, they can learn and grow. They can grow towards the next step on their career, and that means instead of having a report we've got a report who is behaving more like us - or at least our level. This is great for their growth, and infinitely more useful to us as leaders as when they've developed the skills we can spend less time managing them and more time leading.

So let's encourage our people to make themselves vulnerable, give them a space where that is safe and let them do things that are imperfect so they can develop the skills to be as perfect as us (ha). Let's encourage some failure?

A break in the routine

When I started as Director of Engineering at Macmillan, one of my objectives was to build a department which functioned without me. I wanted to be able to pull myself out of the operational day to day, empowering others to own those problems, while I focused on overall direction and wider concerns. This was always an aim rather than a hard goal - similar to the sysadmin end game of a fully automated system, it's something I would like to chase and I think I can get close, but I don't believe I will ever truly achieve.

Over the last year and a bit I've set things up to work this way. I've created core areas of my division, and put someone in charge of each of those spaces. I've empowered them to make decisions and own their successes, and I've carefully worked with each of these leaders to identify and remove weaknesses. There is still a long way to go, but I think we've made a strong start.

Why write about this? Well, I took last week off as leave (booked some time ago) and at the end of the week:

The Boss: How are you doing?

Me: Starting to feel better! After about four days asleep, I finally started to feel human again.

The Boss: Want another week off?

Me: Is this some kind of trap?

It wasn't a trap, so after a quick conversation I decided against looking that gift horse in the mouth and spent half an hour with my assistant going through my diary. The first week off was all planned, so that hadn't been a problem but this second week was a spur-of-the-moment thing. Surely it was going to cause all kinds of problems if I wasn't around?

Nope.

Of the week, there was an hour which absolutely required me and needed rescheduling. Which means ... what? This is the question I've been pondering for a few days. On the one hand, my ground-in desire to be needed and adored took a massive hit. Being basically superfluous is not good for the ego. On the other hand, this is exactly what I've been building towards. The department can survive without me. It can make decisions, move forward, solve problems, etc etc...

We've got a way to go. The wheels most certainly will not stay on the wagon indefinitely and the more forward-planning functions haven't been tested in this short term. Plus, of course, people are covering  some bits of my role and I shouldn't underplay their help. There is still plenty of need for someone in my position to keep things steady and move things forward - I don't think they can make me redundant just yet. However, I'm pretty pleased with the results of this (accidental) test and what it means for changing my day to day when I'm back.

To be clear - I'm not wasting my time. The bits that didn't need rescheduling were parts of the job where I'm providing support or oversight, and direct support for individuals. All this should be done, but I can certainly ask some questions about what happens if I dial it back a bit. That means less oversight, but perhaps we're ready for that? Then I can focus more on the work I'd be doing myself which isn't getting done. However, the nature of the job is such that my work is (supposed to be) much more strategic which naturally has a longer burn. If it's delayed a week, that doesn't create the same kind of problem as operational work stopping. Fortunately, this also means focusing in on the part of the job I particularly enjoy.

So, in summary I am very deliberately in the process of making myself operationally irrelevant and it's time to reboot my focus list. Is this ... is this what success looks like?

Learning at the right time

A few years ago I wrote about practical life lessons learned from playing Dungeons & Dragons. Many roleplaying systems handle the advancement of character skills with a level system. Over time your character gains experience and when you reach a set threshold you gain a "level", which is a collection of abilities and skills. Your choice of character class defines the set of abilities you gain.

So far, so simple. Many years ago, I was playing in a game in which we were forced to enact a dangerous escape in a spaceship. My character was the most competent pilot in the group, which meant he had enough knowledge for the ship to not immediately drop out of the sky. A few very lucky dice rolls, and a suicidal ramming of another ship later and we limped out of the gravity well, escaping to hyperspace in what was left of the ship. Much fun was had, and I gained a level - which I used to improve my piloting skills. Immediately AFTER I needed them.

That scenario never came up again, of course.

In my experience, this is very common in roleplaying games - spend the time learning skills for a scenario that has already occurred. It's also something I see all too often in work. People learning about change management immediately after a change, for instance, or about HR processes immediately after struggling through a difficult piece of casework. In technical delivery, learning how to use a frontend framework properly after releasing an accessibility nightmare onto the public or how to monitor your service on $cloudProvider after implementing their new and shiny features and deploying using it.

I've done this myself many times. So why is it so hard to look forward and learn skills ahead of time? The broad-brush problems should be very predictable. Technical strategy should show which skills are going to be needed in the next six months and longer. Moving into a management role makes change management and some kind of HR process work pretty much guaranteed. For me, there are a couple of problems at play.

Firstly, management work can be far too reactive. More than that - being reactive is actually very seductive as it feels far more productive. It isn't; but the feeling of being needed because you're putting out fires is highly addictive, especially shortly after coming from a discipline with a strong way of defining productivity such as development. I spent most of my early days after moving into leadership trying to force myself onto the front foot so I could actually think ahead instead of running around fixing problems and if I'm honest I didn't really want to make this change.

Secondly, even when there is a chance to look forward we often don't actually have a chance to act on what we see. I know that dedicating hours to studying various aspects of management and reading supporting books will help me, but I certainly don't have the time to do it without making serious compromises in what I have to deliver or just consuming my non-working time. Neither of these solutions are acceptable. Part of this is about having any spare time during the working day, and to study there is a need for some quiet reflective time which is particularly difficult when everyone is trying to reach you for whatever Opinion is needed at that time. But also, I need to give myself permission to study and acknowledge that this is part of the job.

What should we expect from leadership? There are times of difficulties and change, but in general I think it's reasonable for people to expect some form of considered development from their place of work. In these enlightened times, we've moved past "bring them in and use them up" as a management style (insert correct cynicism here) and certainly in a knowledge-based job like development, constantly building skills is essential for an individual's future, as well as of benefit to the organisation. Not to mention retention and in-house skill development is far more cost effective than hiring and firing in this sector. This leads straight to an obvious point - we should be building organisations which value learning, and that means making time and expertise available. For those of us who talk about taking on apprentices and other "learning" roles (which done wrong can destroy someone's career as it starts) the point is that much stronger.

So what is the key thing to learn here? Well, it's important to look forward rather than backwards when deciding what to study. Beyond that, it's a well-rehearsed refrain at this point. Scanning the horizon is fundamental to a successful leadership role. Acting on what one sees there is essential. Both of these require time and carving out time is hard. However there is an extra thought here - giving oneself permission to find and spend time on learning is an important step, and being able to do so is part of the organisation's culture. This is important for anyone, but especially in a position of leadership where one can have a strong voice setting that culture and enabling others to grow.

Magic happens

I use the phrase "magic happens" quite frequently when giving an overview of something technical. For example, if I'm trying to explain the concept of the client / server model I might talk about how a web request is routed from a client to a server where magic happens and some HTML is returned as a response. This isn't supposed to be condescending - it's a shorthand for "this is a black box where something else is going on, but talking about it will draw our focus away from the thing we're talking about here". Unremarkable, but the phrase got stuck in my head the other day and while turning it over it made me think about how learning has changed for developers.

When I was starting as a developer I hated magic. I dug into these black boxes and learned a great deal around the problem until I had a good working knowledge of hosting, networking, etc etc. At the time, you pretty much had to learn this stuff to get a decent local dev environment running. This was before frameworks like Rails made it relatively easy to run up a complete environment with a couple of console commands, and a long time before cloud hosts like Heroku allowed the application to be run in the wild with little more effort. Consequently, there was a huge technical barrier to entry for those learning to program. A barrier that now much lower.

This is in no way a post about how the kids today have it easy, or any other such nonsense. It's a musing on what new developers are learning and what that means for the older generation when it comes to mentoring the next generations (amusingly, my spellcheck wants that to read "tormenting the next generations"). It is now conceivable to have reasonably experienced developers (ie not juniors) who are highly competent, having worked in Rails environments pushed to cloud hosting, who have never had to worry about how anything under that works. No knowledge of linux, networking or other things from the sysadmin world. This has a significant impact on debugging problems and system design, which has a knock-on effect on production costs, maintenance and out of hours support rotas.

On the other hand, and before us more experienced folk feel smug, this focused learning means these developers are likely far better at the core language than we were at the same level of experience. If true, they will be better at their jobs than we were (for a narrow definition of "better", granted). However, it will also stunt career progress as a developer wanting to take the lead in designing or building a system generally needs a wider understanding of the subject area. Skills I learned early on were far less useful while I was a mid-level developer but that knowledge was pretty much essential when I moved into more senior work. This is a key area where our responsibility as more senior people comes in - it's not just juniors who need space to learn things.

In my experience, there is another benefit of this focused learning. Good developers who have learned their particular subject in-depth are aware of the edges of their knowledge. They are aware where, for them, "magic happens", and are capable of explaining that well. I'm not advocating siloed thinking or working, but learning how to define and articulate your problem space is an important skill as a developer - one that people who know everything (sigh) sometimes fail at. It's particularly helpful when discussing work and solutions with other, non-technical disciplines such as product and delivery managers.

Also worth remembering is that we learned around the subject out of necessity and back then it was much easier to get a really solid overview of everything. "Everything" has context of course - how many of us studied machine code, chip architecture and instruction sets, memory rings and so on? Some did, of course, but by no means all. Our window of learning took in what we needed. These days there are many more layers of abstraction in the hosting world as well as many more layers of complexity with SCSS processors, Javascript frameworks and transpilation, and on and on and on. The world today is far more complicated and while we may (MAY) have kept pace with new innovations, that is not the same thing as learning it all at once - especially since change continues to happen.

I have a feeling we're going to be seeing a lot more magic happening as the industry matures. We'll have more black boxes and more abstraction of important concepts - indeed making use magic components is a core part of cost saving strategies. Why on earth would you run up your own virtualisation environment when services like Linode exists, for instance? We are going to need to be increasingly aware of how we talk about technology - not just to those outside our discipline, but to those inside too. We're going to need to put an increasing amount of effort into making sure the next generation can get on - either by learning what they need around the subject, or by shaping our organisations to celebrate the new learning.