Why is an individual contributor like a Tetris block?

One of my clearest childhood memories centers around a Christmas morning when my father gifted me a Gameboy Color and a single game cartridge to go with it: the original Tetris.

For the next few years, I stole every spare moment I could find to rack up higher and higher scores on each level. I distinctly remember that of all the shapes that could drop from the sky, there was a set of cursed tetrominoes (the official term for the shapes!) that always messed up the plan I had for my neatly-laid rows: the ‘S’s and ‘Z’s.

Image source: https://tetris.fandom.com/wiki/Z-Block 

As I improved at Tetris, I eventually came to embrace these shapes and changed my row-building strategy to anticipate their arrival. I became better at the game when my overall tactics became more holistic, and less centered on dread towards one particular piece.

My Tetris skills are pretty rusty these days, but over the years I’ve thought a lot about Tetris as a loose metaphor for software teams: in the same way that some shapes might not obviously fit into a game plan, people will sometimes have collections of skills and competencies that don’t cleanly fit into an organization’s definition of ‘senior engineer’ at a given point in time. I’ve been this engineer before, and I’ve been referred to as an ‘oddly-shaped’ engineer for my defiance of an organization’s neatly-laid-out matrix of competencies. I’m here to suggest to you, whether you’re a fellow lover of classic arcade games or an engineering leader wondering how to create and grow more robust systems for career development, that the oddly-shaped engineer might be the canary in the coalmine most worth listening to.

Imperfect checkboxes 

There are multiple ways to design career ladders – many of which are outlined in concrete detail in Marco Rogers’ excellent talk from LeadDev New York 2019 – but in this article, I’ll focus mostly on matrix-style frameworks, due to my own incidental familiarity with them. Imagine an engineering career matrix that looks like this:

It’s worth calling out that skills matrices will always be imperfect. They’re often retrofitted based on a best-effort approximation of one or more of these ideas:

• What high-performing individuals currently within the org have done, or are doing;
• What skills would likely be beneficial for the org to have, and therefore should be incentivized for individuals to develop;
• What other similar companies have released (or shared in backchannels!).

All of these inputs are based on assumptions and observations taken at a snapshot in time, meaning many engineering teams will likely outgrow the first iteration of this document. Evolving the skills matrix with the changing needs of an organization is a healthy practice, but of course, there’s a hazard to overdoing it – for example, a rewrite of the entire skills matrix every six months will create frustration for individual contributors who will feel that the goalposts are constantly moving. (On balance, I believe that having some kind of defined career progression ladder, no matter how imperfect, is still better than having none.) 

The problem with the matrix

An oddly-shaped engineer is an individual contributor whose skills don’t neatly fit into a single column of their organization’s skills matrix. Conversations about competencies tend to surface at promotion time – when an engineer is viewed to be deficient in some rows but proficient in others, a common reaction from managers is to ask them to focus on developing their shortcomings, before they can be promoted.

Given the rules of the game, this is a reasonable intervention on the part of any engineering manager. In some cases, engineers can succeed in the next promotion cycle after investing in their areas of weakness. In others, individuals find out that they actually become less effective, or enjoy their day-to-day work less when they start focusing on their weaknesses rather than their strengths. I have even heard the case of an individual deliberately taking a title downgrade, because remaining at the higher title required them to develop a set of competencies that were not worth it for them to build, given the other ways they were already effectively contributing. But I also challenge whether asking individual contributors to conform to a skills matrix is the only available intervention for engineering managers and leaders: can an abundance of oddly-shaped engineers, who are otherwise meeting expectations, be viewed as a signal for the organization to reevaluate its definition of engineering effectiveness?

Blocking diversity and innovation

Another pitfall of nudging all engineers to become column-shaped is that it may be harder to build meaningfully diverse product teams. I don’t believe that optimizing for column-shaped engineers will necessarily result in homogeneity on teams, because most career matrices are intentionally written with enough ambiguity that ‘checkbox-driven development’ isn’t possible at the senior-and-higher levels of engineering growth. But I do believe that many engineering ladders under-index on other skills that are tremendously important for innovation. These skills include, but are certainly not limited to:

• Affinity and empathy towards customers;
• ‘Product-mindedness’: curiosity about roadmaps, prioritization, vision, and saying ‘no’;
• Facilitation skills;
• Clarity and kindness in written and verbal communication;
• Knowing when not to build something, e.g. the build/buy/reuse trade-off.

Conclusion

The process of growing software teams often feels more like trying to find the next perfect tetromino, rather than thinking about the construction of the next few rows in a way that accommodates the surprise and chaos that reality throws at us. When we want to bring in a senior engineer, we tend to go through a box-ticking exercise to ensure that the candidate meets some minimum standard, as articulated in the job description. Not to abandon the notion that minimum thresholds of technical experience are important for many roles, but I wonder how differently we would hire if we overlaid the competencies of each person currently on the team – like a stack of semi-transparent layers – and tried to color in the unfilled squares instead. Building diverse, polyglot teams is most possible in a world where oddly-shaped engineers are allowed, and encouraged, to pursue their strengths.

So, what’s my advice on how to grow people and teams? There are no easy answers, but I believe that the most resilient companies are staffed with people who have a steady growth mindset at all levels of the organization. Create processes and artifacts like career matrices with the humility that your assumptions might be wrong, and evolve these tools with observational evidence about what seems to be actually working on your teams. Career development frameworks are perhaps best used as a starting point, but not a closing chapter, to conversations about engineering development. There are no oddly-shaped tetrominoes, only ones that we haven’t figured out how to incorporate just yet.

Special thanks to Mike McQuaid, Jeff Rafter, Tim Clem, and Jon Ruskin – some kindred oddly-shaped engineers – for their wisdom that helped craft this (oddly-shaped) piece.