It seems that nearly everyone is jumping on the bandwagon to highlight the leadership lessons we should learn from Steve Jobs’ business success.  A particularly well written piece is Walt Isaacson’s summary in HBR of his incredible biography of Jobs.  But let’s face it, if we are truly introspective and rational we can probably agree that none of us have Steve’s product vision and sense of the market.  As such, we have as many things to learn from what he did wrong as what he did right.  I for one stand in absolute horror and dismay at his approach and overall attitude and am amazed that he was capable of overcoming his many personality and leadership shortcomings.  Here are a few lessons derived from Steve’s shortcomings:

Don’t be a Brilliant Jerk:   I wish I could claim that I dreamt up this term, but it comes from Reed Hastings.  After reading Walter Isaacson’s biography of Jobs, I can’t help but think that Jobs was a jerk his entire life.  He screwed over his friends from the start of his early career, such as when he used Wozniak at Atari for his own personal gain.   He would cry when he didn’t get his way, and scream at those who didn’t agree with him.  There simply is no room for this type of behavior if you want a truly high performing team.  Maybe you can get away with it if you truly are the next Steve Jobs – but you probably aren’t.  And even if one of us is the next Steve Jobs, the real question we all should ask ourselves is “How great would Steve Jobs have been if he had treated people with compassion and respect?”

Walk the Talk:   Steve would eschew certain perks like a private parking spot and then park nearly every day in the handicapped parking spot.  What kind of jerk does something like that?  You are much better off taking the private space than pretending to be egalitarian and then deciding to violate the rules whenever it suits you to do so.  The people you lead will see that your actions don’t match your statements.  That in turn just makes you another pompous stuffed shirt.

Don’t Steal Your People’s Ideas and Accomplishments:   Great leaders inspire their teams to accomplish great things.  Few things are as deflating to team morale as stealing the ideas and accomplishments of the team and representing them as your own.  Isaacson’s book has plenty of examples where Jobs did just that, and it is clear from the reaction of the people that they felt slighted.  You will always get credit for team accomplishments even if you don’t try to do so.  You are better off ensuring that the folks who truly contributed to the accomplishment get recognized appropriately.  On the flip side, you should always take the blame for team failures – it is part of your job.  That’s not to say that you shouldn’t turn around and coach, develop or fire those who did not perform – you should.  But you can never delegate accountability and you are ultimately accountable for each and every failure.

Use Data and Evidence:   Steve apparently had a number of quirks.  He thought, at one point, that eating an apple (or fruit) only diet would keep him from having BO.  He unfortunately believed, with very little data or evidence, that special diets might help him in his fight with cancer without surgery even when friends and medical professionals urged him to have an early low risk surgery with a high rate of success.  There is no doubt that Steve had great intuition in certain areas such as the development of high tech products.  But as the Dunning-Kruger effect tells us and as Steve’s unfortunate choices show us, we are terrible at identifying where we are great and where we aren’t – or where our intuition is great and where it is not.  As a result, relying on our intuition when data exists that can guide our approaches is a recipe for disaster.  At the very least, data can be confirmatory and even better it can just show us the right answer or path.  Always remember that what matters most is success.  The need to be perceived as being right is for egotistical jerks; the need to get great results is a fiduciary responsibility.  The easiest way to get great results is to rely on great data to help drive great and timely decisions.

You may not remember the 1988 movie The Dead Pool but you probably know the simile that Clint Eastwood made famous “Opinions are like a**holes. Everybody’s got one and everyone thinks everyone else’s stinks.” In this post we’re going to talk about opinions and what you should think of not only other people’s but your own as well.

According to Wikipedia, experts are widely recognized as “a reliable source of technique or skill” and have “extensive knowledge or ability based on research, experience, or occupation” in a domain. It might see odd to use Wikipedia, a crowd sourced knowledge repository, to define “expert” since there is a theory known as the “wisdom of crowds” made popular by James Surowiecki in his book of the same name, that postulates that decisions are better made by a group than a single person, even an expert.

