Why T-shaped people? (2018)

I can't tell how serious your reply is here. Is there a hint of sarcasm in there?

I think T-shaped people are usually specialists-turned-generalists, for example good software developers who later on became managers. As a manager you have to be a generalist, and you usually have hundreds of small tasks, so no deep dive in one topic, but surface level in many.

In my experience these people are definitely better managers (unless they suffer of old physics prof disease), but I don't see the large benefits for more specialised roles. The more I switch to being a generalist, the less I can actually deep-focus, and talking to friends and colleagues, it doesn't seem like I'm the only one.

That said, interest and curiosity about other fields, especially the ones you actively work with or neighbour is probably always a great quality to have.

I am more of a fan of Kent Beck's "Paint Drip People" ( https://twitter.com/kentbeck/status/761223760091320320?lang=... ) (and a commentary on it - https://becarneiro.medium.com/generalist-or-specialist-welco... )

The original used to be available without needing to log in, but now it appears to be hidden behind a login at https://www.facebook.com/notes/373922293851423/

The text of it:

Keith Adams worked on kernels at VM Ware. Then virtual machines. Then search performance at Facebook. Then the HHVM implementation of PHP. Then machine learning. Now he’s Chief Architect at Slack. In between he worked on hundreds of little projects that lasted hours or days or weeks. Keith is a Paint Drip Person.

I was a big fan of the T model of skills, introduced by David Guest in 1991: know about a lot of things, be really good at one. The more I taught it, the more unhappy I got with the metaphor:

  - Skilled people are good at several things.
  - Skilled people’s interests develop over time.
  - Skilled people don’t plan their next focus area. Sometimes it seems completely unrelated to their previous focus area.
  - Skilled people are always exploring, just for the sake of curiosity.
  - Skilled people resurrect interests sometimes.

All of these metaphor fails led me to the paint drip model of skills.

  - You draw a brush across the top of the canvas.
  - Sometimes enough paint accumulates that a drip starts to roll.
  - Once a drip starts to roll, it’s not clear how far it will go.
  - You keep drawing the brush across the canvas, regardless.

“Moving the brush” is the curious exploration. Keith reports that he tries a project a week or so, but that most “don’t go anywhere” (I beg to differ). The drip rolling down is an area of specialization. Once it starts rolling, it’s not clear how far it will go. In any case, the brush keeps moving. Eventually the last drip stops and a new one starts.

I feel the same. It's also just very mentally taxing to learn on the fly. Because usually, I'm trying to develop a feature and I feel the pressure of delivering on time. I find it difficult to learn even on the best days, and if I'm stressed, it makes it much harder to concentrate.

Ha, I had the exact same experience a bit over a decade ago! Only it came from a total misunderstanding of what agile teams were supposed to be, the idea that anybody on the team should pick up any story they wanted to.

So suddenly the graphic designer is writing HTML and CSS, the front-end developer starts writing SQL queries, and the product manager starts writing JavaScript.

The experiment lasted about a month with a lot of hurt feelings, because essentially all the code just had to be totally reverted.

The graphic designer knew how to write CSS for his browser and screen resolution, but didn't have the faintest idea how to deal with window resizing, browser quirks, unexpectedly long text, or how to integrate with our established frameworks at all. Just threw a lot of CSS straight into "style" fields instead of CSS files. The SQL queries fell apart in production because the front-end developer didn't know how indexes worked at all, or to aggregate values on the database server instead of client-side. While the PM's JavaScript was similarly just modifying the DOM directly instead of using the framework, leading to total spaghetti code (and global variables everywhere).

The worst part wasn't even the wasted time, but the damaged personal relationships. Because nobody had even the level of expertise to understand why their code had been reverted, so they blamed it on politics instead. The PM thought it was totally unreasonable to require usage of the framework, the front-end dev blamed the database architecture because indexes didn't seem like something anyone should have to deal with, and the graphic designer similarly could never be convinced of any good reason why CSS shouldn't be inlined into HTML. All of them wound up blaming the actual team member experts for getting jealous of their turf and trying to unjustly sabotage the new people's contributions.

Just a disaster all around.

Now obviously that was kind of a worst-case scenario. But nevertheless, ever since I've been extremely wary about people picking up development outside the area of expertise they were hired for, simply because people don't know what they don't know. In other words, they don't even ask to get assistance on how to do something properly, because they're totally unaware there's a proper way that's different from what they just naturally hack together.