Engineering Managers Need To Understand What Levers They Have
A crane operator needs to know what levers he has in front of him, what each does, and which ones can compensate 1 for others, in order to operate the crane effectively. Similarly, you as an engineering manager or CEO also have some levers in front of you. You need to know what levers you have and how they work in order to run your team effectively. Let’s look at the levers:
Clock time (hours). This is just how many hours a project takes. If a project takes 100 hours and another takes 200, you should stop and think about whether the latter is commensurately more valuable.
Calendar time (months). Some tasks take a certain amount of calendar time like weeks or months irrespective of how many hours you spend on them. For example, hiring takes up to a year to yield the full benefit: a month or two to find the right person, then you make an offer, then they accept, then they serve their notice period of a month or two, then they take two quarters to ramp up. Put all this together and you’re looking at 3-4 quarters. You can’t speed this up beyond a point no matter how much you bash your head against the wall. So the only solution is to plan such activities ahead of time. Other activities can be sped up in calendar time. But this typically comes at a high cost in clock time: if doing something the right way takes 100 hours, waiting till the last minute and then scrambling takes 200 hours to achieve the same outcome. This doesn’t matter if you have one and only goal for your company, such as not going bust in six months. In such case, all that matters is whether you’ve achieved the critical goal. But typically, you have multiple goals, so you can’t afford to spend clock time inefficiently, since you’ll have no hours left over for your other goals.
Skills: Which skills do you have in your team, and which do you need? If you’re deciding between hiring a backend and a frontend engineer, whom should you hire? If you already have four backend engineers, perhaps you should hire a frontend engineer, since the fifth backend engineer will do little the first four can’t. Even if a task comes along that requires five backend engineers, it will be done 20% slower with four. On the other hand, not having a critical skill at all will stop your company in its tracks. If you’re not sure, err on the side of hiring for a skill you don’t have. Even if you’re sure, consider the possibility that you’re wrong, and consider the value of optionality. Plans need to be flexible to deal with reality: when reality doesn’t conform to the plan, as often happens, rigid plans fall apart.
Risk: When you buy insurance, you’re paying to reduce your risk. Similarly, there are some risks you can trade off. For example, you ensure a bus factor of two so that one employee leaving has only a limited impact. But this comes at price, namely that of keeping two people informed and up to date on everything. This is similar to the insurance premium. If you want to reduce risk, you have to pay for it. And, of course, you have to make a judgment of what risks are worth reducing.
Time horizon: This is the time period beyond which you don’t care what happens. For example, if your startup is going to run out of money in six months, you want to optimise to reduce that probability, even if it puts you in a worse position later on, because you’re at least alive to play the game. Depending on the project, you can have different time horizons of a month, a quarter or an year. If you’re building prototypes for multiple products to show to users to ultimately pick one, your time horizon is days or weeks, after which the prototype won’t matter. So paying attention to good coding practices is a bad idea in this case. How can doing something good be bad? The answer is that things are not good or bad; they’re good over a certain time horizon and bad over others. One founder I worked with on a project told me code quality doesn’t matter since we’re a startup and we need to move fast. It was a month-long project. In the first week, we saved a day by not caring about code quality. But in the last week, we wasted two days dealing with the bad code. His decision backfired. And many non-technical founders under-invest in code quality for the code horizon they need, because of a misconception that code quality matters over years, not months. So understand that optimising for a certain time horizon automatically means not getting an optimal outcome over a different time horizon, and what time horizon you’re optimising for, before you make a decision.
Like a crane operator, understand the levers you have and pull them appropriately, to run your team successfully.
Read more about the theory of constraints.
Needless to say, you shouldn’t trade off some factors at all, like treating people right, morale, ethics, making false promises, reputation or legal risk.