On I-Shaped and T-Shaped Skills

Several of the conversations I had at the recent RIPE70 meeting were focused on career advice (usually along the lines of “which technology should I focus on next”) and inevitably we ended up discussing the benefits of T-shaped skills versus I-shaped skills… and I couldn’t resist drawing a few graphs illustrating them.

A person with I-shaped skills is an expert in an ever-narrowing area (in the end you know everything about nothing). A person with dash-shaped skills is a generalist knowing a bit (or nothing) about everything.

Assuming comparable length of experience, motivation for learning, and exposure to new challenges I’d assume the area below the graphs being approximately equal for both types of skills. There’s only so much you can master in a given amount of time.

The “only” problem a generalist might have is that he’s under-skilled for the job at hand (too often solved by cut-and-pasting recipes found on Google aka Fake It Till You Make It). For example, he can easily tackle the green job in the following diagram, but not the dark-blue one. On the other hand, an expert might be over-specialized and thus unable to do a simple job outside of his area of expertise (don’t ask me how to add a user to Windows Active Directory).

Even worse, an expert is quickly over-qualified – he knows too much about a specific area, and no smart employer is willing to pay you for the knowledge they never need. As an expert you have a few options:

  • Get a job in an environment that needs all your skills (example: work for a vendor);
  • Get a job where you’ll get engaged in numerous small high-value projects (example: work for a professional services/system integration company or as an independent contractor);
  • Find someone who’s willing to pay you way more than the real value you add;
  • Reskill.

Someone with T-shaped skills is obviously better suited for a wider variety of challenges and thus a better fit for most organizations – keep this in mind the next time you’re trying to figure out whether to specialize even more or tackle an adjacent technology.

Speaking of adjacent technologies, it might be possible to grow your total area of expertise much faster (due to cross-pollination of skills) if you carefully select the adjacent technologies – for example, storage networking isn’t much different from Ethernet (or X.25 ;) and virtual switches often tend to be lobotomized VLAN-capable layer-2 switches (or really simple IP routers).

Speaking of reskilling…

At least once a month I get an email along the lines of “your webinars really helped me get this new job” – if you need solid fundamentals in new technologies, from virtual networking to cloud infrastructure or SDN, check them out.


  1. The thing is like you said, the capacity to transpose knowledge to other domains, so I would correct your specialist curve by drawing the same peak with slower decreasing. It covers partially the surrounding technologies that are linked. For example, Xen and VMware or ipv4 and ipv6, some knowledges are transposable and some are not. It's my point of view.
  2. So where does the network/solution architect role fall in the enterprise space? It seems that you are expected to be an expert but we also leverage vendors for specific skill sets/implementations and still need to have a breadth of knowledge outside of networking (cloud, security, mobile etc)
    1. It's a different dimension - you need to know how things work (and it helps to know why they work that way), but not how to configure or troubleshoot them.
    2. Yes, I find it's more about learning concepts and how technologies integrate as opposed to the CLI. No cert for this yet :)
    3. "Yes, I find it's more about learning concepts and how technologies integrate as opposed to the CLI"

      TOGAF for Enterprise Architecture, ITIL for Service Management and COBIT for IT Governance, there you go for starters.
  3. You know.... figuring out which adjacent technologies are actually worth developing expertise in seems like a pretty tough problem. It seems easy to research different technologies and begin to develop an understanding and some expertise.

    I worry that many products are so specialized that learning about them is mostly vendor-specific knowledge, and it could be a waste of time.

    For example: Nobody I work for is going to fork over the cash for a Palo Alto firewall, so it seems like there is no point in attempting to add their product to my skillset, unless the training material will cover a broader area in IT that is not product-specific.

    What is hard and confounding is how to pick which technologies, products, or principles are a productive and beneficial usage of time to actually spend time learning about.....

    Is there really anything obvious adjacent to Redhat Linux, Windows Server/Exchange/MS SQL administration, vSphere ESXi admin/design, JunOS/Datacenter Networking, PIX firewall administration, Storage networking, NFS/iSCSI/FC/FCoE, SAN storage array Administration?

    1. I find learning more products or "boxes" helps if you are in a system integrator/VAR job. If you are at a Telco or Enterprise you pretty much just follow their standards and knowing more boxes may be knowledge you won't necessarily use (but you may get paid more if you do :)).
  4. It's always the same debate, practice helps you doing parrallels between multiple technologies or principles, and so helps to understand them faster as if you were learning from scratch. On the other side, the theoretical learning will help you getting the basics to build a solid and trustfull knowledge on. As ever, a mix of both is the best. And I'm sure we are happy to not know some of the crappy technos outside there...
  5. Pirmins post is spot on have that balance and to add one thing I learned and it is an actual skill in our industry is to learn what not to learn and when.
  6. Excellent explanation and diagram, confirms some of the suspicions I had about so-called 'experts' as being Great Big Knobs, LOL!
Add comment