Measure Concrete Actions of ICs

Building an efficient team means building a team that gets done the most with the least amount of money, and humans are the biggest expense in software engineering teams, so getting the most out of them is important 🤑! While senior and staff engineers are expensive, you would hardly guess that the output from a team of senior and staff engineers is going to be proportionally higher than a team of a mixed level of engineers when you compare the team’s total salary. (Note here that I am not questioning the price. Market determines this, not some powerful union of staff engineers…) While the amount of experience is a factor in playing the “Moneyball” with your engineering team, my favorite team I have worked in in my career consisted of people with different strengths: we were good at math, deep learning, infrastructure, code performance, technical communication, etc., but no individual was the rock star in multiple things. So how can I build a team where each individual is relatively cheap but that as a whole creates an expensive output? You could just try to do your best in recruiting, but that’s out of the scope of this post. Let’s focus on loving the one you’re with here 🎶. Where do we start? Start measuring the employees on more aspects. During the review cycle, the questions I answer to give feedback to someone are broad and vague: what does this person do well? what can this person improve on? I want these measurements to be more specific. Think about what you need in this team: project management, ongoing maintenance, agility, research/new feature, etc. What skills do you expect your ICs to have to get these done? Technical communication, planning, code quality, code review quality/turnaround, knowledge in product, empathy with customers, qualitative/quantitative analysis skills, etc. Too often we measure things at high granularity, e.g., leadership, experience in fancy big impactful projects, and they seem hard to get. But if you actually tried to list the more fine-grained qualities that you expect from someone that would score high on these mighty sounding qualities, you would soon see that they seem a lot more tangible and are probably already present in your team to a degree.

Micromanage ICs’ Career

Let’s think what is the point of having someone get promoted in the team:

  1. promotions make ICs motivated and motivated ICs work harder/do not quit
  2. you need a diverse set of skills within the team, such as leadership, planning, execution (and different skill sets are expected at different levels, oddly.)

The point I’m trying to draw is that if all the things we do in a tech organization at heart is to increase the output, you have to be able to tie this career and leveling shinanigans into output, and you manage people to increase output, not to haze them.

Too often, there are some expectation guidelines for each level, and you may talk about some things that you can do to be at the next level with the manager. But the action items set for the ICs are vague, especially compared to the details an IC would include in any technical task description (at least its ideal version)! Another problem is that they are also mostly up to the ICs’ discretion to execute. It’s as if nobody actually believes these things will help the output of the team!

People have different amounts of aspiration, different views on work-life balance, extroversion/introversion, etc., but I believe everyone can level up if they find what they are particularly good at, work on/practice it for a while, and market it well (assuming they want to do this). I’d like managers to micromanage people’s careers more, make related tasks part of the team’s weekly plan, so everyone is given the time and sense of accountability to execute them, as it is the case for technical tasks. Also, don’t just say vague-ass things like “take more ownership”; demonstrate and give concrete examples and review regularly how they did in that regard. If you don’t analyze the situations frequently enough, the details get lost and the feedbacks end up more of a statement of impression than evidence.

These all might sound like a manager is meant to treat ICs like little kids when it comes to career. But we are already confined in a very hierarchical environment. Even as I was leading technical projects, there were times when I was never invited into the quarterly planning meetings. Everything was decided by the product and engineering managers. ICs are already being told what to do. If a manager is truly an expert in “people” and an IC in tech, managers should be able to tell ICs what to do for their career with way more details. It’s frowned upon for managers to micromanage “tech” decisions, but that is because ICs want to micromanage those. If an IC is not micromanaging their career, managers should be able to step in and manage him a least a bit more, not just pick the next likely to be promoted and focus on her.

Closing…

It may seem that I’m frustrated by what managers do, but I acknowledge there are a lot of baseline things they do well, and that’s not my focus of this essay. It also might sound like I am very passionate about management. In reality, I am too soft-spoken for any manager to think I’m fit for the job, and I agree I don’t meet the profile. But I couldn’t help but notice the conflict of interest in building a productive and efficient engineering team, that prioritizes the manager’s success on metrics like no. people managed and IC promotion/hiring history, and indexing ICs’ success too much on ostensible and vague things like project scope and leadership. Economics is my favorite subject to read for leisure, so every problem looks like a policy and incentive problem to me, rather than a junior/underperforming employee. The success of the product and the company is the ultimate goal. I think there’s a lot of room for improving the alignment between that and engineering management, instead of praying for the next superstar engineer/manager. Clearly, I sound like someone who doesn’t understand what managers do.

In this series: