Rubber Gloves, Not White Gloves

I’ve always loved to be involved in making things happen, on the ground.  The detail of execution, the individual decisions that mount up to determine success or failure – I like to plunge my hands into the engine grease.  Hence, rubber gloves, not white gloves.

That enthusiasm hasn’t always been embraced by the environment I’m in – places where the focus was on Big Ideas™, not the minutia of execution.  In academia, research labs, and staff or management roles, I was often supposed to step back, see the bigger picture, and identify the key trends and leverage points.  I love to do that, but I find that big ideas often become irrelevant if you are disconnected from the details.  In studying many projects that both succeeded and failed, my conviction has only deepened that the combination is where the magic lies.

Combining Vision and Execution

A great example is Brunelleschi, the architect who designed the beautiful Duomo – the dome that sits atop the famous cathedral that dominates the skyline of Florence.

It took 140 years to complete the building; the dome had remained a puzzle for decades because nobody could figure out how to build it.  The solution called for rediscovering ideas that had been forgotten since the days of the Roman Empire, and new inventions that had never been tried before.

Brunelleschi solved the problem in 1419 and got the commission, dedicating most of his adult life to constructing the dome and other parts of the cathedral.  The dome took more than four million bricks (37,000 tons of material!), and with the lantern on top stood 375 feet high.  He got a couple of the first patents ever issued to protect his ideas for a new kind of hoisting machine and a river transport vessel.  Brunelleschi was intimately involved in every step of the construction, laid some of the bricks himself, and immersed himself in every detail (including the work schedule and diet of the people doing the construction).  If you are interested, check out the Wikipedia entry; Ross King did a great job telling the story in more detail in the book, Brunelleschi’s Dome.

Another interesting case study was the race to reach the South Pole first in 1911.   Two expeditions were involved.  One party, led by Robert Scott, was less focused on the details of planning and preparation.  The other, led by Roald Amundsen, was a great example of deep focus on every detail.  Amundsen insisted that every member of the expedition be an expert skier who had been practicing the sport since they were children.  Scott’s team mostly couldn’t ski.  Amundsen prepared navigation sheets so that they wouldn’t have to make complex calculations when they were exhausted.  Four out of five members of his final team were experienced navigators.  Scott had one, and used a technique that required more calculation.  Amundsen relied heavily on sled dogs and figured out how to keep them properly fed and cared for.  Scott’s team didn’t want to rely as much on dogs so they were dependent on horses, which turned out to be poorly adapted for the conditions.

Both teams were staffed with brave and seasoned explorers, but the results starkly illustrate the cost of poor focus on execution basics.  Amundsen got to the pole first and returned successfully without losing a man.  Scott, and the four companions who made it to the pole with him, all died.

Right Vision, Bad Execution

There are many, many examples where a compelling vision but poor execution leads to disaster.  It often happens even if the vision is a great and achievable one.

I thought it was very interesting to learn about the history of the Panama Canal in the excellent book by David McCullough called Path Between The Seas.  Basically, there was a competition to come up with the design for a canal that would connect the Atlantic and Pacific Ocean and avoid the laborious and dangerous trip around South America into the treacherous waters of Drake’s Passage.  A Frenchman, Ferdinand de Lesseps, had been the leading spirit behind the Suez Canal and came up with a hastily slapped together plan that chose a sub-optimal path and paid little heed to the enormous engineering challenges.  An American team very carefully and thoughtfully developed an alternative based on extensive surveys.  Lesseps, who was a charismatic, larger than life figure with little engineering knowledge, carried the day anyway and inspired investors to finance the effort.

An engineering group estimated it would cost $214 million; Lesseps cut that to $120 million with no real justification.  After eight years, 22,000 people had died (mostly of malaria and yellow fever – nobody realized that they were spread by mosquitos) and $235 million dollars had been spent, but the project was only partially done with the hardest issues unresolved.  The company went bankrupt.   The project was eventually taken over by the American government, after a fifteen year delay, and it took another $375 million and nine years to complete (but came in under the budget estimate!).  I think it’s a powerful example of a great vision, uncoupled to strong execution, leading to horrible results.  Then that same vision, carried forward in more pragmatic and expert hands, created a vital global resource.

Vision is Crucial .. but Must Not Become Decoupled From Reality

I’m a great believer in the importance of vision and strategy.  But strategy has to be deeply, deeply informed by all the infinite detail of execution.  And in looking at brilliantly successful strategies in technology, I’ve found that they are often emergent properties.  They were glimpsed, and then refined, by someone steeped in a deep understanding of their markets and the technology forces transforming them.  A kernel of insight evolves into a huge success – it doesn’t leap forth from the mind fully formed, like Athena from the forehead of Zeus.   Having a big and bold goal is fantastic .. but strategy is shaped, and success or failure is determined, by the execution.

Great execution is hard and requires endless focus and obsessiveness to achieve.  I’ve mostly worked on large software projects, and when you are building something that has millions of lines of code in it, the team must work together extraordinary well.  Such projects call for Herculean efforts and tiny bits of friction can lead to huge problems.  The code, the test suites, the shiproom triage meeting, the bug count, the milestone definition .. those are the clay and brick from which the great cathedrals are forged.  Lose your connection to the grit and the glue at your peril.

That’s why I love being in a startup .. we have a bold vision for what we hope to achieve, but our days are full of designing and building the product with endless and loving focus on every detail.  Hopefully we are achieving a combination of vision and execution that will let us have the impact we aspire to make in the lives of our users.

As the leader of the forces opposing evil in the universe .. you’re fired!

Epic tales are a lot of fun to read – the struggle of good and evil, the climactic moment of truth when the future of humanity or the world hangs in the balance.  They also can provide good insight on managing complex projects .. or rather, how not to.  There are some great lessons to be learned from the bungling incompetence of fictional heroes (and yes, this point of view can make you a real buzzkill, so you might want to keep these thoughts to yourself!).

Risk Mitigation and Contingency Planning

