Little Things

“I have seen far too many people who upon recognizing today’s gap try very hard to determine what decision has to be made to close it. But today’s gap represents a failure of planning some time in the past.”
- Andy Grove

When you run a company, big things stay on your mind. Will we make the quarter? Did we hire the right engineers? Will the release be on time? Do we have a quality problem? Do we have enough money in the bank?

The Catch 22 is that if you attempt to act on those “big things,” you will usually do big damage. In order to move big things in a positive direction, it’s generally best to focus on little things.

If you are worried about the quarter, you might think that it’s a good idea to call your head of sales twice a day to get the status. By doing so, you might think you are creating the appropriate sense of urgency. In reality, you are just distracting her from closing the quarter twice a day. In fact, by radically overemphasizing the quarter, you will likely cause your sales leader to begin focusing on the cover up — the byzantine set of excuses that she will deploy in the case that she actually misses her number.

These excuses will then cause a new set of problems. She might say, "Why did we miss the quarter? We really did not get the right support from the product organization." So now you go over to the head of products to harass her. She’s responds: “What? If the VP of Sales wasn’t getting enough support, then why didn’t she say something to me?” Do you see what you did there? Not only did you fail to make progress on the sales issue, but you created a new political issue which will contribute to you missing the next quarter.

While it’s correct to worry about the big issues, you must resist the urge to act on them directly. Before acting, you should first translate the big thing into a related set of little things. For example, if you are worried about making the quarter, then you should go on a few sales calls and see if you are selling your product in the most effective way possible. Are your sales people properly trained? Do they run a process that puts your product in the very best light and sets appropriate traps for your competitors? Are you selling at the right level in the organization? Is your product truly competitive? As you get the answers to these questions, you will develop more constructive little things to take action on. These little things might not help you make this quarter, but they will certainly help you make next quarter.

Similarly, if you are deeply worried about engineering throughput, lamenting that your engineers don’t work as hard as other companies that you’ve heard about will achieve very little other than making your engineers think they are the “B” team. On the other hand, spending time going through their day and really understanding what’s slowing them down in the code base, where their build environment is working against them and how the communication overhead between groups slows them down might help a great deal.

This is true for almost anything in your company. You should set high-level goals, but those goals will or will not be achieved by the organization that you assigned them to. If you want to help them reach their goals, do so by focusing on the little things.

My old boss Jim Barksdale used to say that all of the knowledge was with the individual contributors and the customers. As CEO, you need to hire the right people and set a clear direction. Once you do that, you should fly low and fast rather than high and slow. Focus on the little things and the big things will take care of themselves.

Share

The Sad Truth About Developing Executives

The truth is hard to swallow, and hard to say, too
But I graduated from that bullshit, now I hate school

—Lil Wayne, "CoCo"

Coco | Listen for free at bop.fm

My greatest disappointment as CEO was the day I realized that helping my executives develop their skill sets was a bad idea. Up to that point in my career, I prided myself on my ability to develop people and get the most out of them. In my jobs running product management, product marketing and engineering, developing young talent was the most rewarding part of the job. Helping them learn to manage, improve their judgment and be more effective in their domains made my organizations better, and people genuinely appreciated the effort.

How could a great practice for a functional manager be a destructive one for a CEO? Let me count the ways.

You don’t have the skills. The first question that you must ask yourself is how are you going to develop a poor performing head of sales into a good one if you have never run sales? What exactly are you going to teach them? Would a sales VP who became a CEO be able to develop you into a better engineering manager?

You don’t have the time. A company depends entirely on the CEO for an important set of functions, which includes timely and high-quality decisions, clear direction, hiring a great team, and architecting and implementing a super-high-functioning communication architecture. Any time wasted trying to develop executives when you don’t even have the skills to do it takes away from the essential CEO functions.

They don’t have the time. A leader’s effectiveness is largely a function of how much confidence her followers have in her. If someone is running a large organization and doesn’t show competence immediately, her people will quickly write her off, and she will never recover. Executives have no time to be developed before they become useless.

Your results will suck while you work on a task that you cannot complete. It’s bad enough that you will work on something that you will add zero value to, but as you are doing that, the organization in question will continue to be awful. You will lose time and ground in the marketplace while you try and fail to figure it out. Meanwhile, everyone who works for that executive will be working in a crappy organization, doing crappy work and developing a crappy reputation for being part of it.

Executives are compensated for their existing ability, and therefore should not be evaluated on their potential. While it’s common practice and a good idea to take potential into account with regular employees, this methodology does not work well for executives. When you hire an executive, he will demand around 1 percent of the company. How do you explain to a great engineer with less than one-fifth that amount of stock that you are waiting for the executive’s potential to kick in?

