Thoughts on Developer Shapes
Thoughts on Developer Shapes
The "shape" is a good mental model for hiring and professional growth.
Shapes
I don’t know when the first idea of professional shape started, but in the 80s, McKinsey Consulting began to use the concept of a T-shape to refer to individuals with a particular set of skills.
A shape is the set of skills of a person.
A Mental Model
I like the mental model of the shape. I believe it’s a suitable metaphor when hiring or deciding how to grow as a developer.
The “shape” is a simple term that helps us understand why some people adapt better to a team than others. And it also helps us understand why software development is not only about programming. In the end, many other skills make you a strong software engineer.
Shape is a good mental model for hiring and professional growth.
Common Shapes
The first shape concept that started at McKinsey in the 80s was the T-shape. It describes a person with a wide range of knowledge while being a specialist in one area.
Since then, recruiting has widely used the idea of shapes, and many other shapes have appeared—for example, the ∏-shape is like a T-shape with two specialties instead of one.
Shape With Holes
A shape with a hole is someone who lacks a critical skill related to the role.
Examples of shapes with holes are a marketing person that doesn’t know anything about communication, a frontend engineer that doesn’t know anything about UX, or a backend developer with no CLI skills.
It’s hard to complement those skills with other team members. So that’s why I draw the deficiency as a circle in the middle of the shape.
Shape Width
To communicate well with another person, both need to share some common knowledge. That’s why it’s hard for non-technical managers to interact with a development team.
Wider shapes, those with more breadth of knowledge, have it easier to communicate with other team members or other departments. For example, it’s easier to talk with the designer if I know about UX.
Wide shapes collaborate more effectively.
A typical example in development teams is the interaction with the product manager. As engineers, we often complain that product managers don’t know anything about development, and that’s why they don’t understand us.
Yet, do developers know about the product domain?
For example, if the team is developing a program for an accounting firm, do the engineers know about bookkeeping? Can they understand a financial report? Can they talk with an accountant about their work?
Shape Growth
Shapes are not necessarily fixed; they can evolve and change. That’s why one must hire based on the potential, not just the current shape.
Some candidates might lack experience in one technology or the industry, but if they have a growth mindset, their shape grows and adapts to the team. The team’s needs also change with time, and fixed shapes have more difficulty adapting.
Food For Thought
What kind of shape are you? What kind of shape would you like to be?
There is no perfect shape.
I don’t think there is a perfect shape; team members must complement each other. Yet, I do believe that some shapes are easier to fit in a team than others.
What do you think?
If you like this post, consider sharing it with your friends on twitter or forwarding this email to them 🙈
Don't hesitate to reach out to me if you have any questions or see an error. I highly appreciate it.
And thanks to Michal, Miquel and Sebastià for reviewing this article 🙏