AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Category » CEO


In his book, The Lean Start-Up, Eric Ries defines a start-up as a “human institution designed to deliver a new product or service under conditions of extreme uncertainty.” Operating in uncertainty is inherently risky. What makes many start-ups successful, among other things, is their ability to mitigate risk. One way a company can remain adaptive and responsive during uncertainty, and therefore reduce risk, is employing an agile development model. A good example of such an organization is Spotify, which continues to embrace, practice, and improve on agile fundamentals even after growing to over 30 development teams in three different locations.

There are striking similarities between the way Spotify organizes their teams and the way U.S. Army Special Forces organizes their Operational Detachments-Alpha, aka “A-Teams.” It makes sense that the two would be similar because the A-Team was in fact an innovation designed to deliver a “service” under conditions of extreme uncertainty. In this case, the “service” was military assistance to the struggling Republic of Vietnam, and later to guerrilla forces and resistance movements waging unconventional warfare against the North Vietnamese. The U.S. Army had never undertaken a mission similar in objective and scope. They did not know the conditions, the support, or the communication capabilities that their soldiers would find. The U.S. Army needed a self-sustaining team with all the skills necessary to complete a mission with a broad and evolving scope. Moreover, the team would have to operate autonomously and would have to be trusted to make decisions normally left to upper echelons.


The U.S. Army assessed and selected twelve of their most seasoned veterans, and then trained them each in one of six specialties: medicine, engineering, communications, weapons and tactics, or intelligence. Having redundancy in each position was desired in case one soldier got injured, and it also gave the team the ability to pair a new member with a more senior member of the same specialty. Redundancy also facilitated the ascension of the team’s most senior soldier to the role of Operations Sergeant. The A-Team Operations Sergeant is comparable to the role of Spotify’s Agile Coach, or sometimes called a “Scrum Master” in other organizations. He no longer fills a specialty function on the A-team. He is the team’s mentor and draws on his experience to coach the team. He wants his team to be efficient and safe, which equates to a quality product in their realm. It is the also the Operations Sergeant’s job to advise and informally train the A-team’s commander on the team’s competences and potential with respect to their assigned mission. He ensures that the commander does not over commit the A-team to the stakeholders.

The A-Team was designed to operate deep behind enemy lines. They would not maintain frequent contact to their command. Because the complexity of the mission at hand, the A-Team worked not only for their command, but on the on behalf of many other stakeholders, such as the U.S. State Department, CIA, and other government agencies. In the absence of guidance from their command, and other key stakeholders, it is crucial that the commander, with input from the team, manage the team’s priorities with respect to the mission’s goals. Just like Spotify’s Product Owner, it is the A-team’s commander who ensures the team is on track to accomplish the stakeholders’ desired end state by prioritizing projects and associated tasks.

The way that Spotify tweaked the idea of a Matrix Org to facilitate product-centered teams while managing professional development and adherence to standards across functional areas resembles the method used by A-teams. Spotify organizes their development teams or “Squads,” into “Tribes” of 100 contributors of varying disciplines such as software engineering, hardware engineering, DBAs, etc. Each Tribe has a “Chapter” in which contributors with the same competencies are grouped. Chapters are led by “Chapter Leads” who are responsible for the quality of work produced by his or her chapter. Special Forces A-Teams are organized into “Companies” of six multi-disciplinary teams (around 70 people). A-Team “Companies” have a headquarters unit that is responsible for the professional development and standards of each specialty on the team. As an example, the medics on each team practice medicine under the license of a medical doctor assigned to the headquarters unit. The doctor’s function is similar to that of a Chapter Lead because he is responsible for each medic’s continued professional growth, refresher training, and the overall standard of care that is provided by his chapter.