A different perspective on experts comes from another popularization of research by journalist Malcolm Gladwell in his book Outliers. He states “In fact, researchers have settled on what they believe is the magic number for true expertise: ten thousand hours.” Yes, 10,000 hours of practicing something can make one an expert at which point presumably you become a reliable source of knowledge. Gladwell goes on to explain how work or practice influences one’s success.

Once a musician has enough ability to get into a top music school, the thing that distinguishes one performer from another is how hard he or she works. That’s it. And what’s more, the people at the very top don’t work just harder or even much harder than everyone else. They work much, much harder.

While I agree with Sun Tzu’s “the more you sweat in peace, the less you bleed in war” and Louis Pasteur’s “chance favors the prepared mind”, my own experience has proven that opinions can be and often are wrong. An example comes from the time I spent at an online advertising company. Several of the senior exec team were discussing the look and feel of advertisements on publishers’ pages. We were all of the “expert opinion” that ads formatted a certain way would lead to improved performance. Given my six sigma background, I decided to run a quick test to “prove” our intuition. The results were startling in that they were the exact opposite of what we were sure was going to be correct. This resulted in us taking advantage of this insight to improve our advertisements performance and it also taught most of us a great lesson, test your assumptions as well as the unknowns.

There are so many easy-to-use A/B testing frameworks that you can use, there really is no excuse not to do so. Despite some designer’s resistance to use data to drive the look and feel of sites, this is how the largest corporations turn basis point improvements into millions of additional dollars in revenue. If you want to be an “expert”, besides practicing for 10,000 hours, you should adopt Socrates’ mindset of “the more I learn, the more I learn how little I know.”

In this third installment of our “Agile Organization” series we discuss the qualities and attributes necessary for someone to lead a group of cross functional Agile teams in the development of a web-centric product.  For the purposes of this discussion, the Agile Executive is the person responsible for leading a group of agile teams in the development of a product.

In a world with less focus on functional organizations such as the one we’ve described in our Agile Organization articles, it is imperative that the leadership have a good understanding of all domains from the overall business through product management and finally each of the technical domains.  Clearly such an individual can’t be an expert in every one of these areas, but they should be deep in at least one and broad through all of them.  Ideally this would have been the case in the functional world as well, but alas functional organizations exist to support deep rather than broad domain knowledge.  In the Agile world we need deep in at least area and broad in all areas.

Such a deep yet broad individual could come from any of the functional domains.  The former head of product management may be one such candidate assuming that he or she had good engineering and operations understanding.  The head of engineering and operations may be heads of other agile teams, assuming that they have a high business acumen and good product understanding.  In fact, it should not matter whence the individual comes, but rather whether he or she has the business acumen, product savvy and technical chops to lead teams.

In our view of the world, such an individual will likely have a strong education consisting of an undergraduate STEM (science, technology, engineering or math) degree.  This helps give them the fundamentals necessary to effectively interact with engineers and add value to the engineering process.  They will also have likely attended graduate school in a business focused program such as an MBA with a curriculum that covers finance, accounting, product and strategy.  This background helps them understand the language of business.  The person will hopefully have served for at least a short time in one of the engineering disciplines as an individual contributor to help bridge the communication chasm that can sometimes exist between those who “do” and those who “dream”.  As they progress in their career, they will have taken on roles within product or worked closely with product in not only identification of near term product elements, but the strategic evaluation of product needs longer term as well.

From the perspective of philosophy, the ideal candidates are those who understand that innovation is more closely correlated with collaboration through wide networks than it is to the intelligence of one individual or a small group of people.  This understanding helps drive beneficial cognitive conflict and increased contribution to the process of innovation rather than the closed minded approach of affective conflict associated with small groups of contributors.

In summary, it’s not about whence the person comes but rather “who the person is”.  Leading cross disciplinary teams requires cross disciplinary knowledge.  As we can’t possibly experience enough personally to be effective in all areas, we must broaden ourselves through education and exposure and deepen ourselves through specific past experiences.  Most importantly, for a leader to succeed in such an environment he or she must understand that “it’s not about them” – that success is most highly correlated with teams that contribute and not with just being “wickedly smart”.

