eng mgmt ep3: Making tech things happen

This is episode 3 of my series on being an Engineering Manager (1, 2, 3, 4, 5, 6, 7, 8). In this ep we dive in to one of the most important things you should be driving: technical initiatives.

Any reasonable company has plenty of excellent people to cover the life cycle of business initiatives — projects motivated by the market that yield direct business results. Companies have sales+marketing+bizdev folks that bring in intel from the field, leadership that will analyze and prioritize these ideas, Product Managers that digest the intel and define how the product will meet these needs, and project/program managers who will handle all of the complex operational choreography to make these business initiatives come to life. Because the business initiatives are the business, most companies ensure that all the best people are in all the right places in all of these groups, such that the business succeeds. Cool.

But any experienced engineer knows that there is work beyond these business initiatives, that is imperative to keep the ship sailing. Whether it is technical debt paydown, future scalability or performance work, technical innovations and research, or opportunities to make the business or the engineers more efficient, there are plenty of things that should be addressed. These are technical initiatives — initiatives initiated and driven by Engineering.

Technical initiatives keep tech companies sailing. Sails keep sailboats sailing.

Fighting for technical initiatives

Guess whose job it is to make sure these technical initiatives succeed? Yours. There is no other role at the company whose job it is to identify what is needed, fight for these projects to exist, to make sure they happen, to make sure the team has the resources they need, to make sure they have the air cover they need. It is up to engineering leadership. That’s you.

You need to apply your effort, creativity, and diplomacy to get these things done, amidst all of the other stuff going on at the company, and you need to be single-minded in seeing them through to delivery. No one else can do that. Therefore, it is critical you spend a good amount of your time pushing for technical initiatives.

Now, the business won’t be able to work on everything you want to do all at once — that would have a detrimental impact on the critical business initiatives. But, you need to fight for some capacity for some engineering initiatives. You need to identify what is most important to do right away. You need to be able to articulate the business value of technical initiatives, so that you can carve out time to work on them. That’s your job.

How to do it

So here is what to do:

1. Make the list: If you are not aware of any technical initiatives that your team or the broader Eng org thinks are important, you need to create that list. Meet with the engineers — either 1:1s or in groups — and make sure you put together a prioritized list of initiatives. Prioritization is sometimes hard, because it will all seem very important. But this is where you need to put on your business owner hat, and have strict criteria for what rises to the top. Often, crowdsourcing priority is valuable/fun. You can employ a voting mechanism to allow everyone to lobby for what they think is most relevant.
2. If there’s no list: If no one has any suggestions for technical initiatives, then one of several things is happening: A) your team’s software is perfect in every way, ready for the future of the business, with no bugs or debt to remedy, B) your team doesn’t care about building high quality software that meets business needs —i.e., you have a culture problem, or C) your team doesn’t believe the business will let them solve these kinds of problems, meaning they have lost faith that the company cares about the them or their work. A is unlikely, and B or C is a problem you need to solve (more on this in a later episode).
3. Justify the work: Once you have your prioritized list of technical initiatives, you need to figure out how to get some of them done. To do so, you need to be able to explain to the business — the head of Engineering, your peers in Product, or any other interested party — why this work should supplant a shiny new product feature. It is certainly possible to do so! You just need to be able to speak the language of the business. More on this below.
4. Schedule the work: You may need to schedule the work for future cycles/months/quarters: presenting the business with an immediate “we need to fix X right now or else” (the nuclear option) should be a seldom-used tactic. But socializing the concepts, building consensus about approach, familiarizing the Product team with the plan, and getting it slated for an upcoming cycle is something you can do right now. If you are a fully agile environment, the execution could happen pretty quickly thereafter, or if your Prod/Eng planning works on a quarterly basis, you might not be able to get underway until next quarter. But that is okay — however long it takes, it is critical that you get these initiatives on the radar for an upcoming cycle.
5. Product the work: Once you know when these initiatives will be happening, you need to be the “Product Manager” for the initiative. Whatever PMs do for business initiatives, you need to do the same for technical initiatives — you need to author the user story, define the exit criteria, break down the work into stories or tasks, etc. You (or perhaps someone on your team) are the effective PM for the technical initiative, and you need to make sure you do it right. All of the PM artifacts and processes exist for a reason. Understand why they exist, and then make sure you are doing that same stuff for your technical initiative. This will help your technical initiative to A) have the same legitimacy as a business initiative, B) fit into your product development process easily and therefore be officialized, and C) more easily demonstrate success upon completion.
6. Drive the work: When the work is underway, you need to make sure it is getting done correctly, like you do with any engineering work. But, since you are also the PM for the work, you need to fill that role too. Think about what your Product team does, and make sure you are doing that for your technical initiative. But also — drive the team to deliver on schedule. Technical initiatives often can have unbounded scope: “make the product faster” or “remove technical debt” or “increase our test coverage” — and thus, in some sense, could go on forever. If you are rearchitecting or refactoring something, certainly it is important to consider the ideal design as you define the work. But if you and the team are shooting for the ideal design when you execute, you may never get there. This is a bad outcome for a technical initiative. So make sure you defined clear exit criteria in step 5, and then drive strictly to those.
7. Celebrate the work: This is the most important step. Once the technical initiative is complete, you need to be the cheerleader for your team — the folks who have worked hard to make this thing happen. Often this is some of the least sexy work: deleting code, refactoring modules, low-level performance improvements — hard, grueling work that doesn’t always receive the accolades it deserves. This is where you come in. You need to articulate to the business why this work was so important (often, the same arguments you made to the business when you were justifying the work). You need to get cupcakes and champagne, and gather the broader eng team, or the entire company, and proclaim the victory that was achieved, and why it is so impactful. You need to celebrate this important triumph. Doing so accomplishes two important things: 1) it reminds the business that building software isn’t just building features, and 2) it demonstrates to the team that tackling these types of engineering challenges carries weight — it matters, it’s rewarding, it’s meaningful. If you have any cultural issues from step 2, this is how you start fixing that.

