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.

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.

I know I’ll remember where I was and what I was doing when Steve Jobs passed away.  You simply can’t do what we do for a living – what we’ve done for a good portion of our lives – and not have had Steve touch a significant portion of your life.

It’s not just about what Mr. Jobs did at Apple, or about his insane product genius, or about his seemingly super-human ability to bring innovative products to market at just the right time (or almost the right time in the case of the Newton).    While those things alone would absolutely be enough to take a few minutes and remember him, his impact reached far beyond Apple or the direct users of his products.

Steve, though his genius, created new market segments and made existing and dominant players in existing segments even better.  While the Windows interface has been much maligned (in many cases rightfully so) for years, imagine where it would be without Apple and the Mac to chase in usability.  How much longer would we have been fumbling around with CD and Tape Walkmans without the iPod and how much worse would our workouts be because of it?  How many more years would we be lamenting the existing tablet computer industry had it not been for the iPad?  When would computer mice have gone mainstream if not for the Mac?  Would we still primarily be using dot matrix printers without Apple finding a way to introduce the laser printer to the mass market?

You went way too early Steve.  Thanks for everything that you’ve given us – both the things that you and your companies created as well as the standard of excellence you set for your competitors.

As authors, we are always interested in what our readers find interesting or useful.  Online we can see general article level interest through hit rates, etc.  In the print world, we can gauge interest based on book sales.  But neither of these approaches allows us to see what within an article might spark interest or be seen as useful by our readers.    Amazon’s Highlight utility within their Kindle format gives us that opportunity.  We thought we would share the most highlighted pieces of The Art of Scalability with you here.  You can see these quotes as well as new ones and changes in number of highlights over time here

 

You can delegate anything you would like, but you can never delegate the accountability for results.  Highlighted by 30 Kindle users

Management means measurement and a failure to measure is a failure to manage.  Highlighted by 28 Kindle users

As your resource pool dwindles, the tendency is to favor short-term customer facing features over longer-term scalability projects. That tendency helps meet quarterly goals at the expense of long-term platform viability.  Highlighted by 24 Kindle users

Bad behaviors are as good a reason for removing a person from the team as not having the requisite skills, because bad behavior in any team member creates a vicious cycle of plummeting morale and productivity.  Highlighted by 21 Kindle users

An organization that does not foster the creation, distribution, and acceptance of standards in coding, documentation, specifications, and deployment is sure to decrease efficiency, reduce quality, and increase the risk of significant production issues.   Highlighted by 19 Kindle users

These usually consist of teams responsible for the overall architecture of the product (architecture), the software engineering of the product (engineering), the monitoring and production handling of the product (operations), design and deployment of hardware for the product (infrastructure engineering), and the testing of the product (quality assurance).  Highlighted by 18 Kindle users

By having a single person or organization responsible, you are abiding by the “one back to pat and one throat to choke” rule. A gentler way of saying this is that distributed ownership is ownership by no one.  Highlighted by 17 Kindle users

Leadership is important to scale as it not only sets the direction (mission) and destination (vision) but it inspires people and organizations to achieve that destination.  Highlighted by 16 Kindle users

The tool we most often use is called RASCI. It is a responsibility assignment chart and the acronym stands for Responsible, Accountable, Supportive, Consulted, and Informed. Highlighted by 16 Kindle users

Although there are always exceptions even to this broad range of choices, our low boundary for team size is six and our upper boundary is 15.  Highlighted by 15 Kindle users

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”.

Having discussed why organizations arranged along functional boundaries (e.g. production or engineering, operations, infrastructure, QA, etc) and multi-disciplinary Agile teams are often at odds and counterproductive, we now propose a method of organizing product teams more aligned with the Agile process and Agile methods.

The potential solution is really very simple.  The design goals behind the solution are: maximization of individual capabilities of any given team to quickly and efficiently create solutions and solve problems; creation of ownership of individual products (or portions of products) and the business success metrics associated with that product in order to maximize innovation; maximization of morale through a sense of ownership and delegation of decision making; and reduction in time to market through the elimination of non-value added conflict.