It doesn’t matter if you run a commerce site, a services product (such as a SaaS offering) or simply use your homepage to distribute information:  The table stakes for playing online is high availability.  So many companies just take for granted that they will be highly available because they have multiple instances of systems and multiple copies of their data.  This assumption of availability will likely, at the very least, cost you significant pain and in the extreme cost you either significant market share or close your doors as a business.  Customers expect the unachievable – 100% availability.  At the very least you need to give them something close to that.  What will happen to you if you have a data center failure?  How about if a DBA accidentally drops a critical table in your production database?  What will you do when that marketing campaign triggers a near overnight doubling of traffic?  What happens when that new feature has a significant performance bug and gets adopted so quickly that it brings your entire site to its knees?

We often tell our clients that they should treat high availability as a feature.  Unfortunately, it is a somewhat expensive feature that requires constant investment overtime to achieve and maintain. It is a must have feature that will only differentiate your firm if you have competitors who do not make similar investments; when competition exists, customers are more likely to leave a site for a competitor due to availability and performance issues than nearly any other reason.  If you don’t believe us on this topic, just go ask the folks at Friendster.

Treating availability as a feature means measuring availability from a customer perspective rather than a systems or device perspective.  How many times did customer requests not complete?  In this regard, availability now becomes a percentage of failed transactions against an expected number of transactions.   We define an approach to accomplish this in our first book “The Art of Scalability”.  Every executive in the company should “own” the availability metric and understand its implication to the business.    You should track how much you invest in availability over time and significant decreases in engineering or capital should be questioned as it may be an early indicator that you are under investing and a harbinger of hard times to come.

One of the most common failures we see is to assume that disaster recovery is something that only big companies need.  Make no mistake about it, disasters do happen and given enough time they will happen to you.  Data centers catch on fire, have water (sprinkler) discharges that ruin equipment, have complete power equipment failures that take hours to fix and are prone to damages from vehicles, earthquakes, employees and tornados.  In our past lives as executives and current roles as advisors we’ve seen no less than 4 data center fires, 2 data centers incapacitated from earthquakes and tornados and one data center leveled by a truck running into it.  You are never too young to invest in DR.

And DR need not break your bank.  The dials of RTO (recovery time objective) and RPO (recovery point objective) allow you to determine how much you will invest.  Perhaps you simply replicate your databases to a smaller set of databases at a remote datacenter and have a copy of each of your systems there with an additional copy ready “in the cloud”.  While you won’t be able to run production from that data center, you may be able to leverage the cloud to add capacity for relatively low cost by cloning the cloud based systems.  Such a solution has a fast recovery point objective (you lose very little data) and a moderate recovery time objective (several hours) for very low comparative cost.  Of course, you would need to test the solution from time to time to show that it is viable, but it’s a cheap and effective insurance policy for the business.

So remember – availability is your most important feature.  Customers expect it always and will run away from you to competitors if you do not have it.  Create an availability metric and ensure that everyone understands it as a critical KPI.  Evaluate the company spend against availability quarterly or annually as an additional indicator of potential problems.   Assume that disasters happen and have a DR plan regardless of your company size.

We wrote a post last Sept about successful acquisitions. In that post we first struggled with how to actually define a “successful” acquisition. After that we postulated that there were two primary methods of achieving what would in general be considered a successful outcome from an acquisition.

The first method is by overwhelming the acquisition’s culture and turning it into the acquiring culture as fast as possible. I called this the GE-approach because of all the acquisitions I saw while at General Electric during the 90′s, this appeared to be the dominant strategy. The second approach is to leave the acquisition completely alone and let it run autonomously. The only tie to the acquiring company is through financials. Reading an article recently I was shocked but pleased to see that academic research had arrived at similar strategies for successful mergers and acquisitions.

Clayton Christensen, Harvard professor and author of books such as The Innovator’s Dilemma, wrote an article recently in HBR with several other authors about the new M&A playbook. In this article the authors state that studies indicate that mergers and acquisitions fail over 70% of the time. Much has been written and studied about this but from the perspective of attributes of the deal. Christensen et al suggest that the problem isn’t attributes of the deal but that executives fail to match candidate acquisitions to the strategic purpose of the deal.