Trying to help can make things far worse. If an executive is failing and you keep him around, thinking that you will develop him, things will get ugly quickly. You know he’s incompetent, so you will likely discount everything he says. When he raises a point in a meeting that contradicts a high-performing executive, you will take the high-performer’s side 100 percent of the time.

This will make your failing executive feel badly, but more importantly, it will completely destroy the credibility of the function that he is running. If the exec is, for example, the head of marketing, everyone in the rest of the organization will draw the conclusion that marketing is unimportant in your company. That conclusion will be surprisingly long-lasting.

While you cannot develop an underpowered executive into a high-performing one, there are several things that you can do in your role as his manager that will help all of your executives succeed.

Provide the proper context. When you hire an executive, she may know her function, but she does not know your company. She does not know your management philosophy, the top performers, the history of the decisions that were made, how product flaws were created and fixed, etc. This information will be invaluable to her success and you should invest heavily to make sure that she quickly gets all the context she will need.

Be very clear about the rules of the game. You should be extremely clear up front that you expect your executives to be world-class in their functions. If they are not, they will not keep their jobs. Furthermore, you will not be able to make them world-class, because you are not world-class in their areas.

Know what you want, and be clear about it. Tell them what you think world-class performance is. If you don’t know, go find out by interviewing some world-class CEOs and world-class executives, and then tell them.

Be clear about relative performance. If you think your marketing is not as good as other companies in your sector, then let your head of marketing know. If you know that other companies generate five times the number of qualified leads than you do and you don’t understand why, then say something. This will make it much easier for you to make a swift decision if your executive does not know what he is doing.

In the end, a CEO has got to know her limitations.

 

This post first appeared in Re/code

 

Share

The Past and Future of Systems Management

“I said that I’mma ride for my motherf*ckin' n***as
Most likely I’mma die with my finger on the trigger
I’ve been grindin outside all day with my n***as
And I ain’t goin' in unless I’m with my n***as
My n***as, my n***as
My n***as, my n***as (My muthaf*cking n***as!)
My n***as, my n***as (My n***as, my n***as)
My n***as, my n***as"

—YG, “My N***a”

My Nigga | Listen for free at bop.fm

Ten years ago I had a big problem. I was CEO of Opsware, a systems management software company, and we were losing a lot of deals to our major competitor, BladeLogic. We were losing, because they had a better product. There were many reasons for that, starting with the fact that we never designed Opsware for broad based usage, but in a desperate move, had yanked it out of our cloud computing business, Loudcloud, and began to offer it as a commercial product. As a result, Opsware worked okay for some, but was not ready to go up against an excellent competitor. Naturally, nobody cared about our excuses and our business was spiraling down the drain. 

When I fully realized what was happening, I went to see my chief architect, Phil Liu to tell him the bad news. He and I meticulously went through the details of why customers thought BladeLogic's product was better and why they were probably right. It was a come to Jesus moment, but Jesus wasn’t there, so it was up to Phil and me.

As Phil thought through the implications of re-architecting the product and how little time he had to do so, his face told the story. It said: “Oh fuck, this is going to be hard if not impossible and the company is going to die if we don’t figure it out. But we will figure it out or die trying.” When I saw that look, I thought: “My guy."

After nine months of grueling effort by Phil and the team, we released our new product code named Darwin. As soon as it hit the market, our win rate went from sub 50% to 80%. We had done it. It was a new day and we weren’t going to squander it. I will never forget that moment with Phil. When things go perfectly in a company, it’s sometimes difficult to differentiate amongst good employees as everyone consistently beats their objectives. However, when things go horribly wrong, the greatest people distinguish themselves. Phil could have made many excuses and blamed many people — most of all me. But, he would have none of that. Instead, he simply found his greatness. 

Years later, HP acquired Opsware and Phil went on to design a system for monitoring and managing a leading, massive, billion-user application called Facebook. Because Phil intimately knew the traditional systems management market, he quickly realized that the traditional systems would not work for modern, massive, cloud-based architectures. In fact, they would not work properly for cloud-based architectures of any scale. A new system had to be developed. The reasons were several:

Traditional systems are server centric — Even relatively modern systems management products like New Relic treat servers as sacred resources which must be kept alive, but Facebook loses servers every day and it doesn’t matter. Facebook doesn’t care about servers; they care about services. Knowing when a cluster of services that provides, for example, an identity service is out of capacity is critical, but getting paged in the middle of the night because you lost one server in a cluster of 20 is asinine. 

Developers are central to the business — Developers are now playing a much more critical role in the business and need an application intelligence solution the same way marketers need business intelligence. Developers need to answer questions like: Which APIs are being used the most frequently by which customers? Is a sudden spike in latency for my top customers the result of an increase in load or some upstream service using my APIs inefficiently? Which customers are taxing my infrastructure in the most expensive way? How should I think about scaling my systems if my user base were to double?