The A-Team model’s structure has not significantly changed since their inception. During the Vietnam War, and most recently in Iraq and Afghanistan, Special Forces A-Teams have produced tangible results where larger, conventional military units have not. Their self-sufficient and decentralized approach allows the team to focus on mission accomplishment. The conventional Army’s centralized and hierarchical structure doesn’t allow for the flexibility needed to mitigate risk in uncertain environments. Results often become secondary to strict adherence to protocol for protocol’s sake, and the approval of long reporting chains. Similarly, in the technology industry, companies like Spotify who adhere to agile fundamentals are able to scale and grow successfully amid the uncertainty, while larger, less “agile” organizations become bogged down in bureaucracy, and can not navigate the evolving and uncertain market.

Comments Off on A-Teams

Recent Interviews

Below is a list of recent interviews by AKF Partners, Mike Fisher & Marty Abbott on a variety of topics including scalability, healthcare.gov, and customer misbehavior:

Make sure you follow Marty and Mike  and AKF’s Facebook Pages to keep up to date with the latest.



Power of Customer Misbehavior

AKF Partners


Comments Off on Recent Interviews

Wine-Dark Sea

“There is a land called Crete in the midst of the wine-dark sea, a fair land and a rich, begirt with water, and therein are many men innumerable, and ninety cities.” – Homer (fl. 850 B.C.), Odyssey, Book XIX

And some one shall some day say even of men that are yet to be, as he saileth in his many-benched ship over the wine-dark sea…” – Homer (fl. 850 B.C.), Iliad, Book VII

The phrase “wine-dark sea” appears dozens of times in the Iliad and the Odyssey resulting in much debate at what Homer actually meant by the phrase. One theory is that he was describing an outbreak of red-colored marine algae. Another theory put forward by researchers Wrignt and Cattley, was that the Greeks mixed highly alkaline water with their wine, resulting in blue-wine.

The explanation that sounds most plausible to me is that ancient Greeks did not have a word for “blue”. At the time of Homer’s writing there were only five colors (metallics, black, white, yellow-green, and red). Lacking the appropriate term to describe the world, they used what they knew.

Many of us are not unlike the ancient Greeks. We can’t describe a new architecture or we can’t imagine our business differently because we don’t have words for it. Whether you are just out of school and don’t have a ton of experience or your more senior but haven’t seen highly scalable system architectures, both leave you blind to “seeing” a different architecture or business model. Another way we’re blinded is just by being at a business for a number of years. Companies and institutions have collective beliefs, cultures, and even memories that become our own. This is completely normal. If you don’t adapt to the standards and norms of the company you’re going to have a rough go of it. Just like the body tries to reject transplanted organs because the body doesn’t recognize the foreign object, companies reject employees and even leaders who don’t fit or adapt to fit.

So, what is one to do if you know you suffer from a blind spot? The solution to this is to bring in new people or, occasionally, consultants who have seen this before and can help you learn to describe the new world. As made famous by many twelve-step programs, the first step is to “admit there is a problem”. If you can’t admit that you might not see or be able to accurately describe everything, you’ll eventually get blindsided by either the inability to scale or, even worse, a competitor able to see things differently.

Comments Off on Wine-Dark Sea

Conflict and Innovation

Executives often complain to us about the level of conflict within their teams, or the abilities of their teams to resolve conflict.  Often, in the same session, they will wonder as to why they don’t achieve greater levels of innovation in their products.  Sometimes we hear things like “My team is too conflict avoidant – they won’t resolve their issues”, or “I simply don’t get why product and engineering won’t get along”, or “My engineers (or finance team, or team XYZ) simply won’t listen to the rest of the business teams”.  With respect to innovation, quotes range from “Why aren’t we more innovative” to “It seems like I’m the only one with ideas around here!”  Well guess what?  It’s YOUR FAULT!

The simple truth is that what we do and just as importantly, do not do as executive teams sets the stage for the creation and escalation of conflict and maximization or minimization of innovation within our teams.  Before I get into some of the drivers and results of both conflict and innovation, let me first spend some time trying to define some terms and clear up some fallacies surrounding the term “conflict”.

2 Types of Conflict

