The T shape

 

The T shape is something that often gets discussed within the digital world (and I assume other industries as well?) The idea being that someone has a thin (horizontal) set of skills in a range of things related to a job, but also is likely to have a deeper (vertical) level of knowledge about some form of specialism. What does this look like for people who think about services?

 

For a developer, the top of the ‘T’ could be a broad knowledge of a range of coding languages, whilst the vertical line might represent an in-depth understanding of one. However, as I see it, it might be more helpful to have a depth of experience developing in multiple languages and a broad range of knowledge about other things, such as UX, user research, product management, agile and so on.

 

This post came has been in draft for a while, but was kicked into life by this brief chat with Matt on twitter. I want to talk about how my skills have applied to this T structure, but before I do I want to be clear that I don’t see my trajectory as having been a direct or requisite path. The steps I took made sense to me at the time. I’m in no way suggesting that anyone else needs to pass through one of these stages to get to another. Life and people are not linear like that.

 

The T and me

 

It’s not just in the realms of development that the T is talked about, and I have been thinking a lot about what my ‘thing’ currently is. This has been on my mind after attending a UK government course (run by the brilliant Sharon Dale. She is awesome and you should all work with her.) The course focused on how to develop as a Service Manager, the role I now inhabit. It struck me that this is the 4th prefix of manager that I have had in my career. (Also: I am in my mid-thirties. I have a career and worry about bathroom tiles now. What?) This means that my day-to-day management focus has had to change a fair bit in the last few years.

 

So a story of the T and the []

 

It begins

 

I started out after university as a developer and, I am going to be honest with you here dear reader, I was rubbish at it. My hands-on technical skills have developed over the years but it soon became clear to me (and others) that I was a lot better at planning than I was at looking up things on stack overflow.

 

Technical Project - Delivery - Product

 

Perhaps because of my development woes, I was in my early twenties when I was given my first manager prefix. ‘Technical Project’ at the (to my mind sadly missed) peak of government quangos, BECTA. Looking back, I think it was there that my T started to become more of a square. The core of technical knowledge that I’d gained began to be added to with other vertical strands. This is something I now see as a repeating pattern throughout my moves between different jobs. Learning to manage external suppliers, roadmaps, projects (back then work packages) and so on was the first time around the filling in the square loops and took years to develop more. Through working on the (again sadly missed) Jam and a tour of sci-fi at the BBC, my knowledge of how to deliver things grew more definitively to the point that I was able to describe myself, from a project point of view, less as a T and more of a [].

The next manager prefix, ‘delivery’ was then possible. This move meant that – with a return to the T structure – my understanding of the project needed to be the vertical leg again. And the breadth of knowledge that needed to be gained involved line management, budgets, external influences, strategy and so on.

The next step was a shuffle sideways from Delivery to Product management. Within the BBC structure at the time, this was still about managing teams, but also owning a backlog, representing the user more strongly, defining a vision, having a greater focus on UX, user testing, AI scores, costs per unique user and so on.

A brief detour into being Head of Technology for a charity aside, (a role that taught me more about defining strategies and articulating vision than anything ever could,) I then stayed in the product space until my current Service role.

 

Service

 

I had thought that to get me going the vertical element of service management would have been my direct experience in the craft of previous roles. From there I hoped I could acquire the wider skills needed on the job, such as running teams twice the size I had before and working in the open. However, the Service Manager training made me realise I was looking at things from the wrong end.

 

I started to feel overwhelmed. I was being asked to not just know about, but be an expert in: technology, accessibility, assisted digital, procurement, Agile, product, delivery, UX, User research, infrastructure, architecture, team leadership and be a genuine subject matter expert in what the service delivered. This seemed too much to me. Some of them were possible, but *all* of it? It felt like a huge ask.

 

Then I realised I had this wrong. As a service manager, my role isn’t to be an expert in all of those things in the service (I have amazing people to help me with that) but to be an expert in Digital.

 

Digital is the vertical for me now. The role is bigger than just being inside a technology or a digital function in an organisation. And so I am dealing with people who don’t always want the detail. For the first time in my career I am also working with amazing people, outside of my direct team, who are not at all from a digital background. This means the horizontal requires whole new sets of things from me. Strategy for entire organisations, altering the relationship between a citizen and the state and perhaps most importantly (and this still seems the furthest away) actually informing government policy.

So. This means my digital knowledge is now something I can, and should aim to use to transform places where it has not been fully realised to its potential before. And inform choices where it can have the greatest impact. Pretty exciting stuff.