These are some principles of (engineering) management that have been floating around my head. I have observed many of them from great managers at organizations large and small.
However, nothing about the principles in this document are specific to engineering. They are general to any type of employee.
Job titles and leveling
Startups often begin without much of a hierarchy, which might be fine for a while, but there must be an eye towards some eventual organizational order.
What levels look like
If you're running an American-style corporation, typically your management hierarchy will look something like:
- Board of Directors
- Chief Executive Officer
- Other C-Level Officers (e.g., Chief Technical Officer, Chief Operations Officer)
- Vice President
- Senior Manager
- Individual Contributor
Individual contributors (ICs) can have their own parallel set of ranks, however. For example, an IC software engineer could have any of the following ranks from top to bottom:
- Principal Software Engineer
- Senior Staff Software Engineer
- Staff Software Engineer
- Senior Software Engineer
- Software Engineer II
- Software Engineer I
- Software Engineering Intern
It is important to set leveling in place early-on to:
- give employees a sense that their career has a continual logical progression while staying at your company.
- set consistent practices around compensation, slowly putting together the dataset that will eventually let you audit that compensation practices are fair across different demographics.
Engineering leader Camille Fournier has written in more detail about company job titles and how to level employees. Her book The Manager's Path is also a fantastic book to read about how to become a manager.
Becoming a manager should not be a requirement for getting promoted.
Employees who don't want to be managers should not feel pressured into becoming managers. This keeps people who are valuable as ICs, but would be terrible as managers out of management. Management isn't a rank--it's a field, like product management, design, or data science.
To facilitate to this, many companies peg an IC rank--like Senior Engineer--to be "equivalent" to Manager in terms of pay and prestige, but not responsibility in terms of direct reports. Then Staff Engineer is "equivalent" to Senior Manager and so forth.
Avoid lengthy homework assignments in the interviewing process.
When conducting software engineering job interviews, too many companies try to filter for great talent by requiring punitive homework assignments. This is an optimization for the middle of the job candidate pipeline that is costly for the company and brutally time-consuming for the candidate.
Ultimately, great candidates have other options and will not waste their time doing countless homework assignments at companies. Homework assignments ultimately end up selecting for desperate and probably-not-great candidates.
The right way to think about this is to divide the whole interview pipeline into three stages:
- The beginning of the hiring pipeline is how you source great candidates. If you are only speaking to inexperienced engineers, you will only hire inexperienced and poorly-referenced employees. If you are only speaking to experienced and well-referenced employees, this reduces the pressure on downstream filtering.
- The middle of the pipeline is how you filter candidates to find the ones that exceed your hiring bar. This is where onsite interviews, homework assignments, reference checks fit.
- The end of your pipeline is how you win the candidates that you want to hire--how you extend offers, compete against offer letters from other employers, and get excellent candidates signed.
Startups should optimize the beginning of the pipeline to more heavily weight it with pre-vetted candidates, and this will reduce their dependency on expensive homework assignments and other adversarial "middle" practices.
Large companies cannot behave this way because their hiring demands are too great, and they are also designed to train and mentor far greater numbers of junior employees.
Job candidates should know unambigiously who their manager is going to be.
Large companies often try to centralize and standardize their hiring process. As a result, they create a process that completely removes the first-line manager from the equation until the candidate has been presented with or even accepted an offer. This is typically too late in the process.
The choice of one's manager is one of the most important decisions that a candidate can make, and removing the manager from the beginning of the process selects against candidates that have strong opinions in what they want from a manager. If you are developing management practices for a startup, it is a competitive advantage to introduce job candidates to their potential manager as soon as possible.
Team members should always be allowed to transfer from one team to another--without restriction.
It is a common restriction at many companies that employees with poor performance reviews cannot switch teams without first improving their reviews. The goal of this regulation is to hold employees accountable to any problems that they may have caused on their original team and avoid new managers from unwittingly collecting problematic employees.
But there are two problems with this logic:
The performance review is not a review of the employee's performance in a vacuum. It is a measure of how well the manager and the employee work together in a team. The best shot for improving the employee's performance might be to find a better-fitting manager for the employee.
Poor managers now have the incentive to give bad reviews to employees they need to give around. Great employees that are trapped in this manner often have little resource other than to leave the company.
Managers are forbidden from poaching members of other teams.
This is a matter of trust between managers. While employees should not have restrictions for moving between teams (see above), it is also important that managers can share information with each other about their teams without worrying that they're setting themselves up for being raided.
Managers should look upwards in their org chart for resolving organizational disputes as opposed to attempting to quietly persuade employees from jumping ship from one team from another.
The manager : employee 1:1
First-line managers should have weekly direct 1:1 meetings with their IC reports.
If you are a first-line manager that does not believe in this advice because you have too many employees to run 1:1s, then you simply have too many direct reports. Either turn some of your reports into first-line managers or change your philosophy to see your employees more as vendors or service providers that manage themselves.
The ideal 1:1 is 30 minutes long and encouraged to be unscripted unless the employee has a problem that they want to work on with the manager. Ideally, the 1:1 is held in-person or via video chat, as it is important for the manager to pick up on social cues like eye contact from the employee.
The manager should not bring a script to the 1:1 to work on with the employee. If the manager has something they need to work on with the employee, they should schedule another meeting to keep the 1:1 as a place where the employee can use their voice.
Senior managers should have weekly or twice-monthly meetings with their direct manager reports.
First-line managers are expected to be very independent, so it is not necessary for their own 1:1s with their own (senior) managers to be weekly. Instead, these meetings can be twice-monthly.
Senior managers should have quarterly "skip" 1:1 meetings with their direct managers' IC reports.
The quarterly skip 1:1 is important for the senior manager to judge the performance of the first-line manager and diagnose potential issues in the company culture. All of thes 1:1s can be time-consuming for the senior manager, and the exact frequency of the skip 1:1s may need to be calibrated based on how many total employees are under the senior manager, but they should be frequent enough to be applicable feedback in the first line managers' performance reviews.
Performance reviews and promotions
Bad performance reviews should never be a surprise.
The weekly 1:1 should be a tool for tracking the employee's career progress, and a good 1:1 process discusses bad news or poor progress at the first sign of trouble.
A surprise bad performance review, even when seen as justifiable by the entire company except the employee who received the review, will always smack as retailatory to the employee who received it. Once again, the weekly 1:1 is the tool to pilot employees through good times and bad times on a real time basis.
Good performance reviews should never be a surprise (to others) either.
When someone is promoted from Engineer I to Engineer II, that promotion should be because they have been functioning at an Engineer II competency for some time. The promotion should be safe for the company to make and is a long-due reward for a job well done.
If this attitude is taken too far, the company can develop a culture of persistently underleveling employees, which will lead them to pursue higher titles and pay elsewhere. But the much larger threat for most companies is the promotion of someone that is unfit for the role. There is a significant danger for this transitioning an IC into a management role--given how different management can be.
The company should never "stack rank" or place promotions or performance reviews on a "distribution."
Stack ranking is the practice of rating employees against each other--and often penalizing the employees that rate at the bottom. Pioneered by Jack Welch at General Electric, stack ranking has been widely criticized for creating toxic company cultures. Microsoft was known to stack rank its employees--a behavior which countless employees attributed to the company's "lost decade"-- and Microsoft ultimately abandoned the practice in 2013.
The problem with stack ranking is that now employees that should be collaborating now have a bizarre side incentive for each other to fail. Employees' incentives are now entirely around the politics of their own review as opposed to the details of their work.
These are some of the best management books I have ever read.
The Manager's Path by Camille Fournier. As mentioned above, this is an extraordinary book on people management.
Powerful by Patty McCord. Patty pioneerd the iconic culture at Netflix, and in this book she lays out how you can build a similar culture.
The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz. This is founder and venture capitalist Ben Horowitz's legendary story of his time as President and CEO of Opsware, which HP acquired in 2007.
What You Do Is Who You Are by Ben Horowitz. This is Ben Horowitz's acclaimed followup book where he takes broader lessons from history and culture and applies them to business.
High Output Management by Andrew S. Grove. Andy Grove escaped Communist-controlled Hungary and eventually became the third CEO of Intel. He pioneered many of the engineering management ideas in this post and set the culture that much of Silicon Valley has adopted.
Only The Paranoid Survive by Andrew S. Grove. This is another excellent book from Andy Grove about how to build a strong business in the face of external threats.