The worst sins of omission are basic risk analysis, mitigation, and contingency planning.  Very brittle plans are made, with no effort to figure out a Plan B if something goes wrong.  That makes for great drama, but it’s lousy planning.

Let’s start with Lord of the Rings.  It’s a great story that I have loved since I discovered The Hobbit as a ten year old – it has edge of your seat excitement with a richly detailed universe as the backdrop.  But come on .. what kind of a grab-ass plan was that for saving the world from evil?  We’ve got a group of clueless hobbits wandering to Bree with the Nazgûl charging around and almost catching them. The hobbits are supposed to hook up with Aragorn, but they don’t even know what he looks like – would it have killed Gandalf to give them a description?  How about an escort?  The great civilizations of Middle Earth are facing Armageddon, and they can’t scare up a couple of people to help out?

On Star Trek they are always beaming the ship’s top officers onto a potentially hostile and unknown planet, leaving the Enterprise with mostly junior people to run it.  What’s up with that?  They probably shouldn’t be sending most of the senior officers into harms way in the first place.  And, a Constitution class starship is a massive investment and a jewel in the crown of the Federation .. how come they don’t have enough seasoned officers on board to be fully covered even if four or five of the most senior ones insist on wandering into danger all the time?

In the wonderful fantasy series “The Dark is Rising”, they almost lose the ancient artifacts that determine the victory of good or evil because .. somebody left a note with a family and they happened to forget to deliver it.  Really?  Come on!  If that’s the best you can do, time for a new project manager who has a clue.  To drive a complex and crucial initiative, think about the aspects of your plan that are fragile and could easily go wrong, and build in defense in depth.

The Dark is Rising heroes not only made one dumb and potentially fatal arrangement, they keep doing it.  Don’t be like them.  If you see a particular breakdown, think about the underlying causes and address them.  Don’t settle for the obvious explanation – dig deeper.  Say you are running an online service and it went down .. why did it happen?  Well, there was a bug in the code.

  • Sure, but why did the bug slip through?  Do you need better tests?  More tests?  More realistic load testing?
  • Why did it happen in the first place?  Was there some communication breakdown?  Is the architecture of the system too baroque?  Are there missing levels of abstraction between system components?
  • Why was it hard to find and fix?  Do you need better diagnostics?  Better logging?  Better monitoring?
  • Why did it affect so many people?  Could you have a more loosely connected system?  Could components be more resilient when others fail, and degrade the user experience more gracefully?
  • Why were you down so long?  Does it take too long to deploy a fix?  Too much time to restart components that depend on it?

In running a project, you often have to make bets and take gambles – that’s part of the game.  However, you should think about the key bets you are making, and what will happen if your bet is wrong.  How quickly can you tell that you made a mistake (and be fairly sure about it)?  What will you do to reverse course or mitigate the failure?  Are you keeping anything in reserve so that you have some resources you can apply to help rescue the situation?  If you are making an unrecoverable bet, are you clear about that and about the due diligence you need to do up front?

Defining Roles

One of the common sources of confusion and inefficiency in a team is not knowing what role everyone is supposed to play.  Often, you can muddle along until something really important comes up, and then under stress the team works very poorly to resolve the issue.

Think about Boromir and Aragorn – after Gandalf fell into the cavern fighting the Balrog, they hadn’t resolved who was left in charge of the group.  Boromir deeply disagreed with the strategy Aragorn laid out.  Frodo decided he didn’t want to be with any of them any longer.  Since he was the ring bearer, ultimately it was his decision .. but nobody had given much thought to it.   It’s critical to figure out how the most important decisions are going to get made, and it’s a lot easier to do that before you are in the middle of a stressful situation with emotions running high (though hopefully you won’t be getting attacked by the Uruk-hai).

Thinking Out of the Box

It’s easy to get trapped into conventional thinking.  We’re all prone to unconscious assumptions – how things are supposed to be done, constraints we think we have to live with.  For example, Gandalf is close friends with the eagles, who can .. fly.  While carrying riders, and even outmaneuvering the fell beasts that the Nazgûl are riding later in the story.  So why is the Fellowship slogging their way through the mines of Moria and playing tag with terrifying ancient spiders, when they could get to Orodruin in a couple of hours?  Maybe with some Legolas-class archers along to provide suppressing fire in case anybody tries to interfere?  The whole thing could have been wrapped up and the hobbits tucked cozily back in their beds after a nice end of the day snack, before Sauron had a clue.  This idea is hilariously developed on “How it Should Have Ended”.

In life, it’s impossible to identify and question all your unconscious assumptions .. but you can tease out the most important ones.  Ask yourself what you are assuming, and whether you have the evidence to back it up.  Ask “what do I have to believe?” in order to justify a proposed course of action, and see if you can get some kind of backup that those things are really true.  Or a way to notice that they aren’t, so if you are on a delusional path, you’ll figure it out as quickly as possible.

Learn From Everything

I have found that there are great lessons to be learned about accomplishing your goals from every life experience.  Learn on the job, by all means, but I try to make everything grist for the mill – books, stories, movies, tales from history .. it all provides insight and inspiration to help you pick the goals that matter to you and to find ways to achieve them.  And before you decide that “actually, hope is the plan”, remember that in real life, you aren’t the main character.  There is no author who will turn your heedless folly into an exciting story of success against all odds.

Eyes of a Stranger

I’m always looking for best practices to adapt and adopt, and I got an idea that I really like from a mentor.  It is a way to combat the complacency that sets in as we settle into any role – that tendency to become accustomed to the way things are, even when they are pretty screwed up.  “Well, of course you stand on one foot and tug on your left ear with your right hand .. that’s just how things are done here.”  With fresh eyes, we might ask “but, umm, isn’t that kind of stupid?”  And, “about the fire burning over there .. maybe throwing some water on it would be good?”