Monitoring is now an analytics problem — How many milliseconds should a packet take to travel from the database to the application server for the photo app? Don’t feel badly if you can’t answer that because it would be a silly thing to know, yet monitoring systems have wanted people to know such things for years. How about a system that reports the moving average and anomalies such as 3 standard deviation variances from it? 

Applications are now a collection of micro-services — These micro services are often managed by separate teams with all sorts of upstream and downstream dependencies. Having a solution that tracks all the relevant metrics across all the services fosters a much more collaborative environment where teams can communicate with one another (versus logs, where only the developer who wrote the app can really understand what's going on).

Time is money — Facebook is now a $10 billion company. That means that if the site is down for an hour, that’s roughly $11.5 million. So, logged data and dashboards that aren’t real-time won’t cut it. Every second counts and a proper system must enable you to see all of the data in real-time. 

After building a system, which solves the above and serves Facebook amazingly well, Phil co-founded SignalFx with another stellar ex-Loudcloud employee and legendary VMware executive, Karthik Rau. Together, they have built the systems management product of the future. The current product is amazing, but more importantly, Phil and Karthik will make sure that it remains the best product for a very long time.

I am so pleased to announce that Andreessen Horowitz is an investor in SignalFx.

Share

Learning from My Mistakes

"The campaign is global - the dollar ain't what it used to be
Switch a franc for a dollar, you get like 1.3"
—Ryan Leslie, Swiss Francs

Swiss Francs | Listen for free at bop.fm

Three years ago I made an investment decision that I have regretted ever since. 

My friend Sten Tamkivi told me about a great new company founded by his old Skype colleague, Taavet Hinrikus. Naturally, I reached out to Taavet to hear his pitch. 

The basic idea for the business came from a personal need.

Taavet had worked for Skype in Estonia, so was paid in euros, but lived in London. Kristo, his co-founder, worked in London, but had a mortgage in euros back in Estonia. Simply getting money from their paychecks cost them 5%. They thought that was outrageous. Since Taavet and Kristo were friends, they devised a simple scheme to solve their expensive problem. Each month the pair checked that day’s mid-market rate on Reuters to find a fair exchange rate. Kristo put pounds into Taavet’s UK bank account, and Taavet topped up his friend’s euro account with euros. Both got the currency they needed, and neither paid a cent in hidden bank fees. That became the core idea for TransferWise.

Kristo’s background in financial services and Taavet’s background building a very large scale, peer-to-peer software system gave them the perfect backgrounds to tackle the problem. On the one hand, TransferWise was exactly the kind of thing that we like to invest in: two great founders who had discovered an important problem that they were eminently qualified to solve. On the other hand, they were based in London and I could not see how I would have the time to help them start a company from half way across the world, so I passed on the investment. I chose the wrong hand.

After I passed, Taavet and Kristo went straight to work. They built a peer-to-peer foreign currency exchange in the same way that the original Skype was a peer-to-peer phone system. Like the original Skype, Kristo and Taavet built in enough central components to make the network work seamlessly and flawlessly for consumers. Kristo's banking industry expertise enabled them to complement their peer-to-peer network with an impressive international banking network, which made every currency exchange work and work quickly. Once they got it up and running, the business worked beautifully. 

When funding new products, a good rule of thumb is that the new product must be at least 10 times better than the old way of doing the same thing or customers will stay with what they have. It’s an easy concept to understand, but sometimes a difficult one to quantify. Not so with TransferWise: A typical FX transaction costs a consumer 5% and TransferWise profitably charges 10 times less for the exact same transaction. Ten times better indeed. In addition, the customer experience is amazing, yielding an 80% NPS score, which is unheard of in financial services. 

From a macro perspective, such innovation could not come at a better time. Due to the financial system nearly destroying the global economy in 2008, traditional banks have been under incredible pressure from regulators to reduce their leverage from highs of close to 40:1 to less than 10:1, forcing them to dramatically cut costs to fit into their safer cost structures. As a result, we see little to no innovation from the traditional banking sector, which creates a massive opportunity for new financial institutions like TransferWise. 

It should not be a surprise that TransferWise’s resulting performance has been spectacular and makes my original decision to pass look worse and worse every day. Since launching in early 2011, TransferWise has grown to a team of 250 providing 292 currency routes. They continue to grow 15-20% per month and have helped customers transfer £3 billion, saving users over £135 million.

For all these reasons, I am absolutely thrilled to announce that I am correcting my mistake and a16z is leading TransferWise's $58 million round, the money transfer platform of the future.

Share

One Management Concept

 

One Management Concept

Lecture for Sam Altman's How to Start a Startup class, CS 183B at Stanford University (November 2014); the slides are available here. 

Share

Making Any Web App Mobile: The Capriza Advantage

"Even if it's jazz or the quiet storm
I hook a beat up and convert it into hip-hop form"
-Rakim, "I Ain't No Joke"

Rakim - I Ain't No Joke | Listen for free at bop.fm

Over the past 20 years, enterprises have spent over 3 trillion dollars building web applications, but now most of their users would rather access those applications from mobile devices as mobile is indeed eating the world. In related news, most people think that packaged enterprise web applications suck and suck worse when they move to mobile. If you run a company and need your people to have the right information and the right tools to make decisions in a timely fashion, then these are big problems. 

The conventional wisdom has been to rebuild the most important applications by hand on mobile or wait for the big vendors to provide acceptable mobile solutions. The conventional approach has several problems:

1. Workers aren't partially mobile -- Many companies have 100s of internal applications. If employees can only get to 2 or 3 of them via a mobile device, they are not actually able to be mobile and they are certainly not able to exclusively use a mobile computing device. 

2. Big enterprise applications don't fit on a phone -- SAP has 300,000 screens. I don't care how great a designer you employ, you can't make a 300,000-screen application usable on a phone. Of course, most users don't need all of SAP. They might only need to see a forecast or retrieve the number of a key supplier via their phone. There ought to be a way to do this customized for each user and use case. 

3. Security and manageability -- If you do hire people to rewrite your web apps in mobile, chances are each app will have its own security model and its own management hooks, which look nothing like any of the other mobile apps. Your mobile solution will soon turn into a mobile nightmare. 

4. Cost -- In addition to the "rewrite your apps" approach being incomplete, impossible to use, insecure, and unmanageable, it's incredibly expensive. Even using the best development tools, building a fresh mobile app to replace a web app typically costs around $250,000. Multiply that by 100 and you have one big expensive mess. 

For all these reasons, led by Yuval Scarlat, the team that revolutionized software testing at Mercury Interactive is now doing the same thing for mobile application development at their new company Capriza. Rather than re-implementing every web application by hand, Capriza simply observes you using a web app and automatically constructs a mobile app with the same functionality. You take from the web app only what you need and will find useful on mobile -- not 300,000 screens. Capriza is so robust that it can translate virtually any piece of any web app into a mobile app including the SAP colossus. Beyond that, every Capriza app comes with an integrated and consistent security and management model, so the more apps, the better. 

For any company with a big investment in web applications and a real need to mobilize its workforce, Capriza is a magical solution. That's why I am extremely excited to be an investor and board member.

Share

The Prophets of Rage

"You're quite hostile,
I've got a right to be hostile,
my people been persecuted."
- Public Enemy

Public Enemy - Prophets Of Rage | Listen for free at bop.fm

A while back I wrote a post called "When Smart People are Bad Employees." In that post, I wrote about employees that you think will be incredible, but turn out to be destructive. The other day, my partner Lars and I were talking about the opposite: employees who appear to be destructive, but if properly managed can be spectacular. In reference to hip hop's great prophet Chuck D., I call them "The Prophets of Rage."

If you've worked in a company for any length of time, you've probably seen one of these prophets. People refer to them as glass breakers, cowboys, toe stompers, or just plain assholes. Yet it's difficult to get rid of them, because they produce massive amounts of high-quality work. Beyond that, they have indomitable will. No obstacle is too great, no task too large, no problem is too hard and they do not care who they offend, upset, undermine, or piss off to get the job done. In fact, they are so self-righteous that it's difficult to even have a conversation about the right way to do things, because in their minds if they are doing it, it must be right. If you are not them or not on their team, you are very likely "a lazy idiot" or worse. Even if they don't call you names outright, they will deliver searing, totally impolite insights that will cause you to question your own motivations. They specialize in making people uncomfortable.

Their backgrounds are almost never consistent with the typical hiring profile. They do not come to you right from central casting. Often they grew up poor and went to the wrong schools. Or they were the “wrong” religion, sexual orientation, or skin color. In general, they believe that they grew up on the wrong side of the tracks and everybody is judging them on that all the time. They will walk through fire to prove everyone wrong. They have to succeed and are willing to do whatever it takes.

This is not to say that everyone with this background is a Prophet of Rage, just that Prophets of Rage tend to have this background.

These employees are the corporate version of W.M.D.s. The ultimate weapon in any arsenal, but their deployment can lead to highly unpredictable consequences. How can they be used as a force for good? How can you prevent them from destroying your culture and possibly your company?

When managing a Prophet of Rage, the first thing to understand is that they often dish it out much better then they take it. While they won't hesitate to viciously attack their peers and bring them to tears, even the slightest criticism from a prophet's manager may cause him or her to go into a deep funk and become incredibly depressed. Most managers will find this behavior to be totally ridiculous and give up when they see it. Most managers will forfeit greatness at that point.

Prophets of Rage are perfectionists. They work harder than anybody in the organization and expect total perfection from themselves and everyone around them. When they see others deliver sub par work or sub par thinking, the Prophets become enraged and lose all control of themselves. But it's the same dynamic that enrages them and causes them to stomp on other people's toes that makes them recoil at any criticism: they have dedicated their entire life force to doing great work; any rejection of their work is a rejection of them personally. Keep in mind that a prophet's background makes her a bit paranoid about you wanting her there in the first place, so if she doesn't become depressed, she will certainly question your motives.

In my experience, there are at least three keys to managing these super high performing, super volatile personalities.

1. Don't give them feedback on their behaviors, give them feedback on what their behaviors mean

If you tell a prophet, "It is totally unacceptable to scream at your peers in meetings," he will hear: "It's totally unacceptable for you to scream at people in meetings, but others can do it all they want, because I am out to get you." In the prophet's mind, everyone is out to get him, so this is the logical reaction.

A better approach is to focus on how the behaviors were interpreted by the other people in the room. "You have a very important mission, but when you screamed at Andy that his team was blocking you from your goal, his response wasn't to work harder to unblock you. His reaction was to get you back for embarrassing him in public. Your method was totally ineffective." He will initially bristle at the criticism, but when he thinks it through, he will realize that you were right and he will work extremely hard to fix it, because he is, after all, a perfectionist.

2. Realize that they will never be completely accepted in polite society

No matter how clearly and effectively you coach a prophet, you will be unlikely to completely transform her. She has spent her entire life getting to this point, so words from her manager won't get her to the point of corporate acceptance. The more people don't accept her, the worse the behaviors will become, because the rejection will reinforce her life narrative and increase her rage. The more effective approach will be to do your best to moderate your prophet while letting the rest of the team know that you expect them to accept her due to her incredibly high productivity. If they believe that you won't flinch, they will meet her half way. It's absolutely critical that they do this, because she will never be completely congenial.

3. Coach them on what they can do

If you keep in mind that your prophet is paranoid, then you will realize that giving entirely negative feedback will not work. Rather than focusing on what he is having trouble with or can't do, spend most of your time working with him on what he can do. This will enable his true super powers to come out and take your company's production out of the stratosphere.

Even with the best coaching, it's quite possible that a prophet has too much rage to function in an organization as it grows. At this point, they become smart people who are bad employees and there may be nothing that you can do. 

In the end, realize that a talented Prophet of Rage may be the most powerful human force in your company. Your challenge is to help that be a force for good.

This post first appeared in Billboard.

Share

The New Foursquare

"Damn, here we go again
People talking shit, but when shit hit the fan
Everything I'm not, made me everything I am"
—Kanye West, "Everything I Am

 Audio version of the post

Kanye West - Everything I Am | Listen for free at bop.fm

In 2000 Dennis Crowley founded a company called Dodgeball, which built an application that ran on your not-so-smart phone. The point of Dodgeball was to link up with your friends and discover new things to do. It was great fun for extremely social, high tech geeks. The founders eventually sold the Dodgeball to Google in 2005. 

In retrospect, Dennis observed something about Dodgeball that he believed would be the key to creating a magical product. Because Dodgeball captured where people really were and therefore what they actually liked to do, the data set could be the basis for the greatest local recommendation engine that the world had ever seen. Rather than finding out about local businesses via payola and advertising schemes, people could get real information based on where their friends and people with similar tastes actually went. He could build a system based on accurate data rather than perverse incentives. The product would truly make cities more usable. 
 
Obsessed by his observation, in 2009 Dennis co-founded Foursquare. This time, he was building on the smart phone platform, which had things like GPS making the original dodgeball functionality more powerful and the data set richer. From a feature standpoint, Foursquare started out much as Dodgeball before it, but always evolving towards the vision of being the ultimate local recommendation engine. 

Along the way the team added many features designed to make cities more usable. The cumulation of this work was a breakthrough mechanism called Pilgrim. Pilgrim enables a user to "checkin" without ever having to take her phone out of her pocket. Without ever taking action or even opening an app, a user who loves sweets instantly discovers that a local bakery has the bomb ass cupcakes.  This magical functionality was made possible through over 6 billion checkins, which enabled the Foursquare software to figure out the exact shapes of over 60 million venues. Such data exists nowhere else in the world today. 

Despite the breakthrough functionality, the application itself did not feel quite right. Combining the database building social networking features with the local recommendation service meant putting two very different sets of use cases into one app. Most problematically, this meant two separate privacy models. While you probably want every Foursquare user to see your recommendations, you definitely don't want them to all know where you are. Most users find two privacy models in one app to be quite confusing.  

For the past year, the Foursquare team has been working to solve this important problem. They recognized that although the local social networking features had been an essential part of building the data set, with Pilgrim in place, they were no longer needed for the recommendation portion of app. So they split the app into two: 1) An app to keep up with your friends: Swarm 2) An app to get the most relevant and honest recommendations imaginable: the new Foursquare. The old monolithic Foursquare is now two apps with very straight-forward, super clean privacy models and consistent use cases. 

