No More Boxes

Think of the three people in your organization that you consider your top performers. The three people that if they’d tell you they’d quit, they would leave a significant hole in your organization.

Got them in mind?

Alright, now pick one of them, and compare them to their job description, and the the level in your organization’s competency matrix where their current role and seniority level fits. Does their job description and competency matrix level accurately describe what you appreciate in them the most?

Probably not.

Hmm.

Alright, no biggie. We can fix this! Since we now know what we appreciate in our first top-performer, we can adjust or expand our job description and matrix appropriately. So let’s do just that, let’s add the “competencies” that we appreciate in this person to the matrix, and add them to their job description.

Done? Nice! Did you check with your colleague managers, your boss and HR if they’re OK with this expansion? You didn’t. Ok, you probably should.

“This is not the right time,” they said, huh? “Let’s wait until just after the end of year performance review cycle to make any changes.” Oh well, I suppose that makes sense. It’s July right now, but alright.

Did your boss and colleague managers agree with your ideas for expansion? Some did. Others appreciated different things in people than you do, as it turns out? Right, that was to be expected, their needs are not exactly the same as yours.

Did you still manage to compromise on some adjustment, though? Ok, good. Progress.

Now, let’s move on to the second person your top-performer list. Hmm, a completely unique case, again.

Shit.

We are engineers. We like systems. We like systems we can break up into components; clearly define responsibilities of those components and then divide and conquer. We like we can create abstractions in systems and standardize things because that allows us to keep things in our head and scale them. This allows us to build larger and larger systems.

And so we apply the same principles in our organizations.

We start with the smallest unit: the individual contributor (or “IC”), the engineer. Then, we put multiple engineers together to form a team, and a manager to go with it. The manager is responsible for managing the team, which simplifies things for the organization, it creates a team abstraction. Now we can start thinking at the level of teams.

We add another team, and another, and another. Ok, this is starting to get big, so we need a new level of abstraction. We create a concept of a department, and a manager to manage that department. Good, now things are simple again, we have one department and one person responsible for it. Now, we can add another department, and another.

And so on, and so forth. This is how we scale software, this is how we scale organizations.

Another dimension: standardization. We need to hire people. Alright, this was done a bit ad-hoc until now, and as a result, there’s a lot of variance in your “parts.” Skillsets vary, experience levels vary. That’s a bit messy, and it impedes our ability to easily shift resources between departments and teams. We need to clean that up. So let’s standardize this a bit. Let’s introduce a competency matrix to make sure everybody fits the mold. Because if we standardize, we can abstract. And that simplifies things. That allows us to scale.

That’s how we’ve been doing things in companies over the last few decades at least.

How are we liking it? Do we feel this is supporting us in getting the most out of our people?

I have two perspectives on this.

From the engineering perspective, I love it. This is the stuff I know. Abstraction. Standardization. Simplification. Scaling.

As person aware of the “cogs” in this machine, and as a cog myself, I’m not convinced we’re doing this right. I suspect we’re keeping the lid on potential.

Leaving aside that this line of thinking equates people to machines, which is somewhat offensive, this is a system that incentivizes fitting in, following well-paved paths. As we know, you optimize what you measure. All the while our business of software development at the core is all about adapting to change, being flexible and innovative.

The most significant shifts in our industry are made when we think outside of the box. From not fitting the mold.

And here we are building a very elaborate box-based system. It may scale like butter, but it’s set up to to scale through mediocrity.

Think back to your top performers. Why are they on that list? It’s not that they do exactly what they’re “supposed to,” it’s that they do something different.

If they would have fit the mold, if they were properly shaped cogs, you wouldn’t care if they’d leave. You’d have plenty of other cogs to replace them with, right? But these people don’t. Each of them is different, and given a choice, you’d love to have more of such people, not fewer.

But they’re here, so somehow we must be doing something right?

For now. You may have been lucky. Will they stick around? Think back over the last years, how many of these top performers have left, and why?

Performance review season is coming. You’ve got your template. Can show the value they provide to you with that template? Can you fully appreciate their contribution, and will that translate to whatever systems your organization has in terms of showing appreciation? Promotions? Salary increases? If not, can you create the roles and levels to make them fit in fast enough?

Remember, your suggested changes to the competency matrix are still pending. And to be able to promote this one person, you kinda need a role at that level to open up somewhere in your organization.

You need to create a box to be filled.

You’ve told them that when this happens, for sure they’d get it. They’ve been patient for some time, but that patience is rapidly waning.

You can tell, as you talk to them week by week, motivation is dropping.

“It’s coming,” you keep telling them.

They nod. They appreciate that you try.

And then, that Friday, the last day of the month, they drop the bomb.

“I found this other company, and they offer me this great box that fits me better, and pay me all this money. I’m sorry, but I decided to go.”

I envy companies that dare to have simple job titles without levels, like “Engineer.” I feel they’re on the right track.

Perhaps “Engineer” is still too limiting of a box, it still keeps people slotted into a particular area. What if they feel they can contribute beyond engineering, by peeking over the wall towards the business side, or taking some management responsibilities, would you really want to limit them? “Engineer” may not be broad enough. Maybe you just need “Contributor” as a job title. For everybody.

“Zef Hemel — Contributor”

That would work for me.

Then, not limited by a mold and predefined career path, let each find their way to do exactly that: contribute.

No more that’s not my job.

No more you can’t do that, you weren’t hired for that!

No more boxes.