So periodically – maybe once a quarter, or once a year, the idea is to do an exercise I like to call “eyes of a stranger”.  Pretend that you just got your job and are figuring things out – you are in your “first 30 days” and are coming up to speed on the important things you need to focus on.  What is a top priority issue or opportunity that you would see and decide that you absolutely have to pursue?  What inefficiency would you discover that would just bug you until you got it fixed?  What joy-killer is afflicting the team (or you) that needs to get taken care of?

There’s a scene from a book that got stuck in my mind; it’s in Kon Tiki, the really fun story about an anthropologist who gathers a set of kindred spirits to prove that it is possible to sail a raft from the Peruvian coast to the Polynesian islands, using only the technology available in ancient Peru.  At the end of the book, they have crashed on a reef and the raft is smashed, they are pinned down and waves are pounding over them, and one of the people clinging to the remains of the boat says calmly “This won’t do.”  I try to apply that same calm but determined spirit to situations at work that feel desperate.  As you look at your job and the environment around you, what “won’t do” that you’ve gotten used to and have been letting slide?

I’ve found that you probably want to come out of the exercise with a very short list of things you are going to pursue more aggressively than you have been – one is good, three is probably an absolute max.  If you come up with a longer list, revisit it after you do something about the top ones.  I tend to find that you get wildly more bang for the buck by focusing on a couple of things (or one!) rather than dutifully writing down ten “priorities” and feeling overwhelmed so you just go back to ignoring them.

For each of the issues that you’ve picked, you need to figure out what concrete steps you can actually go take to deal with them.  I like to sit down with a piece of paper and do a mind map.  If the issues are worth addressing and you haven’t been doing it, it’s a good bet that you are a bit stuck in figuring out what needs to be done.  Maybe you just need to spend 30 minutes listing next steps or coming up with a plan.  Or, perhaps it will work better to pick somebody you have a good rapport with, and brainstorm about it together.  If it’s a really big issue, you might find it helpful to apply (some of) the framework that I outlined in the series on “Cracking the Nut”.

I’ve done this exercise over a dozen times, and each one has helped me get hard core about tackling something that needed doing and that wasn’t moving forward.  See if it works for you, too!

Relay Race vs. Diving Competition

When you are evaluating how people are doing, it seems reasonable to focus on the business results they deliver.  In my previous team, we called this the relay race model.  What matters in a race is finishing, and finishing with the fastest time.  Nobody cares whether your running form was good or terrible – you are measured solely on the results you deliver at the end.  In most work environments, this is appealing, intuitive, measurable … and wrong.

A diving competition is almost the exact opposite of a relay race.  After all, everybody is going to hit the water, and it will take about the same amount of time no matter what you do.  The score is based on your form – how difficult a set of moves you undertake, and how gracefully and perfectly you do them.

Why the Diving Competition Matters

So what does this have to do with measuring job performance?  It’s the difference between assessing the pure business results that somebody delivers vs. the way they delivered those results.

It’s easier to measure (and talk about) the results that were delivered.  Did the product ship?  How much revenue did it generate?  Did you hit your sales quota?  Was the code quality where it needed to be?  Is the product performance hitting the ship goal?  It depends on your job, of course, but in many cases it’s relatively straight-forward to tell whether the person and/or the team achieved the goals that they were striving towards.

But there is another side of things – the way you behaved in pushing towards that goal.  Did you help build up the team?  Do people find you a good person to work with?  Do you help make the whole team better, smarter, and more capable?  I’ve worked with a lot of aggressive young engineers, and they sometimes are very impatient when I bring up these questions.  “Hey, I wrote the code, the product shipped, and it’s good.  I didn’t have time to humor those other idiots – we were on a tight schedule.  And I was right, wasn’t I?”  Often, yes.  But you are still going to get dinged on your review, because you may have been right about the issue, but you didn’t handle it the right way.  By running roughshod over the other person and leaving them feeling dismissed and mistreated, you blew it.  Why?

Well, for one thing, you are only responsible for part of the project.  Checking high quality code into the build is important, but the crucial thing we need to do is solve the customer’s problem.  Which means we need to understand their problem holistically, build a complete solution that meets their needs, test it, explain it and then sell it to them, support it, and integrate with other products.  That calls for a group of people to work effectively together.

Also, a particular deliverable is just one in a long succession of business results that we have to achieve together.  Sure, we shipped the product .. but that was just the beginning.  Even with packaged software, we have to ship patches.  We immediately start building the next version.  If it’s a service, shipping is the beginning of the hard work, not the end – now we have to run it 24/7 and manage the business that is based on it.

All of these ongoing business deliverables rely on the team working smoothly together.  When you are working on a problem that involves groups of people, no single person’s work alone can make the whole group successful.  If you achieve the goal you are focused on but leave a path behind you strewn with dead bodies, you can easily do more harm than good even if you do achieve what you set out to do.  Every team member has as much of an obligation to help ship the team as they do to help ship the product.  Given our ongoing responsibilities, the team is often the more important deliverable.  In the software business, if we create an unpleasant working environment and everyone leaves, we’ll be left with a big pile of code and no ability to run it, fix it, evolve it, support it, and sell it.

So for very hard-headed business reasons, I think it is necessary to evaluate people based on both the relay race model (the explicit results they achieved) and the diving competition model (whether they work effectively with others).  If you only focus on one, you aren’t encouraging and rewarding the behavior that yields the most value for the organization.  And on a more personal note, who wants to be on a team that’s unhappy and mistreats each other?

What Do You Want to Be When You Grow Up?

When I’m managing or mentoring somebody, this is one of my favorite questions.  It’s a good way to crawl into their heads a bit, understand their motivations, and figure out how I can help them.  It’s also not a bad question to ask yourself!

Framing

There are different ways to approach the answer – you might base it on:

  • A particular person’s abilities: code like Guy Steele, move an audience like Meryl Streep, or paint like Raphael.
  • A particular job: be the VP of your division, the CEO of a Fortune 500 company, or the founder of a growing startup.
  • An achievement:  win an Olympic gold medal in swimming, design a piece of software that millions of people adopt, or take a company public.
  • A state of being: be crazy passionate about your job, feel that you are living in perfect alignment with your principles, or devote your life to serving the community.