When you try the new Foursquare, you will understand exactly why splitting the app in two makes perfect sense. The new products are straight-forward, easy to use and truly unlock the best of what cities have to offer. And, if when using the new Foursquare, you miss the features of the old monolith like checking in, just remember that everything Foursquare is not made it everything it is. 

Share

How to Ruin Your Company with One Bad Process

“Real quick, whole squad on that real sh*t
0 to 100, n***a, real quick”
—Drake, "0 to 100/The Catch Up"

For the audio version of this post click here.

Drake - 0 To 100 / The Catch Up | Listen for free at bop.fm

I am a giant advocate for technical founders running their own companies, but one consistent way that technical founders deeply harm their businesses is by screwing up the budgeting process. Yes, the budgeting process. How ridiculous is that? How does it happen and why is it particularly problematic for engineers?

I'll begin by describing how I screwed it up in my company. Our sales were growing so fast that the biggest problem that we faced was that we literally could not handle all the customers that wanted to sign up for Loudcloud. To combat this and enable us to grow, I worked diligently with my team to plan all the activities that we needed to accomplish to expand our capacity and capture the market before the competition. Next, I assigned sub-goals and activities to each functional head. In conjunction with my leadership team, I made sure that each goal was measurable and supported by paired metrics as well as lagging and leading indicators. I then told the team to figure out what it would take to accomplish those goals and return with their requirements for headcount and program dollars. Finally, I made adjustments to their requests based on industry benchmarks (mostly reductions) to get to a plan that I thought made sense.

