N.B I originally wrote this back in 2017, but thought it was worth carrying over
Not the post-office
I work in software development, specifically in media and have done for quite a few years now. But I’m not an engineer, I’m not a product manager or even a QA. I’m in delivery.
This topic always seems to come up when you meet someone for the first time, either that or when getting your hair cut, and you start to talk about what you do. Some of the challenges this causes is that firstly you can’t talk about the value you bring very easily nor the importance of the role overall. If you can’t talk about it in those water cooler type moments, then how can you talk about it within your workplace!
In the past ten years I’ve taken my hand to a multitude of things, from customer support to architectural design to organising celebrations and team outings! The role of delivery within software development can see you play many roles, meaning you really need to have a range of knowledge. If there was any role within software development that needed to be ‘T-shaped’ then delivery is it.
Someone recently said to me that not everyone should be t-shaped, it’s become a term very similar to ‘Agile’ and has been packaged and sold as something that will solve your problems.
During our conversation it resonated with a piece of advice I’d received a long time ago about building teams and ensuring to have the right mixture of not only race, sex and backgrounds but also in terms of their motivations, aspirations and energy.
If for a moment you think of the t-shape as filled up with your overall abilities, you’ve got a limit ultimately, be that on your actual physical or mental limits depending on the type of work, or even to the time of day! For those of you that play video games, imagine it in a way that you have a certain amount of points to spend on certain attributes. Fallout does it in one of the simplest ways;
Thinking of it this way, it becomes a challenge when you invest too heavily in the broad part of the T and not the deep part of the T.
And the deep part of the T represents some serious expertise! Without people like that, you might no be able to overcome the huge challenge or break into that opportunity.
But what about delivery?
In software development, on page 1 of most books we talk about a life cycle. It varies with interpretation but fundamentally it falls into very straight forward categories.
Planning > Analysis > Design > Implementation > Maintenance
(At least, that’s Wikipedia’s version anyway).
What role does delivery play in? Certainly product might fall more into the former parts of planning, analysis and design. Engineering more likely to fall to the right with analysis, design and implementation. Where does delivery play?
Everywhere.
That can be pretty intimidating and can cause friction in some areas (although that’s a topic for another day) but in some shape or form delivery roles should be involved along that whole life cycle.
With that in mind, we can talk much more about fundamentals since listing every single thing we could do becomes an unnecessary task. In essence our work falls into enabling everyone around you and facilitation, ensuring the frameworks and processes work for all involved.
This ultimately puts us in the position where being t-shaped really is necessary for working in delivery. Knowing enough about engineering, product & UX&D and having skills that allow you to contribute to all of those areas well enough to bring it all together.
Not having those skills or abilities, puts you in a solo and for such a role — it really puts you on the back foot in your ability to enable and facilitate everyone else.
Delivery really is the only role that should always be t-shaped.