How somebody chooses to answer will tell you a lot about their values, ambitions, and self-image.  Be careful about guiding them too much .. we’re talking about their dreams, not yours.

Cheerleader or Critic?

In doing this exercise with many people, it’s usually at least imaginable that they might achieve their ambitions with hard work and some (or a lot) of luck.  However, now and then somebody will come up with a goal where you have to struggle a bit to keep a straight face.  Often it’s about personality and passion – if you are impatient and can’t stay focused on your own, writing novels might not be your best bet.  So what do you do when someone who hates math wants a Nobel Prize in physics?

I try to be a “pragmatic cheerleader”.  I don’t want to be a dream buzzkill – most people are surrounded by plenty of those already.  But I also don’t want to be mindlessly encouraging.  The next question often helps to get things more grounded in reality.

What Does it Take to Achieve That Goal?

Dreaming big is great, but you have to break down the goal and figure out what it takes to achieve it.  One approach I like: if the person wants to be an X, I get them to write down a description of what the absolutely perfect X would be like.  For example, when I was running a relatively large team, I came up with what I thought a perfect team leader should do .. I wrote about that here.

Often, the person doesn’t have a great answer.  They are attracted to the idea of being a CEO, but they don’t actually know much about what the day to day life of a CEO looks like.  After some discussion, we can usually rough out an outline of the skills and qualities needed, but we often agree that a key next step is to validate that list with people who actually have that role or are more familiar with it than we are.  That’s a great practical step forward on the journey.

How Do You Stack Up Today?  How Do You WANT to Stack Up?

The next thing I do is have them assess themselves against those ideal qualities or skills.  At this point, people sometimes realize that their supposed goal doesn’t actually make a lot of sense for them.  I was talking to one person who thought they wanted to be the CFO of a public company.  We talked about the skills you’d need to be a fantastic CFO, and then she thought about when in her work life she had been really happy and why.  And she realized that the things that really did make her passionate and inspired were not the key activities of that job at all.  So I think that was a helpful moment of self-revelation.

This exercise also tests self-awareness.  Sometimes, they are confident that they have some needed quality .. and you think they are wrong.  It’s tricky to handle this.  I tend to tread pretty lightly – the goal here is self-revelation, not a lecture on their weaknesses, which tends to bring the discussion to a halt in a hurry.

But if people have at least a basic level of clue about their true nature and abilities, this exercise can have quite a profound impact.  I’ve watched people realize that they were carrying around outmoded ideals foisted on them by authority figures from their youth, and realize that they have an inspiring path open to them in a quite different direction.  That’s what you hope for – an opportunity to enable somebody to achieve a profound moment of self-discovery.

How Does One Actually Get That Job?

Next, I like to consider how people actually get the job or the opportunity to achieve the goal in question.  If it is a well-defined role, then the answer is usually straight-forward, but many people don’t think about it very practically.  I’ve repeatedly asked, “how do you become a VP” (or whatever).  People go on about a demonstrated track record, a well rounded set of skills, and all sorts of worthy things … but none of those are the real answer.

The actual answer is, “somebody who hires VPs chooses you”!  Now why would they do that?  All these ideas about skills and roundedness are fine, but often the true reason is that the hiring manager has confidence in you to do a great job and trusts you.  They’ll almost always pick somebody with strong skills, whom they deeply trust, over an unknown with a potentially stronger resume but who might be a whacko.  And they trust you because they know you over a long period of time, and have watched how you handle many different situations.  So one of the things that might be necessary to achieve your goal is to deeply commit to a particular team or company for an extended period of time, rather than bouncing around all the time.

Alternatively, the goal might be something that has to be created rather than granted – becoming the CEO of a new startup is self-elected (!).  But they need to have enough money to survive without an income and perhaps to fund the company for a while.  They may need a network of people they can hire.  And so forth.  Pretty much any ambitious goal will require something in order to open up the opportunity.

What Are Your Next Steps?

Now they have identified the goal, what it takes to get that opportunity, what they need to be successful, and where they stand now.  For each skill or ability where they aren’t already strong and experienced, I’ll brainstorm with them about a specific action that will develop it.  For example,  they can often build up skills that aren’t a direct part of their job by volunteering for extra projects – what I like to call “hobbies”.  I’ve learned a ton from hobbies – helping to organize and run a large developer conference, participating in working groups considering radical new directions to take the team, teaching classes, etc.  None of those had much to do with my core job, but I practiced new skills, learned about new areas, met really cool people .. and had a lot of fun.

The goal is to finish the discussion by identifying very concrete steps that will build the skills they need to achieve their dreams.  And if you have an ongoing relationship, hold them to it.  If you can really help somebody achieve their dreams, that is one of the best feelings in the world!

We’re Living in Florence, in 1450 A.D.

If you work in technology, you have the amazing luck to be in the midst of one of the great transformations of human society.  There have been numerous times in history when technology has transformed the way we live, our understanding of the world, and the life we are able to experience.  I’ve had one of them on my mind a lot lately – the Renaissance.  I think there are very interesting parallels to be drawn.  It feels like we’re at the height of the first round .. which would put us in Florence, around 1450.

What Caused The Renaissance?

Many forces came together to enable that astonishing transformation of knowledge, art, architecture, and commerce, whose profound impact shaped the world and still fascinates us.

There were some key technology breakthroughs.  Gutenberg is famous for inventing the printing press in 1440, which greatly expanded our ability to distribute ideas.  But just as important, and less frequently remarked upon, was the spread of paper.  We take it for granted today, but it was a magical boost to our ability to capture and disseminate ideas.  Paper is far less costly to produce and can be manufactured in much greater quantity than alternatives like vellum, made from animal skins.  Invented in China in 100 AD, paper remained a closely held secret for several hundred years, but had become widely used by the time of the Renaissance.