A reasonable celebration after delivering a technical initiative

Justifying technical initiatives as business objectives

Every single project or task your team wants to work on can be justified in terms of the business impact — and you need to become an expert in drawing this connection, gaining consensus with the business, and mentoring your engineers to be able to do the same.

How do you justify highly technical work in terms the business can understand? If at all possible, focus on numbers and metrics. Let the data make the case for you. Here are some axes to consider as you make the business case for technical initiatives:

• Developer Efficiency — Salaries often make up a large portion of the company’s budget, particularly for software companies, and particularly for early-stage ones. And the Engineering department is often a large share of that. Engineers are expensive, and thus their time is very valuable. If you can make the case that time is being wasted or engineering velocity can be increased — that is a powerful argument. If your team wastes 20 minutes a day due to some tech debt or something, and your technical initiative fixes that, that is maybe 4% of their time that is recovered. If there are 10 engineers and the average overall comp is $150k, that means that this work will add $60k of capacity annually. Or maybe your initiative will positively impact the entire 100-person engineering team — that is $600k of extra capacity, or effectively four extra engineers’ worth of time — that’s huge!
• Scalability — this is an important one. Often, when first building some software, we rightly choose the most pragmatic way to do so. Once that software proves to be successful or valuable, then the focus needs to turn to how to support its success — will it work for a million users? Will it support the load of 1,000 customers? Businesses will always invest in their future growth, and evolving the technology to support that makes sense. But how and when you do that is important. First, you need to metricize this, like any other initiative. How much scale do you need to handle? What investment do you need to make to enable that? Don’t underinvest — if the work you’re planning will only support the next six months of the business’ growth, then you are going to have to do it all over again in that time. But, likewise, don’t overinvest — don’t spend your team’s precious time on the distant future, since by the time you get there, the needs or strategies might change.
• Risk — fear of bad things happening is a powerful motivator, and it is your job as a steward of the company to help insulate it from risk. You need to avoid scare tactics like “if we don’t refactor the flux capacitor, our servers will all crash”. You need to instead approach the risk scientifically. What are the odds of the bad thing happening? If the bad thing happens, what is the impact to the business (in lost revenue, in users cancelling their accounts, in percent of failed logins, etc). If you complete this technical initiative, how does it change the odds? Present this as a business decision: “There’s a 1% chance of up to $10M in lost revenue. If we do this work, it reduces the risk by 50%”. That means the technical initiative will reduce the expected loss by $50k. If it is 1 month of an engineer’s work, that is perhaps a $10k investment to save that $50k. Compelling, but certainly there may be other forces at work: perhaps the customer is a marquee customer, which will have a negative cascading effect, or something. Presenting in these terms will allow leadership to objectively evaluate the project.
• Reward — the opposite of “what bad things could happen if we don’t do this work?” is “what good things could happen if we do do this work?” A lot of technical initiatives are exploratory: exploring some new technology that you can factor into your product; prototyping a new product or feature; evaluating an integration with a third-party application. These types of exciting, innovative projects can often be a game changer for the company. Depending on the stage the company is in, carving out capacity for such a project could be easy or hard. Your job is to guide your team to break down a big exploratory project into milestones, each providing motivation for the next phase. Milestone A shows that the technology works, B shows that an integration is possible, C shows a prototype UI working, etc. At each of these accomplishments, you will then provide the business with evidence that the time has been well-spent, and the incremental investment in the next milestone has been merited by the success so far, and that it stands to benefit the company greatly if the results pan out.

How much of your team’s capacity should be devoted to technical initiatives? Well, that is a function of the current state of things — level of tech debt, its impact on productivity, risk of things breaking, etc. Sometimes when things are generally going swimmingly, the number is low, like 10–20% of capacity, and in other situations I have put a full 50% of the dev team’s capacity on technical initiatives. Your job is to make a smart business choice about how you allocate resources, and be able to explain that position to the business.

Make sure you are pushing forward technical initiatives that will support your company’s progress. And as your team succeeds in these efforts, make sure you broadcast their success widely. Good luck!

Photo credits: Matty Adame, Frankie Sutera

Eng Mgmt series by Matthew Vanderzee

• eng mgmt ep1: Should I become an Engineering Manager?
• eng mgmt ep2: What should I do today?
• eng mgmt ep3: Making tech things happen
• eng mgmt ep4: Goal-driven development
• eng mgmt ep5: Recruit great engineers or die tryin’
• eng mgmt ep6: Growth-oriented leadership
• eng mgmt ep7: Am I a good manager?
• eng mgmt ep8: So you want to be a Director (Quiz Show edition)