The solution is clear given these goals – eliminate functional organizations and align the organization to architecture specific services.   In the ideal case, each of the senior leaders of these organizations are capable of owning and leading one more complete agile teams.   The number of teams that an executive has is likely going to depend on the size of the company, the size of the engineering and product teams and the number of discrete services in the company’s product architecture.

Here we come to a very important point – it is critically important that the architecture, the process and the organization structure be aligned to reap the benefits of such a change.  If the product architecture continues to be monolithic, nothing is solved.  The solution described above will get you no further than an “agile overlay across functional organizations”.  Each division of agile teams needs to own their own services so that disputes, problems and opportunities can be resolved or capitalized within the team.  This rapid resolution starts to slow down when outside resources are necessary to resolve a problem or capitalize on an opportunity.

We readily admit that this new approach to eliminating functional organizations in favor of agile teams isn’t for everyone.  Some companies don’t have the need to segment their architectures into services as they aren’t experiencing rapid growth.  As such, they shouldn’t pay the price of re-architecting their product.  Some companies deliver to very clearly defined specifications and as a result can’t really benefit from the product discovery aspects inherent to Agile or the questionable “final dates”.  These companies are probably better off continuing to develop in a waterfall fashion.  Many companies won’t have the right skill sets at the top to have former functional executives own product sections.

This last issue sets up a topic for another post.  The question we aim to answer is “What are the qualities and attributes of the Agile Executive?”

We’ve done a lot of work with organizations attempting to become more Agile by implementing Agile development practices.  One common problem we see time and time again is that the “old school” way of defining organization structure starts to lose its value in an Agile world.  Here I am specifically talking about organization structures developed around functional roles such as development (or engineering), QA, Operations, Infrastructure, etc.

This old method of organizing, which resembles a Y axis split within the AKF scale cube served our industry well for a long time.  And, for many organizations, it can continue to work well.  It particularly works well in organizations that follow waterfall models as the organization structure mimics the flow and passage of work through certain gates.  The structure is also comforting in its familiarity as most long tenured managers and individual contributors have worked within similarly structured organizations their entire professional careers.

But in the Agile world, this organization structure doesn’t add as much value as in the Waterfall world.  In fact, I argue that it’s counter-productive in many ways.  The first and perhaps most benign issue is that the actual structure of the organization does not foster work-flow.  Unlike waterfall development where one group hands off a project to another in phases (development to QA, QA to operations, etc), Agile methods seek to develop and deploy seamlessly.  To be successful the Agile team needs representation from multiple stakeholders within functional groups.  As individuals now spend most of their time in cross functional teams, what value does the functional group offer?  In essence, these functional organizations become the analog to the “home room” in school.

The next problem is the inherent conflict created between the Agile team and the functional organization.  To be truly effective, the team must be empowered to some degree.  What power or responsibility does the functional leader then have?  If he or she isn’t responsible for a specific product, are they to be given some sort of veto power?  Such a notion has meaning in the waterfall world but really runs counter to the time to market and discovery objectives of Agile methods.  The resulting affective conflict simply doesn’t add value to the overall product.  In fact, as research shows, it destroys value.  Some proponents of continuing with functional organizations might indicate that the functional groups allow for more effective management and mentoring of individuals within their domain.  Given how little time managers truly spend on mentoring relative to other tasks, I highly doubt this is the case for most organizations.  Our experience is that the functional groups spend more time arguing over ownership of certain decisions (affective conflict) rather than mentoring, training and evaluating individual contributors.

Perhaps the largest problem – larger than the lack of support for work flow and the creation of conflict – is that implementing agile processes across functional organizations sub-optimizes innovation.  Research indicates that innovation happens most frequently and beneficially within groups of individuals with diverse and non-overlapping experience across a number of domains (functional and experiential diversity) and with non-redundant links to individuals outside of their organization.  By engaging in beneficial debate (cognitive conflict) on approaches to a certain problem or opportunity, the perspective and networks brought by each person widens the potential solution set.  Alas, this is the true unheralded value of agile development teams that properly incorporate multiple disciplines within the team (QA, dev, product, infrastructure).  Each of these individuals not only brings new and valuable expertise in how to develop a product, they also have contacts outside the organization unlikely to be matched by each of their peers.  Innovation quality and frequency therefore increases.  But the inherent conflict in multiple competing organizational affiliations will dampen this innovation.  So not only is there conflict and a lack of workflow, the potential major benefit is removed or at the very least diminished.