The article states that there are two reasons to acquire a company, to boost your company’s current performance or to reinvent your business. To extend your business but not fundamentally change how you compete, an executive should buy a company with resources aligned with the current business and fold them in, letting the acquisition eventually die. This is what we described as “overwhelming the acquisition’s culture” or the GE-approach. To reinvent your business, executives should seek companies that have a different business model put resources into it and let it grow. This is what I see as our approach of leaving the acquisition alone letting it continue to grow, perhaps providing financial resources from the parent company.

If you are a technology organization within a Software as a Service (SaaS) company, there is no such thing as an “internal customer”.  We often see this anachronistic IT phrase thrown around in web X.0 companies by executives and engineers who simply have not adopted the new SaaS mindset.  Do you think you’ll hear the left offensive tackle of an NFL team refer to the quarterback as his “internal customer”?  The quarterback consumes services (energy to block opponents) of the left tackle – so why wouldn’t he be a customer?  The answer is simple – because the notion of a customer relationship is different than the notion of a relationship within teammates.

The first reason why your teammate isn’t your customer is because he or she is, well, your TEAMMATE.  Customers are someone for whom you produce a service or product and teammates are someone with whom you work to accomplish a goal.  The difference between working FOR someone and working WITH someone is HUGE.  This difference creates a contextually activated identity that forces you to think about customers in a different light than you would a teammate.  Very often, as we’ve written before, this can result in affective (role based or bad) conflict between teams.  Affective conflict is bad and it destroys shareholder value.  Working as a team is important and customers aren’t part of your team.

The next reason that your teammate isn’t your customer is that the customer is always right.  Your teammate isn’t always right.  You need to debate certain points as a team to come to better solutions.  This isn’t affective conflict, it is cognitive conflict and if handled properly it is good and helps to create shareholder value.

The most important reason there isn’t a customer relationship here is that your teammate isn’t paying!   “Servicing” your teammate (uggh…that’s an ugly term) doesn’t create shareholder value.  Working as  a team to delivery a service or product to your  “real” customer is what creates shareholder value.  One design, one approach, one ruthless drive as a team to get across the goal line is what is necessary to thrive and succeed.

So stop using the ugly “internal” C word in your SaaS company.  It doesn’t have a place there.  Let the old world, internal IT folks continue to provide services to their internal customers.  Start acting like a team, designing and building services rather than software.

The strategic fit camp emphasizes strategic analysis and negotiation prior to the acquisition whereas the organizational fit research emphasizes the integration of day-to-day operations post acquisition. There has even been recent research on the impact of the acquisition process itself, which makes sense given that first impressions are established during this phase. I’ve had the good fortune of seeing acquisitions from all different perspectives, as the acquired, as the acquiree, as a consultant of the acquiree, etc. I think there are two models that result in successful acquisitions.

First off defining a successful acquisition is tough. Whether or not the acquiring company writes off the purchase cost in a few years might be one way but these write offs can include goodwill which is the amount of the purchase price paid above the value of the target’s identifiable net assets. There are of course accounting rules for testing impairment of goodwill that may require it to be written off. Another way of testing this might be by calculating Return On Investment (ROI) for the cost of the acquisition. A third way of determining success would be whether the acquired company’s product offerings continue 3 or 5 years later. If the acquiring company has discontinued the acquisitions products the purchase might be considered a failure. Lastly, I tend to think of a successful acquisition like Justice Potter Stewart tried to explain what is obscene by saying “I shall not today attempt further to define the kinds of material I understand to be embraced … but I know it when I see it.”

Whether there is a clear definition or I know it when I see it, there appear to be two paths to get there. The first is what I term the GE-approach because of all the acquisitions I saw while at General Electric during the 90′s, this appeared to be the dominant strategy, although I’m sure many other companies have similar methods. It’s simply an approach of overwhelming the acquisition’s culture and turning it into a GE culture as fast as possible. They did this by sending current GE employees into key positions at the acquisition and sending the acquisitions employees to lots of GE training. Within the first year the acquisition was on the GE strategic planning calendar, using GE financial systems, and following GE’s HR guidelines…they were a GE company by that point.

