Icicle-Shaped People
In the Agile world we hear a lot about the concept of “T-shaped people”, where a person has reasonable skills in a broad range of topics and deep knowledge and expertise in one area. If you were to graph those skills with the topics on the X-axis and the depth of expertise on a descending Y-axis, it would look like the letter T.
Conventional wisdom says that Agile teams should be comprised of these T-shaped people in order to deliver their work. For example, the Scrum Guide states, “Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment”, as well as, “Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole”. This guidance is good, and suggests from the start that we would like T-shaped people on our teams!
In a recent discussion, though, someone asked what would happen if a team had T-shaped people but many of the depth areas overlapped and left gaps in others. I suggested that the team would have to acquire those missing skills either by learning them or by borrowing a person who had them. For the former, I spoke about my own experience over years of being a contract software developer where I simply had little choice but to pick up new skills as new problems confronted me.
I said that I wasn’t T-shaped, but instead icicle-shaped, in that my skill-set looks like icicles hanging from a roof or tree branch!
The more I thought about it, the more I liked the analogy! Again, there are a broad range of skills, and I don’t necessarily have equal depth of knowledge in all of them. Similarly, those skills can “melt” over time becoming shorter icicles. For example, I recently received a phone call from an agency asking if I was interested in a development contract using a technology in which I was once an expert, but that I hadn’t touched since 2003! While I’m sure I could pick it up again, that icicle was now just about melted away completely.
There’s a hint in that last sentence, though — I could pick it up again. Or, I could pick up a new technology, new framework, new platform or, really, anything new if I needed to. I could build more icicles along my roof line!
This ability isn’t something that’s unique to me, either. I know dozens of people who will simply pick up whatever skills they need when faced with a problem to solve. In fact, that’s what got me into developing software in the first place: the love of solving problems! I suspect that’s also a driving force behind anyone who had a broad base of skills which form a toolbox that they can use at any time.
You may be asking, “What’s so bad about specialization?”, or saying, “If we don’t have experts, then we’re bound to make ‘rookie’ mistakes!” The answers are that there is nothing wrong with specialization and, yes, having experts helps avoid mistakes. Those aren’t the problems, though. Where specialization of skills causes problems is when those specialists are isolated from the teams they serve, thus creating a potential bottleneck in the flow of work which, in turn, slows a group down.
For example, I have dealt with countless clients where all database change work had to be done by a Database Administrator (DBA). There was usually some ratio of teams to DBAs that was in an uncomfortable range of 3:1 or 4:1, often worse. That meant that the DBAs always had a backlog of work and any request took some time to be completed. Even simple changes could take days to weeks, depending on the current workload.
What bothers me about the specific example of the DBA is that the vast majority of their work can be learned by anyone, even me! Until you get into the realm of low-level storage optimization and the care & feeding of the database engine, work like creating DDL with reasonable data types is relatively straightforward. I learned data modelling from working with some of them back in the early ’90s. I also learned how to structure tables with the most efficient data types from various people with that knowledge across multiple RDBMS. I learned how to use the database tools to see how a query would be executed so that we could optimize it and not have to wait for a DBA to tell the team that a particular query was eating resources. It really wasn’t difficult!
In essence I’m what’s now called a polyglot or full-stack developer, or what Scott Ambler referred to as a Generalizing Specialist. Many of the people I worked with in the ’90s were the same… because we had to be! Today’s proliferation of technologies might make that more difficult, but you don’t have to know everything about everything in order to be effective. You just need to be willing to learn something new in order to solve the problems at hand and allow your team to keep moving forward. You also have to be willing to let some older icicles melt away because you don’t need those skills at the moment. Again, you can re-learn them if need be.
So, while the concept of T-shaped people is a good one and creates a decent mental model of what a team needs in order to ship effectively, think about moving from T-shaped to Icicle-shaped to truly ensure that your team has all of the skills necessary.
📝 Read this story later in Journal.
🌎 Wake up every Sunday morning to the week’s most noteworthy stories in Society waiting in your inbox. Read the Noteworthy in Society newsletter.