Having discussed the problems inherent to functional organizations and agile processes, we’ll next discuss how a company might “organize” around agile to be more effective.

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.

It’s been awhile since I’ve gone on a rant. Leaving my rants bottled up inside me just means that I’ll take it out on my partners in some fashion (most likely by hiding in their houses and beating them upon entry in the fashion of Cato and the Pink Panther) .   Chief among the things that are ticking me off right now are some ridiculous phrases and approaches to speech that I will term “Corporate Speak”.  This mouth diarrhea is closely related to the “buzzword bingo” games of the mid 2000’s where employees would wait for half retarded executives to flip clichés out at company meetings.   Unlike buzzword bingo, this dribble simply doesn’t seem to have a purpose and we should try to excise it form our speech like the tumor that it is.  Candidly speaking, my partners and I are guilty of some of these ridiculous statements and we are working actively with a speech oncologist to send them into remission.  One warning: if you are speaking about yourself in the third person you may be beyond help.  Third person speech is a clear indication that you should just end your career.

Without further ado, here are the most cancerous phrases:

OK, this isn’t a book review as much as it is a comparison of how the iterative and rapid “productization” of strategy closely parallels Agile methods of software development.  But first, here’s an overview of a particularly good book – Walter Kiechel’s The Lords of Strategy.   I flew through the book – not because I wanted it to end but because I couldn’t put it down.  It’s an incredible history of the people, organizations and ideas that developed the concept of corporate strategy and it’s full of incredible facts and observations.  Take for instance that the notion of strategy consulting as purveyed by the likes of BCG, Bain and McKinsey is only roughly 30 to 35 years old and that perhaps even more interestingly the notion that a company exists to create shareholder wealth is only about 30 years old.  The book does a great job of explaining not only the history of the ideas behind strategy consulting, sometimes told alongside the biography of their inventors, but how those ideas affected the industry for better and for worse.  Ultimately it describes how these ideas “quickened the pace of capitalism” though the reader is left with figuring out whether we are better or worse off for the change.

What struck me as particularly interesting in this book is the parallels one can draw between how corporate strategy (including the product and services surrounding it) developed and how Agile methods of solution development should work.  The germinating idea behind strategy was the identification of the “experience curve” by the Boston Consulting Group.  This curve identified through trend analysis that the longer and more experienced a company became, the lower its cost of producing a certain good or service.  This notion, though flawed (experience alone isn’t what drives cost), came quickly and was brought to market quickly by BCG.  In rapid fashion, the company built upon this to develop the growth-share matrix as its second “product” offering.  Both of these ideas together led to a grouping of offerings that suggested companies take on debt, reduce costs, differentiate themselves on price and expand shareholder value.  The success of BCG led to McKinsey joining the ranks of strategy consultants, Harvard Business School changing its curriculum (via Michael Porter who had now built his own strategy framework – the famous 5 Forces analysis) and created Bain and Company.

Key here is the evolutionary nature of strategy as a product.  In the very early phases, the offerings were quite frankly wrong.  We know now that the notion that companies differentiate themselves on price alone in every industry is flawed.  But the firms and institutions that supported strategy as a product and intellectual endeavor did not try to offer the absolute best solution – they attempted to bring an appropriate solution to the market and then modify it from there.  In effect, for the time, their solution was the minimum viable product.  Did their approach work?  Billions of dollars of consulting revenue and profits and billions in market value would argue it was an effective approach.

While these companies didn’t realize it at the time, they were in fact practicing agile development.  They didn’t know end user requirements – how could they?  The market wasn’t created yet.  They created a quick offering and iterated upon it, simultaneously changing the market demand and adapting to both the shifting demand and their growing understanding of what strategy needed to become.

Where else might agile methods apply?