The ability to travel and to trade was revolutionized by ocean-going ships (like the Portuguese caravel), which were capable of navigating the globe.  At the same time, the mariner’s astrolabe made it possible to measure latitude anywhere in the world.  With weapons like the arquebus, small groups were able to wreak havoc among less technologically advanced populations.

New technology called for new technique, as well.  The development of merchant capitalism, along with sophisticated means of tracking commercial activities like double-entry bookkeeping, allowed a modern system of banking to emerge.  It was banking that made Florence so wealthy, and that wealth enabled major investments in science and the arts.

In addition to a major infusion of money, the arts were transformed by new techniques as well.  Paintings became far more realistic using linear perspective.  Architecture took advantage of construction techniques both novel and rediscovered.  Grand new structures were created that finally matched and exceeded marvels (like the dome of the Pantheon in Rome) that had been built 1400 years earlier.

This confluence of breakthroughs in technology and technique allowed Europe to leap forward and become the dominant world power in a remarkably short period of time.  Businesses grew to previously unheard of scale and their activities reached across the globe.  Ideas moved much more quickly, too, because they were carried along by the people who were associated with this explosion of trading activity.  Control of knowledge moved from guilds to a mobile class of experts.  Liquidity, supported by precious metals imported from the New World, began to move the basis of wealth from land to capital.  Our world view also began to shift radically – from deism, centered on God, to humanism.  Our conception of the universe was rocked by the discovery that we were one of many planets orbiting around the sun.

The Modern Renaissance

Fast forward to today, and consider what is happening.  In technology, we are seeing two massive changes: devices and the cloud.  The cloud has transformed the cost and reach of computing.  By most estimates, Google runs well over a million servers in their data centers and handles something like three billion searches per day.  This is technology operating at a global scale that was absolutely inconceivable a few years ago.  At the same time, the programmable cloud has made it extremely cheap to build and deploy software.  For a few hundred dollars a month, a programmer with a laptop can take a program they have written and within minutes make it available to more than two billion people.

Smartphones and similar devices are also astonishing in their capability and their reach.  There are now around 1 billion smartphone users in the world with the Internet in their pocket and accessible at all times.  That number is growing rapidly – estimates are that there will be a billion net new smartphone users in the next few years.  The Apple App Store just crossed 25 billion downloads.  The pace of growth and the scale of what has already happened are just staggering.

As always, new technology encourages innovation in techniqueOpen source software has been around for decades, of course, but it has gotten a major boost from its intimate relationship to cloud computing.  A wide body of high quality components are available for free to anyone who wishes to build cloud applications, representing a dramatic reduction in the time and effort required to go from idea to product.  We’re benefiting from that tremendously in our startup.

Another key change is the move from on-premise software to software as a service.  It means that the latest version of every application is available to every customer, without their needing to deploy or manage it.  Services pair nicely with, and encourage, the shift from physical to virtual – instead of manipulating objects, increasingly we’re manipulating data.  We are doing research and developing new products using simulated environments.  We’re transporting knowledge and entertainment as packets over networks, not by sending boxes of plastic and paper around the world.  Increasingly, the basis of value is rooted in virtual goods and services.  I believe that is as profound an economic change as the shift from land-based wealth to capitalism.

Signposts of the Revolution

We have seen some dramatic evidence of the impact that these changes will have, but I think we’re just at the beginning.

  • Facebook has over 900 million active users, and is on track to hit a billion later this year.  It has grown to that size in .. eight years.  To put that in perspective, China’s population today is 1.3 billion; it took around 250 years to grow the last billion (and it took human beings about 12,000 years to hit their first billion).
  • Speaking of Facebook, they recently purchased Instagram.  This company, which serves 30 million users has .. 13 employees.  Two developers run the back-end service for their users.  A few years ago, it would have taken a big company with major resources to support that many users, and now it can be done with a handful of people and no capital expense at all.
  • Consider that icon of the industrial revolution – the car.  A modern premium automobile has something like 100 million lines of code to run the nearly 100 processors distributed throughout it.  It was simulated extensively on supercomputers, is supported by myriad online services, and the supply chain that delivered it to you only works because of massive amounts of software tracking every minute aspect of its progress in real time.

I could go on, but the point is that virtually every industry is in the process of being transformed by the combination of the cloud and the device.  The way we make discoveries and create new inventions.  The way we communicate.  How and what we buy.  How companies interact with each other and with their customers.  And this is all happening incredibly quickly – the cost and effort for new ideas to be tried, refined, and deployed globally has dropped to the floor.  We’ve seen some dramatic changes already, but that was just a warm-up – we’re in for quite a ride.

The Path Ahead is Uncertain

In 1450, Florence was unquestionably at the forefront of the Renaissance, and the city was dominated by the Medici family.  By 1500, the focus of the action had moved elsewhere in Italy and across Europe, and Florence never regained its dominance.  What happened?  Well, for one thing, Charles VIII of France invaded Italy in 1494 and kicked off the Italian Wars, a series of conflicts that involved various city states and several empires.  That first invasion forced the Medici to flee the city, though they returned and ruled it again later.  In the meantime, other parts of Italy and Europe took over and led the Renaissance forward.  I suspect that the fortunes of the early players in our current Renaissance will also dramatically rise and fall.

And worse than losing leadership, there is a darker side to change.  We like to celebrate the Renaissance and the great leap forward in human capability that it represented.  But it wasn’t positive for everyone; it was particularly brutal for indigenous cultures around the world who were now within reach of the Europeans.  Many of them were despoiled and enslaved.  The current changes will not be as violent, hopefully, but we have seen these forces help governments fall and companies be humbled, and there are industries filled with people whose economic future will be dramatically affected.

We can never know ahead of time how things are going to shake out for particular groups during times of great change.  But when transformative forces come along that are this strong, they cannot be denied – they will transform our lives, culturally and economically.