The second approach is to leave the acquisition completely alone and let it run autonomously. The only tie to the acquiring company is through financials. The parent company acts like a board of directors, approving annual budgets and determining the reinvestment ratio. The acquiree is left to their own to manage the day-to-day operations, processes, etc.

If you’ve seen other successful acquisitions handled differently let us know your thoughts.

If I get another phone call from another recruiter about a “Chief Innovation Officer” search, I may just hang myself from my hotel light fixture with my belt.  Don’t get me wrong – I’m not angry at the recruiter (other than for wasting some of my time) – I’m mad at the CEO or person advising the CEO who come up with such a lame title.  Why am I so upset over the name? Pull up a chair and grab a cup of coffee.  You don’t want to miss this rant.

My first gripe is with the name of this “position”.  The name just sucks and flies in the face of everything we know about innovation.  In some companies, the Innovation Officer might just be a rebranded VP or SVP of product.  I’m almost okay with that – except for the fact that in this case it is a complete misrepresentation of what the person is doing.   If the person is something other than the head product person, well, that’s when this position really is nothing more than a shareholder wealth incineration device.

This moronic title seems to imply that there is a person “responsible” for innovation within a company.  Anyone who believes that one person can somehow be responsible for innovation is clueless about whence innovation comes.  You can no more “control” innovation than you can domesticate a rabid dog hyped up on meth.  You can certainly “kill” innovation, just as you can put down that rabid junkie dog – and giving someone a business card with Chief Innovation Officer on it is like putting a 240 grain slug in that dog.  Goodbye junkie dog and goodbye innovation.  The dog will probably die a more humane death however, as the Chief Innovation Officer will kill innovation under the crushing weight of power point presentations and spreadsheets.

Innovation simply can’t be controlled.  It can be “captured”, it might be “harvested” and it certainly can be “found”.   In some cases, it might even be able to be “directed” with the right questions and incentives.   But “controlled”?  Give me a break.  Capturing, harvesting and finding are all by the company culture – not a single individual.  And as we all know, that culture is most often affected by the CEO and to a lesser degree by each level below the CEO.  This is one of those things, then, that the CEO can’t delegate.  It’s not a position – it’s a shared responsibility.  How do you incent people to innovate?  How do you find little pockets of innovation that hide within the organization but never become apparent because your processes require it to be presented within a 40 page Power Point deck?

My partner, Tom Keeven, knows how.  Tom is a man of varied interests.  One interest is running a pizza parlor in Carmel.  His employees come to him with suggestions all the time.  “Let’s start a delivery service”, “Why don’t we make a low carb pizza dough?”, “Let’s advertise in local hotels”.  Tom doesn’t tell them to run off and build a presentation – he listens to them with great interest.  He rewards them for great insights.  He tells them to experiment and try things out.

Google allows engineers to work on interesting problems with great benefit to the innovation process.  Granted, few of these innovations have paid off and the resulting shareholder dilution is very large.  But the process of bottoms -up, “grass roots” innovation produces results in terms of number of innovations brought to market.  Sooner or later one of them will pay off – the question is “at what cost”.

In summary, innovation isn’t an organization, it’s not a title and it’s certainly not something controlled from the top.  There are things you can do to nurture it and maybe even slightly direct it – but there is little you can do to control it.   You can’t hire a person to control it and you are just wasting your time if you expect to try to create an organization to “innovate”.  If you want your team to innovate, work on creating a risk tolerant culture and work to incent your team for their innovation efforts.  Lower the cost of innovation by eliminating ridiculously complex and burdensome innovation hurdles like executive presentations.  Change the ridiculous titles of your innovation officers to something useful and stop wasting shareholder wealth.

I’ve noticed lately that more companies are putting up signs in hallways and cube farms requesting that people avoid having conversations in these areas. While having a nice quiet work environment makes sense to me as a developer, doesn’t this completely void having people work beside each other? The ad hoc/hallway/water cooler/coffe machine conversations or ones overheard when cube mates are chatting about a new feature are one of the primary benefits of having people work in small open environments.

