Resource Allocation: Race or Rate?

I was recently in a review with a team that was asking for additional resources. I strongly agreed that this team needed more resources but when I listened the case they made, I was not convinced. I thought I would share with you the coaching that I gave them.

Successful communications is all about what is heard, not what is said.  In order for the message you want to send to be heard correctly, you need to speak into someone’s listening. That is to say, the conceptual model that people have in their head is what defines what they are able to hear. You need to understand someone’s conceptual model and craft your communication accordingly. If you make case for additional resources that does not fit an executives conceptual model, they won’t hear your argument and you won’t succeed.

How do executives think about resource allocation?

Good executives think about resource allocation as Race or Rate?.  For any project, you are either in a race or your are making progress at a rate.  In a race, there is typically a time period where at the end, there is a winner and a loser.  When an executive decides that they are in a race, they allocate whatever resources are required to win.  You encounter few true races.  Most projects fall into the rate category – you are working towards a set of objectives and making progress at a particular rate. For the vast majority of projects, the only question is whether the rate of progress is appropriate.

The project under review had done a good job year after year and now were asking for additional resources.  It was clear that this would not get funded because they were not in a race and they did not make the case for why the rate of progress needed to be accelerated.

Now that they understand how executives think about resource allocation (Race or Rate?), they are getting crisp about their argument. When I drilled into their case, what they were really saying was while the rate of progress has been good, the competition is getting better faster than we are. Success is not assured. They need to gather the data to support their hypothesis but they are now on the path to make an argument that executives will hear and understand.

If you want to have effective communications, understand the conceptual model of the person you are communicating with and craft your argument so that you speak into their listening.

Working with Microsoft

A lot of people want to talk with Microsoft with the hopes of establishing a business relationship. Most of these engagements go nowhere because people don’t know how to have that conversation. I thought I would provide some insight into why these discussions fail and what you need to do to maximize your chances of success. While the advice I provide is critical for any dealings with Microsoft (at least my part of Microsoft), I think it is a best practice and applicable to any business engagement.

The most important thing to understand when dealing with people from Microsoft is this:

We all have ten jobs and our only true job is to figure out which nine we can fail at and not get fired.

Prior to joining Microsoft, I worked in environments where if you pushed hard enough, put in enough hours, and were willing to mess up your work/life balance, you could succeed. That was not the case at Microsoft. The overload was just incredible. At first, I tried to “up my game” so I wouldn’t fail at anything. I learned what everyone that doesn’t burn out and quit learns – that this is a recipe for failing at everything.

The great thing about the Microsoft situation is that it isn’t even remotely possible to succeed at all the things you are responsible for. If you had two or three jobs to do, maybe you could do it but ten? No way. This situation forces you to focus on what really matters and manage the failure of the others. If you pick the right things to focus on, you get to play again next year. Choose poorly and you get to pursue other opportunities.

What that means for potential business partners is that everyone you talk to is juggling way too many things and can’t afford to waste time. Any time they spend with you and your opportunity risks them screwing up the one job they can’t screw up and get fired. Of course if we are always looking for great opportunities so we often take these meetings but what that means is:

You have to do all the work.

Often these discussions have the flavor of “you’re great, we’re great, if we did something together, it would be great “.  Let me explain how someone consciously failing at nine of the ten things they are responsible for, parses a conversation like this. We ask ourselves the question, “does this have the potential to bring in a billion dollars* a year?” (Note – the precise dollar amount varies by the level of the person). If the answer is yes, then this is a conversation worth investing in but they’ll probably delegate it to someone to go figure out the details. An incredibly small number of conversations pass this filter so most of these conversations end with a frustrated smile and a hurried rush to our next meeting. I’ll also note that when someone comes in with something as fuzzy as this, it is generally an indicator that other parts of their business are equally unfocused and are unlikely to be a strong successful partner.

