Being ‘T-shaped’ is a term that’s been trending recently. The ‘T’ is a metaphor used to describe a person’s skill profile – the vertical bar represents the depth of a person’s core expertise and the horizontal bar represents that person’s ability to contribute in areas outside of their core.
When you’re part of a cross-functional product team, being T-shaped is incredibly important and this is well illustrated by digressing a little with some recent experiences of mine.
Last year my girlfriend and I went on a kayaking trip in Sweden that involved 4 days of navigating on our own through the St. Anna archipelago with only a sea map and a compass to guide us.
We had a double-seated kayak constructed so that the front seat had space for the map and compass, and the back seat had foot pedals to control the rudder with a small space for another compass to ascertain the bearing. My girlfriend has a better sense of direction than me and so took up the front seat. I’m stronger than her, so took up the rear seat.
We planned that she’d read the map, call out the bearing to me, I’d get us on the right course and then power on until we hit our next checkpoint. Simple.
Day 1 went pretty smoothly as we covered only a short distance in the remaining light, but on day 2 we soon got lost. I can assure you that getting lost in St. Anna is a major issue when you’re trying to navigate through 6,000 tiny islands that all look virtually the same.
The real problem stemmed, however, from the fact that whilst my girlfriend listened intently to the instructor before we set off, I figured it didn’t matter as she’d be taking care of navigation whilst I was just the engine. So whenever we got lost, my capacity to help figure out how, where or why we’d gone wrong was next to nothing – I couldn’t have been less T-shaped in our team of two if I’d tried.
We found our way, in the end, but I learnt a tough lesson in Sweden. We were significantly slowed down, didn’t get to see all the places we wanted to and ‘debated’ more than we normally would in that situation. Above all it meant that the goal of having an amazing trip was compromised.
This year we went to Iceland on another 4-day adventure, hiring a 4x4 and driving many miles across the country to see the amazing sights. Though we got lost in Sweden, my girlfriend is still the better navigator, and whilst she'd beg to differ, I’m definitely the better driver. But we weren’t going to make the same mistake as our last trip and stick to our roles. This time we planned our routes together, navigated together, and both got insured to drive.
We’d made concerted efforts to be T-shaped and it paid off, especially when extreme snow storms hit and navigating got incredibly difficult. We still got lost, but we always figured out where we’d gone wrong quickly and were able to get back on track with little delay. This meant there were no hold ups (other than waiting out the snow storm!), we saw everything we planned to see, and we had an incredible time which meant we achieved the goal of our trip.
The above scenarios are no different to how things work in a cross-functional product team. There are specific functions and roles that need to be fulfilled in order to achieve the goal of the team.
If you’re lucky enough to be part of or involved with such a team then ask yourself how many times has one of your developers gotten stuck and you haven’t been able to help? How many times has a design challenge required more brains but you haven’t felt equipped to contribute? Or how often does someone struggle with the amount of testing on their plate?
Being T-shaped doesn’t mean we need to be experts in every field (we’ll leave that to Elon Musk) but by reaching outside of our core expertise and growing our skills into other domains we can be more useful to each other, have a better chance of achieving our goals and, as my girlfriend will confirm, you’ll be sure to have a better time on the journey.