Note: While this column is directed at all engineers, it is most applicable to group managers and above. Other engineers can still apply many of the suggestions or, at least, print out this column and slide it under the group manager’s door.
News flash! Microsoft is a business. Engineers cost money—roughly $250K per person per year (US), and that’s for the less expensive engineers. (This is fully burdened cost, which includes benefits, hardware, air conditioning, and the rest.) As a business, Microsoft expects engineers to deliver sufficient value to customers over time to pay for their salaries, management salaries, executive salaries, supporting services (like sales, research, IT, HR, finance, and legal), and other overhead and still turn a heathy profit.
News flash! Your group, led by the group manager, is a business. Your group owns a sufficient portion of the business for Microsoft to weigh the value it delivers against the headcount costs, lab spend, vendor spend, and other resources it burns every month. For years, Microsoft and other software companies have shielded their engineers from this fact. They want engineers to be creative and innovative without the burden of business considerations. Unfortunately, this balancing act is yet another leaky abstraction in the software world.
As an engineer, business considerations for your group impact your life in many significant ways, and I’m not just talking about rare events, like layoffs. Your group’s value delivered versus costs incurred determines your headcount (up, down, or flat), your mix of level bands (count of seniors and principals), your lab and vendor budget, and your personal annual rewards. That’s right—business results matter. Concerned? You should be. Don’t know what to do? I’m here to help.
There are always groups that seem to get more budget leeway. Typically, they are either poorly managed or proving out new technologies and markets. In all these cases, time catches up with you eventually and budgets need to balance. The clock is ticking.
Taking care of business
If you are a group manager, you are running a business. Sure, it’s part of the larger business of your division, and Microsoft overall, and thus must be aligned to those larger businesses. However, you’re still running a business. You have a budget, you have costs, you have customers, and you deliver products and services of value to those customers (internal or external).
The trick to running a small business effectively within a much larger business is having a clear sense of your group’s delivered value and incurred costs. You could compare your group to competing solution providers, determining their pricing, staffing, and overhead. However, most groups don’t have the skills or resources available to do such an analysis.
Instead, estimate your delivered value by order of magnitude: Is your group’s delivered value worth $1M/year, $10M/year, $100M/year, more? Be honest with yourself—don’t take credit for your whole division. How much would Microsoft pay to license your group’s products and services from a supplier? That will provide your delivered value per year.
As for incurred costs per year, ideally that would be captured in your group’s budget, but often it’s not so clear. Many of your costs may roll up to your division, and often the different disciplines in your group are part of different budgets. Instead, to estimate your costs, multiply the number of senior band engineers and below by $250K (including program managers), principal band engineers by $350K, and partners by $450K (rough estimates, but close enough). Then add your lab and vendor budgets, plus your budget for services like Azure. Don’t know—find out! Even charities track their expenditures.
Now you can compare your group’s value to its cost. Since engineers make up a little less than 40 percent of the company’s employees—yet the value they deliver must pay for everybody else—your group’s delivered value should be at least 2.5 times its incurred costs (and that’s just breaking even). Falling short? Finding excuses in my rough estimates? Good! You’re starting to think like a business owner.
For more on budgeting, read On budget.
I see red, I see red, I see red
By now, you’ve rationalized how your group’s delivered value is three to five times its incurred costs, but you don’t feel good about it. Maybe that’s because you’re working on future stuff that hasn’t shipped. Maybe it’s because you know you overestimated your value, underestimated your costs, or you simply sense your costs are too high compared to your competitors’ costs. I’m glad you’re growing up.
If your incurred costs are too high, restructure them. Do you need so many high-level folks or so many folks, period? Perhaps you can reassign some people to work on projects that deliver greater value. Perhaps you can trade some of your high-level people to a team that needs them in exchange for some lower-level people. Perhaps you can reuse components and services from other Microsoft teams or responsibly utilize open source. Perhaps you can cut your vendor or lab budget or renegotiate the pricing. Costs are not a given, and this is your business to run.
If your delivered value is too low, reprioritize and refocus. Perhaps you should drop that vanity project in favor of top customer feature requests. Perhaps you should fix your top customer support issues to reduce your overhead or otherwise reduce your technical debt to run more efficiently. Perhaps you should work on fewer features at once and shorten your cycle time (code-to-customer time) to better respond to customer demand and deliver more value in less time. There are many ways to increase the value your group delivers per month, and you can make that happen.
If your group is working mostly on future value (new technology), it’s easy for your incurred costs to vastly exceed your delivered value—after all, your delivered value is near zero. This is a problem. You could go back to enhancing legacy products instead, but that’s so boring and the new technology is so sexy! Hear that ominous music? Smell the blood dripping from the budget ax? Perhaps it’s time to rethink your definition of sexy.
For more on running lean, read Staying small and Span sanity—ideal feature teams.
A legacy of excellence
Many engineers associate legacy products and services with boring dead-ended technology that our competitors will soon overcome with their hot, new applets and bots. I associate legacy products and services with real delivered customer value, and oh my goodness is that sexy. (Fanning myself as I write.)
Why work on something that some customer someday might use, when you can work on real products that real customers are realizing real value from today? “But cars replaced the horse and buggy. I don’t want to work on a horse!” Then stop thinking of your legacy product as a horse. Think of it as transportation. Put a motor in the buggy that eases the work of the horse, using the horse as a starter. Next, beef up the motor and replace the starter, so you no longer need the horse. Now you’ve switched smoothly from horses to cars, while staying in the transportation business, delivering added value to your existing customers, and adapting to the changing and expanding market.
No market or technology stands still—you must move ahead and quickly adapt as things change. However, that doesn’t mean abandoning your current customers. Instead, embrace your customers, and help them navigate to a better future with higher productivity and better outcomes. That’s what we did by adapting Windows to the internet and Office 365 to services. It’s what we must continue to do with bots, the cloud, and mixed reality.
Yes, Microsoft failed to adapt our smart phone business (Pocket PC Phones) quickly enough to Apple’s iPhone approach. No company is perfect—Microsoft included.
For more on navigating to your desired outcomes over time, read The value of navigation.
Better learn balance
As you run your business, how do you balance investment in new technology and changing markets against keeping your current customers well-served with your current products and services? You create and maintain a balanced portfolio of work.
As I talk about in Agile Project Management with Kanban, my teams like to use McGrath and MacMillan’s Options Portfolio. We brainstorm or otherwise list all the major work we currently do or plan to do over the coming year (high-level items). We then place these items on a two-dimensional grid, using a table in Microsoft Word. (We put a glossary after the table to remind us what each item is.) The grid’s vertical axis shows increasing execution risk (technical or operational), and the horizontal axis shows increasing market risk (customer or competitive). The lower left corner tends to hold our current core work (like legacy support). The upper right holds our game-changing ideas.
For a balanced portfolio, your team’s work should spread across all portions of the grid—not enough in the core and your current business suffers; not enough in the middle and your customers will balk at your next major release; not enough on the edges and you’ve got no future business. You need balance to drive sustainable success.
For more on planning with agile teams, read Coordinated agility.
Let’s get down to business
Microsoft is not a charity. It is a for-profit business. Our primary competitors—Google, Apple, and Amazon, to name a few—are also for-profit businesses. Your success as an engineer depends on delivering high value at low incurred costs.
We’re getting close to the end of our fiscal year. Did you deliver some high-value items to your customers? Did you do so in a lean, low-cost way, reusing rather than reinventing, keeping quality high and rework and maintenance low? Is your team as small and low-level as it can be? Is it as efficient as it can be? Do other teams produce more with less?
Next time you ask for more headcount or a higher vendor or lab budget, consider whether that money is going to produce three to five times the investment over the next few years. Next time you dismiss updating your legacy solution to take advantage of new technology, consider how many customers and how much customer value you are throwing away.
There’s nothing more satisfying and profitable than delivering real value to customers every day. With a balanced portfolio of investment in current solutions, the next major improvements, and bold new ideas, your group can empower every person and every organization on the planet to achieve more. That’s what we’re here to do, and that’s what we’re paid to do. You make it happen by getting down to business.
Good stuff in general.
But I’m disappointed that there isn’t more detail about analysis. If you want to improve what your team delivers, there are two things that you need to know.
First, you need to know how much you are paying for non-new-feature work. What percentage of developer time is spent fixing bugs in existing products, responding to CSS requests, dealing with bad automation, attending meetings? The time that you are wasting here is a direct result of the decisions that you made over the past few years, but my experience is that many teams view customer bugs as a tax that is always going to exist rather than a waste to get rid of. This one not only costs you developer time (and focus), but it is damaging from a customer satisfaction perspective.
So, figure out the percentage and try to estimate how much each of those escaped bugs is costing your team and MS as a whole.
Second, figure out how your developers are spending their time. How long are they waiting for installs, for builds, for code reviews, for checkin queues? How often is they waiting on broken process in the team? What is your code review leverage vs return? Those are the simple ones. How skilled are your developers at writing the correct code the first time? How often do they write good unit tests? How often do bugs show up that slow the rest of the team down until they are fixed? Spend the time with the team analyzing the current state on an ongoing basis and invest the time to improve things. Many managers view their development teams as a group that can produce X amount of code in unit time Y, and don’t realize that with some analysis, a little investment of time, and maybe the willingness to do things differently the same team might be able to produce 2X code in the same amount of time.
[…] Long-rang planning. Eric says a real key here is planning around dependencies, and he likes the approach “Manual, social intensive” he writes about in Chapter 7 of his book, Agile Project Management with Kanban. He says another key here is using the McGrath and MacMillan Options Portfolio for a balcony view, which he also describes in his book in the same section, and in his post, It’s Business Time. […]