Here’s the basic process:

  1. Set goals that will enable us to grow
  2. Break the goals down so that there is clear ownership and accountability for each goal by a specific team
  3. Refine goals into measurable targets
  4. Figure out how many new people are required to hit the targets
  5. Estimate the cost of the effort
  6. Benchmark against the industry
  7. Make global optimizations
  8. Execute

Unless you are an experienced manager, you may not even see what’s wrong with this process, but it very nearly led to my company's demise. In fact, the above process is completely upside-down and should only be followed if you wish to bloat your company to the brink of bankruptcy and create a culture of chaos. 

When I asked my managers what they needed, I unknowingly gamified the budgeting process. The game worked as follows: The objective was for each manager to build the largest organization possible and thereby expand the importance of his function. Through the transitive property of status, he could increase his own importance as well. Now you may be thinking, "That wouldn't happen in my company. Most of my staff would never play that game." Well, that's the beauty of the game. It only takes one player to opt in, because once someone starts playing, everybody is going in -- and they are going in hard. 

Gameplay quickly becomes sophisticated as managers develop clever strategies and tactics to improve their chances for winning. One common game technique is to dramatically expand the scope of the goals: "When you said that you wanted to increase our market presence, I naturally assumed that you meant globally. Surely, you wouldn’t want me to take a U.S.-centric view." To really motivate the CEO, another great technique involves claiming dire circumstances if the company fails to achieve its metrics: "If we don't increase sales by 500% and our top competitor does, we will fall behind. If we fall behind, we will no longer be No. 1. If we’re not No. 1, then we won’t be able to hire the best people, command the best prices, or build the best product, and we will spin into a death spiral." Never mind the fact that there is almost no chance that your competitor will grow 500% this year. 

