It is difficult – research shows nearly impossible – for any of us to accurately answer the question of “What makes us successful?”

At the intersection of cognitive biases (especially attribution bias) and the Dunning-Kruger effect lies this (to my knowledge unnamed) phenomenon that keeps all of us from understanding how our contributions might have resulted in a successful outcome.  Cognitive biases cause us to take far too much credit for successes, and incorrectly attribute the reasons for our success.   The Dunning-Kruger effect causes us overrate our abilities to achieve similar success in the future.   All of these work against us in trying to determine what allowed us to be successful.

Incorrectly attributing the causes for our success can be a huge problem.  Imagine that you decide that the reason your company achieved a particular successful outcome is because of your sales ability as a senior executive.  You might be inclined to believe, based on your personal analysis that your sales ability and sales execution will result in similar future successes.  There are two potential problems here.  The first is that we  incorrectly attributed the reason for success when the real reason was due to, for instance, the efficacy of our product.  The second is that we overrated our contribution and abilities when the real credit should go somewhere else.   Clearly both can lead to future disasters down the road.

You may be thinking that many people are successful time and time again by taking similar actions and by employing similar behaviors.  That is absolutely true.  The issue is not whether we can repeat our past successes – it’s that we can’t accurately identify (for ourselves) which actions or behaviors led to those successes.

Research suggests that we are much more likely, if we apply disciplined process, to learn from failures as compared to successes.  Even greater learning can be gleaned from comparing our successes and failures.   Furthermore, involving others helps us triangulate and either validate or invalidate our beliefs as to the causes of both successes and failures.  The key here is disciplined process coupled with introspection and outsider perspective to guard against cognitive bias and eliminate the Dunning-Kruger effect.

In summary:

1)      We are ill equipped to identify the causes of success without outside help.

2)      We are better equipped to identify the causes of failure.

3)      We are best equipped to compare successes and failures and draw conclusions.

4)      It is always best to involve multiple people in the identification of either success or failure.

We spend a good portion of our time performing due diligence on companies that are either looking for financing or preparing to be acquired. We thought it would be interesting if we shared some of our observations on what makes the process go smoothly and what causes problems. In our experience and through working with our clients we believe it’s important that you consider the following:

1) Secret Sauce – First off, you need to figure out your secret sauce. Simply stating that you have the world’s largest online bicycle sharing service is only a start. While a service like bicycle sharing might be a great concept, there should also be an algorithm or business method that isn’t necessarily visible to you and I from the outside. For example, the company may have a pricing algorithm that factors in various demand variables for bicycle rentals on a given day and adjust prices accordingly. Look for something similar with your venture. Figuring out your secret sauce will help to raise your valuation.

2) Open Source – We’re a huge fan of open source tools but you need to be diligent about what you are using. Specifically, keep track of the open source products that you use and be aware of the license under which you are using it. There are many different licenses in use today. Below are a few of the most popular and our, non-attorney, interpretations of them. Note, that there is disagreement among much more erudite individuals than us on the terms of each of these so be sure to check with your legal representative before you use any of them.

• GPL – GNU Public License – You are allowed to use, redistribute and change the software, but any changes you make must also be licensed under the GPL. So that means you have to give everyone else the same rights as you got.
• LGPL – Lesser General Public License – If you modify the software, you still have to give back the source code, but you are allowed to link to it (compile with it) without giving the source code to everything you built back.
• BSD license – Berkley Software Distribution – You can take the code and turn it into a proprietary application and you don’t have to give it back.
• Apache license – Allows the use, modification, and distribution of the software for any purpose but does not require modified versions of the software to be distributed using the same license.

3) Patents – One method of demonstrating value and uniqueness is to build up a patent portfolio. To be valid, your patent must be new, useful, non-obvious, and of a subject matter defined as patentable. Machines, processes, methods, and compositions of matter are examples of patentable ideas. Algorithms and laws of nature (e.g. E=mc2) are examples of subject matter than cannot be patented.

Remember your secret sauce? You should not file a patent on this because as soon as you do it becomes publicly disclosed. Instead this is a trade secret which is information that derives independent economic value from not being generally known. A trade secret can be an algorithm that you have developed and resides in your codebase. In our bicycle example, the renting pricing algorithm is a trade secret.

4) Patent Trolls – As soon as you announce an acquisition or any other news that indicates your company is highly valued, someone is likely to file a lawsuit for patent infringement. Facebook was sued five times in the first two months alone after announcing they were going public. Microsoft recently introduced the “Live Tiles” feature as part of Windows 8. They are being sued by a small operating system company for allegedly stealing the patent on “tiles.” Such a lawsuit will tie up resources in your organization and run up legal fees. Make sure you prepare for this inevitable cost of doing business.

Obviously, none of this guarantees success with fund raising or getting acquired but these are items that we often see stop a process or delay it. Make sure you discuss all of this with your advisers, directors, and attorneys.

When you’re waiting for your startup to achieve the hockey-stick growth, so you can ring the NASDAQ bell in a hoodie, it might seem impossible to grow too quickly. However, there are some serious possible negative consequences of too rapid growth using the wrong metrics, i.e. vanity metrics.

A household brand that we can point to for growing too quickly is Starbucks. Schultz, when he was on his 8-year hiatus from the CEO role, wrote a letter criticizing the Seattle-based company for growing its global chain of 13,000 coffee shops too quickly. He stated that as a result the company was commoditizing itself and losing much of its soul. Upon his return to the CEO role he took actions to close over 600 of these stores. Not only are situations like this harmful to the brand but all those stores employees were negatively impacted as well.

At AKF, we deal with hyper-growth companies every week and sometimes we get to keep up with them over years. The growth of most companies is not steady but rather it is sporadic. When a company has grown too quickly based on the wrong metrics, trouble ensues.

At Quigo (our previous company acquired by AOL) traffic growth would move along steadily until we brought on a large customer and then it might double overnight. But traffic isn’t revenue. Making money on that traffic lagged by weeks or months. Had we celebrate the increase in traffic rather than the really important business metrics (revenue & profit), we might have grown too rapidly. Some of the bad things we’ve personally seen with companies that grow too rapidly based on vanity metrics include:

• Organization – bringing employees up to speed takes time and it is easy to get behind or ahead of the demand curve. Hire too slowly and customers might be impacted but hiring too quickly means either too high of a burn rate or having to lay people off. Growing rapidly in year one and then laying people off in year two causes credibility issues. This in turn might give potential new customers pause and will certainly result in hiring difficulties in the future.
• Valuation – interest, from an investment perspective, in particular types of technology companies waxes and wanes over time. Online advertising companies were hot in 2007 but now it is a much more competitive environment. Social networking was hot before the FB IPO but now people are concerned. Raising money at too high of a valuation, unless it’s the last round, will make future rounds more difficult and painful.
• Office Space – along with hiring too many employees comes building out or leasing too much office space. Obviously this causes excessive burn rates but it also can have morale implications. With too few employees and too much space the team is reminded every day that they haven’t grown fast enough to fill the office. They also might gravitate away from each other (often heading for the available offices) and lose the power of sitting beside each other.
• Hardware – while you might have to buy or lease hardware based on a vanity metric like web traffic, this doesn’t mean you should forget how much revenue and profit this traffic is generating. Traffic that might not bring in the expected revenue should be treated as such. We’ve argued for an R-F-M analysis for storage costs which can be extended to processing as well.

Are you growing too fast or have you seen companies grow to fast?

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.