Leonardo Da Vinci.  Michelangelo.  Brunelleschi.  We are still inspired by what they accomplished.  They were amazing people … but they also had amazing luck.  They lived in a magical time and place in the history of mankind.  So do you.  How are you going to be part of this modern Renaissance?

Beware the Shining Paladin From Afar

Companies often fall into the trap of believing they can hire some external person to be their salvation – a shining knight who will lead them out of the darkness and into the promised land.  There are times when this works, but in my experience those are overwhelmingly outnumbered by the failures.  Why?  And can we learn something from the failures to try and avoid them?

The idea is very appealing.  If we as an organization are failing – maybe we are getting creamed by some competitor, or our formerly successful product is moldering into obsolescence and we can’t seem to get with the program on a modern reinvention of it.  Shouldn’t we invigorate the tired old blood in the team with a turbo-shot of new thinking?  Well, maybe.  But if we do, we’d better think about the many ways that this tends to fail.

Internal Pathology

We might be failing because of a systemic problem within the company.  This problem might be organizational (there is no team that cleanly owns the charter, so it keeps falling between groups), personal (somebody influential and passionate is preventing us from pursuing a workable strategy), failure of execution (the team that owns it isn’t healthy or effective), failure to focus (the team that owns the problem fundamentally doesn’t care about solving it), or strategic (the team gets pushed by company leaders into building overly general solutions that collapse of their own weight).

Fixing these problems can require a lot of organizational savvy and trust from the rest of the company; a newcomer is often much less capable of solving them than a seasoned employee.  Add to that the burden of expectations, and you have a situation designed to create failure.

Teacher’s Pet

Many times, I’ve watched a senior person get frustrated with a team, so they stick in some new blood and hope for the best.  The team can resent the newcomer as a teacher’s pet or “golden child” who hasn’t paid any dues.  Who are they to come in and start shooting off their mouth, without knowing anything about the team or the product?

For example, a friend of mine was hired by the president of a division to come in and shake things up in a new direction.  My friend gave an exciting pitch about the opportunities the team had and wasn’t taking advantage of.  He was put inside a group that had no buy-in to those new ideas, and which took its cue from somebody who had helped create the division and been responsible for some of its great successes.  Who also wasn’t bought in.  How receptive do you think the team was to my friend’s ideas?  Right, zero.  It was a massively frustrating experience for him and a waste of energy for the team, which of course went on to do exactly as it had before. 

Cultural Rejection

Teams can be a lot like the immune system, which “will try to destroy or neutralize any antigen that is recognized as a foreign and potentially harmful invader.”  People coming into the team, especially people brought in because they think differently and aren’t bound by the dominant assumptions shared by everyone else, are just bristling with antigens.  They use different language and terminology, they say things that seem off-key.  Often the instinctive rejection is so strong that their ideas don’t get a fair hearing.

Missing Key Skills

Having worked at both startups and large companies, I know how deeply different the success factors can be in those two environments.  People who flourish in a smaller community don’t always have (or value!) the skills to negotiate the internal landscape of a large company.  A big company might hire somebody who was winning, and the big company hoped that this person can transform its efforts.  If I’m that new person, why would I abandon my successful approach and adopt ideas from this team that has failed?  What could they have to teach me?

The problem is that the way you run an independent team for success, and the way you run a team inside of a big company, is quite different.  There is some overlap, but there is a lot of non-overlap.  As the new person, I have a lot to learn.  It’s very hard to figure out which traits I bring that are uniquely valuable and must be preserved, and which ones I have to supplement or replace in order to be effective in my new environment.

Wrap Up

I’m certainly not advocating that companies refuse to bring in new blood – it is crucial that they do.  But those people, especially if they are brought in to turn around a failing situation, have to negotiate a minefield.  The company needs to think hard about whether the problem it has is one that an outsider is really equipped to solve.  And it can’t expect that outsider to solve it alone – he or she is likely to need seasoned partners who can help translate that new perspective into a form that others can understand and act on.  Paladins seem like lone crusaders, but they wouldn’t have gotten very far without a host of supporters ranging from squires to armorers (not to mention the most important one – their horse!).  Before you try to hire one, make sure it’s what you really need … and don’t leave them unmounted and unsupported, or you are likely to have a bruised and grumpy knight on your hands pretty soon.

On Being Acquired – Lessons Learned

Once upon a time, I was one of the three full-time employees at Colusa Software, which Microsoft acquired in 1996.  We all came to Microsoft as part of the buyout, and went on to learn some interesting lessons about having your very small company acquired by a very large one.

Who We Were

Colusa was building some nifty virtual machine technology – you could target it from any conventional language, could run in a protected sandbox, and could get close to natively compiled performance on a variety of hardware platforms.   Our dream was that we would contribute towards a VM for Windows that would ultimately run much of the software in the world.  Other companies wanted to acquire us, but we came to Microsoft because we thought it offered the best chance for our technology to be ubiquitous – we said to each other that it would be a place to build software that “my mom will use.”  That was a very powerful motivation.

What Happened

After we were acquired, we ended up in the Visual Studio organization.  It seemed to make sense because we needed to work closely with the compiler team to target the VM, but actually it was a mistake.  All of the major decisions about runtimes were being made elsewhere, and we had limited contact with the key people.  Many of them were already committed to other solutions.

The result was that we kept getting redirected from afar.  “Your VM would be perfect if the wire size was smaller than Java.”  Ok, we went and built a cool compression strategy that yielded extremely compact code.  “Your VM is out of the question because it isn’t compatible with Java bytecodes.”  Oh.  “Your VM is Microsoft’s future.”  Great!  “Your VM would be cool, but isn’t practical without a substantial modification to Windows that would require too many resources.”  But …  And so on.

Amidst these conflicting messages, we tried to soldier ahead.  We rebuilt our original system to work with Windows, and demonstrated that it worked  by recompiling Microsoft Word and running it on the VM with performance indistinguishable from natively compiled code.  Eventually the team helped design the bytecode strategy of one of the VMs in the operating system.  Although it wasn’t what we had originally hoped to accomplish, the ideas did influence the design of a part of Windows.