Another subtle problem with this process is that when I asked my team what they needed to achieve their goals, they naturally assumed they would get it. As a result, my team deeply socialized their ideas and newly found money with their teams. This has the added gaming benefit of inextricably tying their demands to company morale. When the VP of marketing asked me for 10 headcount and $5M in program expenses, then shared that plan with his team, it changed the conversation. Now a major cutback to his plan would alarm his team because they had just spent two weeks planning for a much more positive scenario. “Wow, Ben greatly reduced the plan. Should I be looking for a job?” This kind of dynamic put pressure on me to create a more expansive expense plan than was wise. Multiply this by all my managers and I was on my way to burning up all my cash and destroying my culture. 

My core problem was that my budgeting process did not have any real constraints. We were private and did not have a specific profit target that we needed to hit and we had plenty of cash in the bank. Drawing the line on expenses seemed rather arbitrary. In the absence of a hard constraint, I had no constraint. 

An excellent constraining principle when planning your budget is the preservation of cultural cohesion. The enemy of cultural cohesion is super-fast headcount growth. Companies that grow faster than doubling their headcount annually tend to have serious cultural drift, even if they do a great job of onboarding new employees and training them. Sometimes this kind of growth is necessary and manageable in certain functions like sales, but is usually counterproductive in other areas where internal communication is critical like engineering and marketing. If you quadruple your engineering headcount in a year, you will likely have less absolute throughput than if you doubled headcount. As an added bonus, you will burn way more cash. Even worse, you will lose cultural consistency as new people with little guidance will come in with their own way of doing things that doesn’t match your way of doing things. Note that this does not apply to you if you have very small numbers. It's fine to grow engineering from one to four people or from two to eight. However, if you try to grow from 50 to 200, you will cause major issues if you are not extremely careful.