That doesn’t mean that we aren’t interested in smaller opportunities. The vast majority of our engagements are much smaller than that.  What it means is that you have to do all the work. Instead of a fuzzy story about potential synergies, you need to come in with a concrete theory of value amplification. Explain (in qualitative and quantitative terms) what the opportunity is, what you would do and what Microsoft would do and how that would generate value from the marketplace (vs getting money from each other) and how that differs from what others could do. The Geoffrey Moore Value proposition format is a wonderfully concise and precise for articulating this:

For <target customer> who <qualifying characteristic>, <joint offering> <value proposition>.
Unlike <competitor>, <joint offering> <differentiator>

A good example of this can be found in Section 10 of my Monad Manifesto.

When you present a story like that, it allows us to very quickly understand and evaluate the opportunity and can decide whether this is something worth pursing or not. I’ve had  lots of conversations where afterwards the Microsoft folks would huddle and ask each other “what they heck was that about?” and no one has a clue.  That doesn’t put you in the “I’d love to partner with them” category.

I sometimes wonder whether people are afraid of coming off as too bold or aggressive and want to take the slow walk the conversation. They spend so much time on the “your great, we’re great” portion that they never get to the ask before the meeting ends.  They wasted their time and they wasted our time and the odds are that the next conversation won’t happen.  At Microsoft we have a phrase:

Go big or go home.

If you are too timid to come out and make the your case, then do everyone a favor and stay home.

Successful engagements almost never end up the way anything starts off thinking about them.  The process is about exploring ways to amplify value based upon the strengths and limitations of both parties.  Presenting a clear theory of value amplification starts the conversation off on the right foot.  So remember:

If you don’t look like a $billion/year opportunity – you need to do all the work,

I hope that helps.

Jeffrey

Identifying Problems

Problems, like the poor, are with us always.  The trick is what to do about them.  I recently told my boss about a previous job where someone had resigned and during the exit interview, they cited a particular problem as the reason for leaving. Had I known about the problem, I would have happily addressed it but I didn’t know about it until the person was leaving the company.  The lesson is:

People can only solve the problems they know about.

Continue reading

Write-Host Considered Harmful

[2023 Update]  

I’ve been meaning to update this for a while.  The advice in this post is no longer current.  A while ago we changed the implementation of Write-Host to being a wrapper on top of Write-Information.  Prior to this, when you used Write-Host, there was no way to capture and process the data you wrote – because it just wrote to the host.  Now that it uses Write-Information, it goes through a path that writes to the host AND allows you to capture and process that information.
-Jeffrey Snover

[End 2023 Update]

When you are writing or reviewing PowerShell scripts, I’d like you to remember the following rule of thumb:

Continue reading

Evolution of a Script: Timing Operations

I just love PowerShell!  One of the things I love the most about it is that you can pick the level of programming you want, write a script and then evolve it to meet whatever need you have.  Sometimes you want something quick and dirty and other times you want something you’ll share with others and then other times you want something that is going to be used in production. Continue reading

On Heroes

Technology heroes are always difficult subject.  As an engineering manager, I remember the first time I participated in a “life boat” drill where you have to produce a stack rank of your engineers.  Someone explained the process saying, “The task is to figure out if you had to throw out one person from a lifeboat, who it would be?  After you figure that out, then you decide who would the next one be, etc. until you have a fully ordered list.”  I chewed on that a bit and asked, “How many people are going to be left in the lifeboat?”  When they asked me why, I replied “Because if there is only one person left in the lifeboat, it would be Mark but if there was more than one person left, Mark would be the first one I’d throw out.”  Mark was a technical hero.  Able to accomplish a great deal but at a great cost to the the organization. Continue reading

Iranian Drone Hack and Technical Debt

This week I read the story about how Iran hacked and captured one of our most sophisticated military drones. It struck me that this was an excellent example of the potentially disastrous ramifications of ignoring technical debt.  It appears that the potential to spoof GPS was known and ignored for many years.  Acknowledging and managing technical debt is an issue that separates the whiz kids from the graybeards in the tech industry.  Let me start by saying that a military boof-a-rama of this magnitude is, by necessity, going to be followed up with multiple misinformation campaigns so I doubt we’ll really know what really happened for a few decades.  Nevertheless it provides a teachable moment for us so let’s explore this topic. Continue reading