Psychologists and sociologists, especially those who study conflict, conflict resolution and innovation, recognize the following:

1)      Affective Conflict (sometimes termed Role Based) is “bad conflict”.  Affective conflict typically involves “who” should be responsible for doing something or “how” something should be done.  Any way you cut it, our jobs as leaders are to try to minimize this type of conflict and set up systems to reduce the probability that it happens.  Affective conflict is never good.

2)      Cognitive Conflict is “good conflict”.  This type of conflict deals with “what” should be done and “why” something should be done.  When handled properly, it helps increase strategic possibilities, open up new doors for innovation and drives teams to better answers.  When left unhandled by leaders, it will often escalate into affective conflict and be detrimental to overall performance.

I will just call these terms “bad conflict” and “good conflict”.

Outcomes (or consequences) of Conflict

Here we see why affective conflict is “bad” and cognitive conflict is “good”.

1)      High levels of bad conflict are highly correlated with lower morale, high rates of employee turnover within teams, slower time to market, lower levels of financial/business performance, and lower levels of perceived performance within teams.  Bad conflict minimizes and very often can completely eliminate innovation within a team.

2)      High levels of properly handled good conflict are highly correlated with higher morale, higher employee retention, higher levels of innovation, happier teams, faster time to market and higher levels of financial and business performance.

Put simply, you want lots of quickly resolved and properly facilitated good (“what and why”) conflict and very little bad (“who and how”) conflict.

Drivers of Bad Conflict

Research indicates that there are many drivers of “bad” conflict.  Here are some of the most frequent drivers:

1)      Team Alignment:  Without getting into the theoretical specifics, teams find themselves in conflict along team boundaries that are defined by organization structure and the resulting individual identities.  If you have an “engineering team” and a “product team” on your organization charts, the employees will identify with one or the other and sometimes conflict along those boundaries.

2)      Employee Tenure:  Research shows that employees also identify themselves along tenure boundaries.  These may be the “old guard” and the “new employees” or the “founding team” and the “new team”, etc.  While not codified within an org chart, this stratification of employee identities can lead just as much to conflict creation as an actual organization.

3)      Leadership Approach:  Engaging in quid-pro-quo management (“Do this for me, and I’ll do that for you”) is highly correlated with conflict creation.  Individuals think of themselves, rather than a team.

4)      Loosely Defined Responsibilities:  Chaos breeds conflict.  When people don’t understand the boundaries and expectations, they attempt to expand or define each for themselves which in turn increases strife.

Out with the Bad and In with the Good

Bad conflict is inversely correlated with good conflict.  The more bad conflict you have, the less good conflict you have.  Good conflict on the other hand correlates directly with innovation.  The higher the good conflict, the higher the level of innovation.  The fix to ending bad and promoting the good is to address each of the areas above.

1)      Team Alignment:  Create cross functional teams aligned around product or service initiatives – not functions or experiences.  Each team should have all the experience across all domains that it needs to be successful.

2)      Employee Tenure:  Eliminate old and new employees who cling to tenure based identities.  Ensure everyone understands there is one, and only one company identity (though there may be product identities within the company – but each of these has everything they need to be successful).

3)      Leadership Approach:  End quid pro quo leadership and talk about higher purposes and team accomplishments.  Make the job about something other than just the individual.  Eliminate people who are “in it for themselves” and won’t contribute to the higher cause.

4)      Loosely Defined Responsibilities:  A leader has many responsibilities and one of them is to eliminate uncertainty where possible.  Help people quickly resolve conflict with roles.  Don’t let employees come into conflict or stay in conflict about competing roles and responsibilities.


What Makes You Successful?

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.


Preparing For a Financing Round or an Acquisition

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.

1 comment

Growing Too Fast

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?

Comments Off on Growing Too Fast

More Leadership Lessons from Steve Jobs

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.


Opinions Don’t Matter

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


The Agile Executive

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

Comments Off on The Agile Executive