So, what did I learn from all this?

Lesson #1: Have a champion

By far the most important lesson is that you desperately want to have a senior person who is the champion for your group.  We didn’t have one, and we suffered badly for it.  The need is particularly acute if you walk into a politically charged area.  There were deep divisions in the company that we didn’t understand – it was confusing for long-time employees and utterly baffling to us.  We thought we had something that the company would eagerly seize upon.  Over the course of six months, we were told that we had one of the most important projects in the company, that our technology would be scrapped, and that we should redesign it in ways that we felt would be a disaster.  Not fun.

I don’t think anyone could have prevented the situation from being difficult and confusing, because the company was facing very tough and important decisions.  But at least we would have felt that somebody was in the key meetings advocating for us and then telling us what was happening.  I think the team was hurt, for example, by a feeling among some key partner teams that we were overselling.  We thought we had carefully explained that, for a commercially viable solution, we would have to rely on other parts of the company to deliver key missing pieces.  But that message didn’t get through.  This kind of disconnect happens all the time and is natural; people who hear about a technology without the details make assumptions about what it does and doesn’t deliver.  Teams have to actively (and continually) educate their partners.  We just weren’t talking to them.  In fact, we didn’t even know their names.

To a company being acquired, I can’t stress enough that you want a politically savvy champion who has the ear of the key architects, people in management, etc. and will go to bat for you when it is appropriate.  You want that person to be identified with the acquisition and their credibility on the line as to whether it succeeds or fails.  They should drive you hard and want to exploit your ideas for the maximum benefit of the company – after all, that’s what you want, too!

Lesson #2: End up in the right part of the organization

Many large organizations have teams that are quite autonomous from each other.  If you land in the right place, which we didn’t, the people around you will understand how to integrate your technology into the product portfolio of the company and be in a position to make that happen.  The key thing, though, is that your hosting organization is the one that drives the decisions that most directly affect you.

Lesson #3: Nobody trusts you

Getting acquired feels like a seal of approval.  It says that you were doing something cool enough that the big company felt it was better to buy it than to build it themselves.  That doesn’t prepare you for the likelihood that nobody in your new company will trust you at all.  They won’t believe that your code is any good or that your team is up to the standards of the rest of the organization.

As far as I’ve seen, there are only two solutions:

  • Seed your team with some experienced and trusted employees from the big company.  This is a great idea anyway, because in addition to providing credibility, they can also be enormously helpful in getting things done in your new environment.
  • Ship and win in the marketplace.  That’s the ultimate coin of the realm in any software company.

Final Thoughts

There were ups and downs throughout the experience, but I learned an enormous amount from being acquired by and working within a large company.  I’m doing my third startup now, and hopefully applying lessons learned from all the experiences I’ve been fortunate enough to have along the way.

Use the “Pet Rock Principle” for your next project review

Ah, the project review.  Like death and taxes, if you work in a larger company, these are probably an inevitable fact of life – at some point, and maybe quite frequently, you have to get in front of somebody senior and give a review of the state of your project.  At Microsoft, the ritual of the “BillG Review” was woven into the culture when Bill ran the company.  Your review might be anything from a routine monthly status update to a high stakes undertaking with people who have the ability to cancel the project (and/or fire you).

Designing a great review is complex and involved; you want to tell a compelling story that resonates with your audience, to distill the work into its essence, and to convince that the team is executing well and should continue to get support.  These reviews can take on a life of their own and soak up tremendous amounts of time that could be (much) better employed in getting the darn work done, rather than talking about it.  This is one of the reasons that small organizations can be more efficient – they don’t need to prepare reviews of the work they are doing, because everyone is too busy getting it done.

Enter the Pet Rock

To avoid getting bogged down in an expensive manage-up exercise, when I’m preparing for a review I try to stay focused on what I call the “pet rock” principle.  If you didn’t grow up in America in the 1970’s, you might not have heard about the pet rock – it was a hilarious (and self-mocking) fad where people bought a rock, instead of a real pet, because they are much less trouble to take care of.  Pet rocks were very good at some tricks – as the instruction manual explained, they excel at “sit” and “stay”, but struggle with “shake hands”.  Since the pet rock is an iconically useless object, it seems like the perfect stand-in for some members of senior management, as seen from the trenches.

The principle that’s guided me through many reviews (on both sides of the table) is that most of the value from a really good review would be achieved if you replaced the audience with a pet rock.  In other words, the review should be mostly designed to benefit the team, not the reviewers.

As easy as it is to get cynical about reviews, they can be a valuable exercise.  They force you to:

  • Articulate the goals, strategy, and execution plan for the project.  As I have repeatedly advocated throughout this blog, there is magic to writing things down.  It forces you to think much more carefully and systematically than you usually do.  A review is a great opportunity to tell your story to your own team.  Usually the leaders of a team assume that everybody “gets it” .. and often that isn’t true.  It’s incredibly valuable for the team to walk through the vision, the strategy, and the plan.  From research in advertising, we know that people do not absorb a message until the third exposure (and some studies have yielded much larger numbers).
  • Distill the essence of the work.  Senior people generally get bored easily, so they won’t let you maunder on at endless length about what you are doing.  They want it summarized into a succinct and effective form.  Figuring out how to capture the work you are doing in a tight and lean format is a powerful exercise.  And it’s hard.  Often you won’t bother to do that work until you have a forcing function, and the review can be that forcing function.
  • Enumerate top issues/risks and what is being done about them. It’s easy for teams to get desensitized to their biggest problems.  “Well, yes, there is a blazing fire over there that threatens our success, but it’s been on fire for a while and we just don’t have time right now to worry about it.”  Reviews can force you to think those problems through and make sure you have a plan to resolve or mitigate them.

An excellent review can be a morale booster that reminds everyone of the exciting mission that they are on.  It can identify issues that are falling through the cracks, and can help you to hone your execution.  Mostly, that isn’t how it works, though – they provide modest benefits (at best) for the team, and they represent a bunch of overhead that saps precious reserves of energy and enthusiasm.