Starting with the cultural cohesion principle, a far better way to run the budgeting process is to start with the constraints. Some useful constraints are:

  • Run rate increase – Note that I say "run rate increase" and not "spend increase". You should set a limit on the amount by which you are willing to increase what you are spending in the last month of the coming year vs. the previous year. 
  • Earnings/Loss – If you have revenue, another great constraint is your targeted earnings or loss for the year. 
  • Engineering growth rate – Unless you are making an acquisition and running it separately or sub-dividing engineering in some novel way, you should strive not to more than double a monolithic engineering organization in a 12-month period.
  • Ratio of engineering to other functions – Once you have constrained engineering, then you can set ratios between engineering and other functions to constrain them as well. 

 After applying the global constraints, the following steps will provide a better process:

  1. Take the constrained number that you created and reduce it by 10-25% to give yourself room for expansion, if necessary.
  2. Divide the budget created above in the ratios that you believe are appropriate across the team.
  3. Communicate the budgets to the team.
  4. Run your goal-setting exercise and encourage your managers to demonstrate their skill by achieving great things within their budgets.
  5. If you believe that more can legitimately be achieved in a group with more money, then allocate that manager extra budget out of the slush fund you created with the 10-25%.

At this point, some readers may think that I've lost my mind. As a technologist, you know that the worst thing that you can do is over-constrain the problem before you start. You'll kill creativity and prevent yourself from getting a truly great outcome. That's precisely why I, as an engineer, struggled with this process: the human factors muck up the logic. Specifically, local incentives, if not properly managed, will sharply motivate human behavior and defeat the global goals. 

It’s critical to recognize this so that you don’t turn your agile, small company into a slow, big company before its time

Share

Do You Feel Pressure or Do You Apply Pressure?

"To whoever think their words affect me is too stupid
And if you can do it better than me, then you do it"
—Kanye West, "Cold"

Kanye West, DJ Khaled - Cold.1 | Listen for free at bop.fm

One obvious yet under-appreciated law of business physics is: For any given company, the larger the company becomes, the more opportunities emerge to screw it up. 

Another obvious, but not well understood law: The more screwed up your company, the more people will complain about it and blame you.

If we take these two together, it is easy to see that without intervention the larger your company becomes, the more people will complain and blame you. 

This seems simple enough, but CEOs often fail to understand the logic, become overwhelmed by the criticism, lose confidence in themselves, and decide that they are no longer capable of running their own companies. This can be tragic as I explained in “Why We Prefer Founding CEOs”

If you are a logical and open-minded person, it is difficult not to take a 10X increase in criticism seriously. More importantly, it's difficult not to take a 10X increase in criticism personally. So how can a CEO keep from getting ground into sawdust by complaints from her own people? The answer comes from a simple CEO aphorism: You either apply pressure or you feel pressure

Let's begin by looking at the overwhelming spiral. As your company grows, people start complaining about everything from your sales efforts being underwhelming to there not being enough organic snacks in your free food section. In the meanwhile, you are trying to wrestle serious product strategy questions posed by scary competitors to the ground. You don't know the answers to most of the complaints, so you defer them and focus on what you know. The problems related to the complaints fester and grow. Your employees get frustrated that the issues are not being fixed and complain louder. They begin to lose confidence in you as CEO.

The Best Defense is a Good Offense

The key to breaking the cycle is to stop feeling pressure and to start applying it. The most basic way to do this is to assign the problems to your team. This transfers the pressure from you to the organization and has the added benefit of empowering the team. 

At this point, those of you who have read my book are thinking: "Ben, that's not the hard thing about this. The hard thing isn't delegating, the hard thing is when the executive disagrees that there's a problem or there is no logical owner or the problem is cross-functional or the executive tries to give it back to you." Let's take these in order. 

The executive fundamentally disagrees that there is a problem
Imagine that your employees are complaining about the number of bugs in your product and you ask your head of engineering to improve quality. Chances are that he will not say: "Sure thing, boss." He will much more likely say: "By what definition?" He will likely have way more data than you about product quality and it will be difficult for you to win the argument. Yet you know the employees are right, which is why you didn't explain to them they were wrong in the first place. 

