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?
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 on your top-performer list. Hmm, a completely unique case, again.
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, and budgets and things. 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. The products that we ship tend to reflect what our organization looks like from the inside. Our business of software development at the core is all about building new stuff, about being agile, about being 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 do so much more. The specific additional value they bring is all very unique to them.
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.
Yes of course, this would result in new management challenges. How do you distribute salaries fairly? What if your people want to move to another company one day and have to explain what that “Contributor” role on their CV really means (I say: let them put on LinkedIn whatever they want)? Yes, it will make some things harder. But is that sufficient reason to just stick with our current static systems forever?
Contributors, not limited by a mold and predefined career path, are free to each find their way to do exactly that: contribute. Set those people free!
No more that’s not my job.
No more you can’t do that, that’s not your role!
No more boxes.
Custom box design
Even if we would be able to either give everybody the same title, or everybody a custom one, that doesn’t magically make everybody do their highest impact work.
So, how do we do help people with that?
Our starting point would be the principle that everybody is different, and we should benefit from this fact rather than suppress it. The goal is therefore to uncover every person’s “essence,” develop it and optimally integrate it into the larger organization.
We started the chapter “No More Control” with a Steve Jobs quote:
“It doesn’t make sense to hire smart people and then tell them what to do. We hire smart people so they can tell us what to do.”
We can adapt this quote to personal development. Here’s how we can formulate this analogy:
It doesn’t make sense to hire smart people and then tell them what to learn or what exact role they should play. We hire smart people so that they can tell us what the company needs and what their role could be to contribute to it at their full potential.
The role of management is to challenge and support people in this process, and provide them with relevant context (e.g. knowledge, experience, connections) they need.
Note this is quite contrary to a more command-and-control approach that assumes the boss’ role is to be the smartest, the most knowledgeable; and that the boss knows what your talents and potential is, and what your role should be. Once again, we lead with context.
Here are the steps:
- Identify an (initial) scope of potential impact. If a person is new to the company or junior, the manager may need to nudge things more into a specific direction than with more senior people. For instance, when hiring a junior or mid-level engineer, a perfectly valid starting point is to propose owning the implementation of specific features in the scope of a team. For more senior people, this scope should be bigger and ideally ever increasing. This scope of potential impact ought to be based on the area of interest and expertise of the person in question, although ideally slightly wider to push people outside their comfort zone. Questions to ask:
- How would you describe your scope of potential impact at the company, what area do you currently feel responsible for, or want to grow into to have more of an impact on?
- Identify the customer’s and company’s needs in the identified scope of impact. Questions to ask:
- What do you think the customer and company gaps are in your area of potential impact? In other words, what in this space is not going perfectly just yet?
- Of those gaps identified, which ones do you think have the most priority?
- Identify your role and goals. Questions to ask:
- Of the high-priority gaps identified, which ones
- Can you fill immediately?
- Can you grow to fill?
- Do you see yourself as a high-leverage fit (a high “bang for the buck”) to fill?
- Do you want to fill?
- Which ones do you want to commit to filling in the next time period?
- Identify blockers. Project yourself some predetermined time into the future, you’re in your next performance review and we get to the section “What blockers or challenges did this person experience over this review period?” Questions to ask:
- What is this section likely to include? What are some steps we can take today to avoid them from becoming a problem?
From this, we can make a plan. If our company is flexible enough to allow the creation of individual job descriptions, you can do that. If not, just position this plan as personal development goals.