So if you are pulling a review together, see if this principle helps you stay focused.  Constantly ask yourself whether you are working on something you would truly continue to do if there were a pet rock presiding over the review.  When the answer is no, you are just managing up.  You may have to do some of that, but the more you do, the less you are advancing the organization’s true interests, and the more you are creating the overhead that everyone complains about.

Omit needless work .. and remember the rock!

Five Favorite Books .. Capturing the Passion of Creation and Discovery

One of the most common and effective of the “classic plots” for a novel is the quest.  Many epic tales are based on it – Frodo and the Ring, Indiana Jones and the Ark, Odysseus and his attempt to get home.  But the passion to create and to discover in the real world can be just as compelling, if they are captured well.  I’m always looking for books that pull it off, and here are five that I particularly enjoyed.

Ship of Gold – in 1857, the SS Central America was wrecked off the Carolina shore on its way back from the California gold fields, with hundreds of people and tons of gold aboard.  The exact location of the wreck was a mystery – a puzzle that Tommy Thompson was determined to solve.  He is an entrepreneur and explorer and inventor who spent 10 years searching for the wreck and preparing for the salvaging operation.  Along the way, he invented a whole range of new equipment and techniques for doing deep-water recovery – the ship was 8000 feet below the surface, distantly out of the reach of traditional salvaging methods.

Thompson throws himself into the project, leading a team of oddball characters and managing investors and lawyers .. while fending off competitors who are watching his every move.  He built a six ton remote controlled underwater vehicle called Nemo, with video cameras and robotic arms.  How he ultimately succeeded in recovering a few hundred million dollars worth of gold from the wreck is a triumphant story of achieving an extraordinarily difficult mission against all odds.

A Place of My Own: The Architecture of DaydreamsMichael Pollan is probably best known for his book “Omnivore’s Dilemma” (which is very good!).  But I am a fan of his less celebrated (and quirky) book describing in immense detail how he came to build a writer’s cabin on his property.  You may have been involved in a construction project of your own at some point, but I’m going to guess that you didn’t approach it in quite the way that Pollan did.  He’s .. well, he’s an obsessive sort of person, and fiercely bookish.  And yet he decided that he would build this house himself, starting from absolutely zero knowledge of architecture or construction.

Work is how we situate ourselves in the world, and like the work of many people nowadays, mine put me in a relationship to the world that often seemed abstract, glancing, secondhand. . . . Nor did what I do seem to add much, if anything, to the stock of reality, and though this might be a dated or romantic notion in an age of information, it seemed to me this was something real work should do.

The two and a half year saga of Pollan and a curmudgeonly builder putting together what is essentially an oversized garden shed is a glorious and beautifully written ode to manual labor mixed with over-thinking everything.  To get things rolling, he turns to the writings of … Marcus Vitruvius Pollio, a Roman architect from the first century BC.  And to Chinese writings about the principles of feng shui (he tries running downhill to feel the flow of the land and identify a good site for the building).  And to poets, architects, philosophers .. the list goes on and on.  You get the pleasure of joining Pollan on an absurdly wide ranging set of digressions on the history of architecture, how to design a truss, and the often uneasy relationship between architects and builders.  And at the end, you feel like you have traveled with him on a zealot’s quest to create a perfect organic writing space.

The Soul of the New Machine – as an engineer, I love the way that Tracy Kidder captured the excitement and the exhaustion of creating a new piece of complex technology.  He vividly conveys the marathon sessions of caffeine-fueled intensity, the team driving itself to the edge as it creates and refines a tremendously complex design.  It is one of the truest portrayals I’ve read of what it is like to be swept up in that kind of experience.  And it’s particularly noteworthy because Kidder is not technical at all – he has no real understanding of the work that the team was doing, yet managed to capture the spirit of it very accurately.

This particular machine was built by Data General, in 1981, at the dawning of the age of the mini-computer.  It ended up having little impact on the evolution of computer technology, because DEC’s VAX was and remained dominant.  But that makes the story even more authentic to me, in some ways – you have to believe that what you are doing is incredibly exciting and important.  It’s magical to be swept up in that collective creative act, regardless of the verdict that history ultimately renders on the outcome.

How I Killed Pluto and Why it Had it Coming – those of us in my generation grew up in a nine planet solar system, with lonely Pluto orbiting way out in the frigid fringes of the solar system, looping in its eccentric orbit off kilter from everyone else.  It was jarring to hear that the astronomers downgraded the poor little wanderer to being a mere “planetoid” – My Very Excellent Mother Just Served Us Nine Pizzas lost its punch line (maybe now she is serving us Naan, to reflect our globally connected community …).  What happened?

This book answers that question, and it also lets you join Mike Brown, a passionate explorer of the cosmos.  He introduces us to his life as an astronomer and his painstaking exploration of the pocket of space around the sun that we call our solar system.  You will learn about the Kuiper Belt and its littering of frozen asteroids, you’ll watch astronomers move from massive cameras exposing film all through the night to computers that can capture images hundreds of times more quickly and search for cosmic wanderers algorithmically.  It’s a great ride.

Double Helix – I almost didn’t include this book because it is so well known, but it’s such an exciting read, and represented such a transformation in our understanding of genetics, that I couldn’t leave it out.  If you haven’t read it yet, it tells the story of how James Watson and Francis Crick figured out the structure of DNA, the genetic blueprint for human beings (and every other organism on earth, aside from some viruses).  It’s literally the magic key to life on Earth.

The book shows the human drama of discovery, complete with a race to figure out the answer before other teams could “crack the code” first.  And the result is such a beautiful answer – the double helix structure is elegant and resilient.

This is what drew me to science and research as a child – banging your head against hard problems that matter, suddenly having the insight, and then being able to understand how the world works and came to be in a new and exciting way.  It’s what science ought to feel like!