I haven’t done any sort of scientific study but it seems that these sort of “please be quiet” signs are more prevalent at larger companies. These are the same ones that are trying to mimic the small startup with agile development processes or open work spaces to compete in a fast moving SaaS marketplace. Imitating the actions without understanding the purpose or allowing old school corporate policies to overrule are surefire ways to tank the initiative.

A parallel to the “please be quiet” sign is allowing corporate IT to dictate the architecture of the SaaS offering based on a corporate standard that works for the ERP system. Running Oracle ERP on a 16-way system might be the vendor recommended, preferred approach but for scaling a SaaS offering this is a quick way to run up the costs and ensure lower availability. We often use the analogy of goldfish and thoroughbreds for comparing small, cheap 1U servers with large, expensive multi-processor boxes with lots of memory. The goldfish (small, cheap servers) are inexpensive to purchase and replaceable while the thoroughbred (large servers) are expensive to purchase/maintain and cause big impacts when they go down.

The take away to all of this is that if your part of a corporate initiative to run an internal startup or deliver a Software as a Service from inside a larger organization, don’t allow corporate policies to prevent your success. The differences in approaches, architectures, organizations, and offices have a purpose and should not be discounted as non-critical to the success of your initiative.

I saw this Nike commercial with Michael Jordan talking about how much he had failed in his career and this got me thinking about the debate of whether or not entrepreneurs should “fail early, fail often” as the saying goes. A quick Google timeline shows how popular this term has grown in our vernacular over the past two decades. No doubt following the trend of high tech entrepreneurial failures.

Digging deeper into some of the more popular entrepreneurial technology bloggers, I found one of the earliest references to failing early from Jeff Atwood from Coding Horror. In May ’06 he stated:

“The best software developers embrace failure — in fact, they’re obsessed with failure. If you forget how easy it is to make critical mistakes, you’re likely to fail. “

And Jeff continues in the same post:

“I say the more failed projects in your portfolio, the better. If you’re not failing some of the time, you’re not trying hard enough. You need to overreach to find your limits and grow. But do make sure you fail in spectacular new ways on each subsequent project.”

Next up that same year in September, Matt from Signal Vs. Noise, the 37Signals blog, quoted Jonathan Ive, VP of Industrial Design, Apple:

“Getting Real is all about iterations too. “Be excited to be wrong because then you’ve discovered something new” is a neat way to put it (btw, so is Fail early, fail often).”

Fast forward to February 2009, Jason, also from Signal vs. Noise states:

“It’s true: Everything is a learning experience. Good and bad, there’s something to be learned. But all learning isn’t equal. I’ve found that if you’re going to spend your time pondering the past, focus on the wins not the losses. The lessons learned from doing well give you a better chance at continuing your success.”

Hmmm, it seems like there has been a change in attitude towards failure. As a final example we have Matt from Signal vs Noise again in December 2009 stating:

“The idea that you should “fail early, fail often” is bogus. Plans are guesses. Interruption is the enemy of productivity”

What are we to make of this change in advice from some of the most popular names in entrepreneurial advice? Well this study from Harvard published in 2008 might explain some of it. In it the authors claim that entrepreneurs with a track record of success are much more likely to succeed than first-time entrepreneurs or those who have failed before. The primary reason for this is that the successful entrepreneurs exhibit persistence in selecting the right industry and time to start new ventures.

“… all else equal, a venture-capital-backed entrepreneur who succeeds in a venture (by our definition, starts a company that goes public) has a 30% chance of succeeding in his next venture. By contrast, first-time entrepreneurs have only an 18% chance of succeeding and entrepreneurs who previously failed have a 20% chance of succeeding.”

Alas don’t give up hope for redemption from failure, the study does show entrepreneurs who have previously failed have a slightly higher subsequent success rate than first-timers, suggesting that they learn something from their failure.
My take on all this failure talk is that both camps are correct, depending on the magnitude. Failing on small things like a wrong product feature should be done early and often because no matter how much you think you know your users, you nor they know exactly how or what they will use in the future. But you should avoid if at all possible failing on the big things like a product line. These large failures take too much time, energy, and resources that can never be recouped. If you do happen to fail big you can at least take comfort from the fact that there is something to be learned. And that lesson is to fail at the small stuff so that you don’t fail at the big stuff.