The reason for the stalemate is that quality in the abstract is an intractable problem. In fact, most problems in the abstract have this property. If you want it fixed, you must be specific. Doing so is tricky in this case because no software organization has ever produced bug-free software in every version. So if you don't want zero, then how many bugs are too many? The best way to start is to frame it in terms of something that you know well. Sometimes this will mean moving to a more qualitative argument. For example, pick your 3 favorite bugs and use them as examples. Describe why they are particularly damaging and try to classify them as best you can. Let your executive know that bugs like that should not ship and if they do accidentally ship then the company should not rest until they are fixed. Then ask him to do something specific: have him tell you exactly how many bugs are outstanding in the classes that you identified and report back on when they will be fixed. Then ask him to make a proposal about how he will systematically do a better job on this in the future. Finally, let him know what you are willing to give up in terms of other work (schedule, features, etc.) to make this a priority. Getting specific will help energize the team as it will give them a problem they can actually solve. It will also clearly communicate that you are super serious about the issue. 

The problem is cross-functional
Imagine that your sales people keep complaining that there aren't enough leads. You feel as though they are Jack Lemmon in Glengary Glen Ross. But then you go to your head of marketing and he demonstrates that he's generated 150% of the leads that he was supposed to generate based on his objectives. What do you do? There are many possible issues: the definition of a lead differs, the profile of the target customer differs, somebody is lying, etc. As tempting as these possible solutions may be, resist the temptation to solve this one yourself. Instead, get both executives together and let them know that you need them to agree on a common definition of a lead, a method for determining whether any given lead meets the description and an objective for the head of marketing to hit next quarter that both he and the head of sales will be happy with. Give them a firm deadline and let them know that you will take no excuses, because you have a whole field filled with demotivated sales reps and you will not stand for that. Apply pressure. 

There is no logical owner
Sometimes a problem has no owner. Customer churn has increased in the past 2 quarters. It's an important issue and left unchecked it could become mission critical. However, it's not the top priority in the company today. To further create CEO procrastination, it's not clear whether it's a customer support problem, a sales problem, a services problem, a product quality problem or some combination of all four. In reality, it's probably a CEO problem, but if it's not the top priority in the company, having the CEO personally drive it to resolution may not be the best idea. So, what do you do? You assign the problem to an illogical owner. In this case, you might assign it to the head of sales, because she has the highest incentive to fix it properly—otherwise she has to resell all those deals to make quota. You empower her to dig into each churned account, find the root cause analysis, and report back to the team on a frequent basis. Once the root cause has been determined, she should propose a cross-functional plan to fix the problem. 

This is an imperfect strategy in many ways. The problem might be entirely with sales setting poor expectations and she might cover that up. The various groups might not get along well and not want to listen to a peer. The head of sales might not have a great idea of what's possible in engineering or customer support. Imperfect yes, but far better than doing nothing, which is generally what happens when the CEO has too much on her plate and doesn't apply pressure. 

The assigned executive tries to give it back
Your company's engineering schedules are unpredictable and your engineering throughput is poor, so you ask your VP of engineering to fix the problem. She complains: "The schedule keeps slipping because the product management team keeps changing the priorities and thrashing the engineers back and forth across the various projects." You say: "Great. I will work with product management to get them to cut that out." The VP of product management replies: "I'd love to stop with the requirements, but we need certain things to close large deals and make the quarterly number." You then go to the head of sales and she says: "Do you want me to make my number or not?"

In this case, everyone is under empowered to make the right decision and get you what you want. The key to delegation is better empowerment. You could simply give the head of engineering the ability to say "no" to everything, but you may well miss all your sales forecasts and cause yourself an even bigger problem. A better approach would be to formalize the change process. You can say that once a project begins, you can alter its definition, resources, priorities, or schedule, but doing so requires a formal meeting with all the stakeholders and the CEO. At that meeting, all changes and their potential consequences will be discussed and a decision will be reached. If you implement such a process, you will find that the number of changes drops by an order of magnitude. By simply making it more difficult to make a change, you will apply pressure to the team to find another way to make the sales number. 

At this point, you haven't empowered the head of engineering to control her own destiny, but you have empowered the team to give you what you want.

Using Pressure to Evaluate Executives

Founding CEOs often find it difficult to evaluate executives. How do I know if my head of marketing is world class? I've never run marketing. Applying lots of pressure is a great way to sharpen your instincts when evaluating executives.

If you consistently apply pressure to an executive and get no results, then you very likely need to upgrade that position. The whole point of paying an executive all that money and giving her that fat stock option package is to take the pressure off of you and give you some leverage. If she can't do that, then she must go. She may be a fine executive for another CEO, but not for you. 

On the other hand, when you have a problem that you have no idea how to solve and you delegate it to an executive and she solves it, then she's extremely valuable. 

Final Thoughts

If you are feeling overwhelmed and under competent, then you are very likely not applying enough pressure.

Share

About
Ben's Book
Archive

App.net