AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

The AKF Story

Tom Keeven came up with the idea for AKF Partners in December 2006. Each of the founding partners would spend a handful of days a month helping interesting companies with their technology challenges. It sounded like the perfect “lifestyle/retirement job” – help fun companies solve challenging problems while having lots of time on the side for personal projects. AKF was born in February of 2007 with 3 founding partners. When we founded the company in February 2007, we had no engagement model and no unique or differentiating approach for the business. Essentially, our company violated everything we had learned in business school.

Our Defining Moment

One early client stands out as helping us to create our unique and differentiating approach as a growth consulting firm. This company was a post-A series internet startup that had recently run into some fairly serious product problems. The company was the darling of the internet, and their CEO was being talked about in nearly every magazine. The executive team proudly proclaimed that they had a new management approach – one that would change the way companies were managed forever. But what the company thought was novel, we felt was contributing to their problems; the lack of management discipline was allowing product problems to linger unsolved and causing significant issues for the users of their product.

An example that everyone can probably relate to, whether you’re a weekend warrior or seasoned athlete, is a strained or torn muscle.. If a doctor prescribes pain medication, the meds will help treat the symptom of the problem (the pain) but they will neither address the cause of the incident (improper form) nor treat the cause of the pain (tear or inflammation). This early client made it clear that they only wanted our pain medication – technical fixes to the problems they had encountered to date. While we were happy to give them the advice they wanted, we also felt obligated to address the causes of their pain. We told the client if they wouldn’t listen to all of our advice, including how they should manage their team and which processes they should implement, we would leave and not charge them. The client could have the technical recommendations we had already made for free.

AKF’s Focus and Approach

From that moment on, AKF focused solely on client value creation. We believe that creating value for our clients will result in the best possible outcomes for our company. We’ve since told many clients that we won’t work with them if we believe they won’t take our advice. We aren’t simply drug peddlers or professional consultants whose primary goal is to sell more consulting. We provide pain relief in the form of architectural advice and injury avoidance through advice on organizations and processes.

Realizing that our approach of evaluating architecture, organizations and processes was unique within the industry, we wrote our first book, The Art of Scalability, to help clients who couldn’t directly afford onsite services. The book was an Amazon bestseller and now has over ten thousand copies sold. We subsequently wrote Scalability Rules, a companion to The Art of Scalability and a third book, The Power of Customer Misbehavior, which explores the attributes of successful viral products and the companies that build them. Together, these books help teach companies how to drive growth within a market, and service that growth within their products.

We successfully followed this approach of treating both the symptoms (architectural/technology pain) and causes (people, organizations, management and processes) through hundreds of clients until the Healthcare.gov debacle of 2014.

Putting Our Values to the Test

Upon launch, the healthcare.gov website supporting the Affordable Care Act simply could not keep up with user demand and repeatedly crashed. People attempting to sign up for government mandated insurance could not comply with the law. For many companies in our business, this would represent an incredible revenue opportunity. We saw it as an opportunity to help and continue our service to our nation.

The founders of AKF are neither registered democrats nor huge proponents of the Affordable Care Act. That said we do believe that expensive initiatives should fail or succeed based on their merits and not die as a result of easily avoided technical failures. When Jeff Zientz, who was appointed by the President to “fix” the ACA called on AKF asking for help, we agreed as long as we were allowed to contribute to both the technology symptoms and the organizational, management and process causes. We suggested that we do all of these things on a pro-bono basis such that taxpayers could sign up for healthcare in compliance with the law.

True to our past experiences with other clients, the technology failures were a result of poor management practices, a lack of coordination processes, and a failure to quickly address the root causes of early technical symptoms. And true to the principles and values of our company, we worked to help create client value (in this case some return on tax payer investment). To us, it was unfathomable to charge a fee for what was already an over-priced solution.

The Past and the Future

The early, unnamed startup (which has since gone out of business) and ACA examples are extremes in our experience. Very few of our clients display the complete lack of management or absence of processes that these examples represent. For most of our clients, simple tweaks pay incredible dividends. Most clients are staffed by hard working and focused people who suffer from the same tunnel vision we’ve personally experienced in our past jobs. Rising above the chaos of explosive growth is difficult. Having a partner can help force companies to make the time to consider their options. We approach every company as though we are extensions of that company’s team, helping to guide the team and leverage their and our combined experience to design the most appropriate solution. Most importantly, we never take on a client without believing we can help them create more value than what they’ve spent on our services. In eight years AKF has worked with hundreds of clients and grown from three individuals working part-time to twelve fulltime people, with still more to be hired in 2015. We continue to grow because we provide value to clients by identifying the true root causes of issues, not just quick technical patches.

Send to Kindle

Selecting Metrics for Your Agile Teams

One of our favorite sayings is “you can’t improve that which you do not measure.” When working with clients, we often emphasize the need to select and track performance metrics. It’s quite surprising (disheartening really) to see how many companies are limping along with decision-making based entirely on intuition. Metrics-driven institutions demonstrably outperform those that rely on “gut feel” and are able to quickly refocus efforts on projects that offer the greatest ROI.

Just as your top-level business KPIs govern strategic decision making, your agile teams (and their respective services) need their own “tactical” metrics to focus efforts, guide decision making, and make performance measurable. The purpose of agile development is to deliver high quality value to your customers in an iterative fashion. Agile facilitates rapid deployment, but also allows you to garner feedback from your customers that will shape the product. Absent a set of KPIs, you will never truly understand the effectiveness of your process. Getting it right, however, isn’t an easy task. Poorly chosen metrics won’t reflect the quality of service, will be easily gamed, or difficult to track, and may result in distorted incentives or undesirable outcomes.

In contrast, well-chosen metrics make it simple to track to performance and shape team incentives. For example, a search service could be graded against the speed and accuracy of search results while the shopping cart service is measured on the percentage of abandoned shopping carts. These metrics are simple, easy to track, difficult to game, and directly reflect the quality of service.

Be sure to dedicate the time and the mental energy needed to pick the right metrics. Feedback from team members is essential but the final selection isn’t something you can delegate. After all, If I’m allowed to pick my own performance metrics — I can assure you I’m always going to look awesome.

To keep you on the right track, below is a checklist of considerations to take into account before finalizing the selection of metrics for your agile teams:

  1. A handful of carefully chosen metrics should be preferred over a large volume of metrics. Ideally, each Agile team (and respective service) should be evaluated/tasked with improving 2-3 metrics (no more than 5). We have witnessed at least one company that proposed a total of 20 different metrics to measure an agile teams performance! Needless to say, being graded on that many metrics is disempowering at best, and likely to illicit either a panic attack or total apathy from your team. In contrast, having only a handful metrics to be graded against is empowering and helps to focus efforts.
  2. Easy to collect and or calculate. One startup suggested they would track “Engineering Hours Spent Bug-Fixing” as a way to determine code quality. The issue was quickly raised: Who would be doing this tracking? And how much time/effort did they estimate it would take?  It became obvious that tracking the exact amount of time spent would add a heavy productivity-tax to an already burdened engineering team.  While providing a very granular measure, the cost of collecting this information simply outweighed the benefits.  Ultimately we helped them decide that the “Number of Customer Service Tickets per Week” was the right metric. Sometimes a cruder measure is the right choice, especially if it is easier to collect and act upon.
  3. Directly Controllable by the Team. Choose metrics that your agile team has more or less direct control over. A metric they contribute towards indirectly is less empowering than something they know they own. For example, when measuring a search service the “Speed and Accuracy of Search” is preferable to “Overall Revenue” which the team only indirectly controls.
  4. Reflect the Quality of Service. Be sure to pick metrics that reflect the quality of that service. For instance, the number of abandoned shopping carts reflects the quality of a shopping cart service, whereas number of shopping cart views is an input metric but doesn’t necessarily reflect service quality.
  5. Difficult to Game. The innate human tendency to game any system should be held in check by selecting metrics that can’t easily be gamed. Simple velocity measures are easily (read: notoriously) gamed while the number of “Severity 1″ incidents your service invoked can’t be so easily massaged.
  6. Near Real Time Feedback. Metrics than can be collected and presented over short-time intervals are the most actionable. Information is more valuable when fresh — providing availability data weekly (or even daily) will foster better results than a year-end update.

Most importantly, well-chosen metrics tracked regularly should pervade all aspects and all levels of your business. If you want your business to become a lean, performance driven machine, you need to step on the scale every day. It can often be uncomfortable, but it’s necessary to get the returns of which you are capable.

Send to Kindle

5 Product Team Must Dos – the New (Old) Approach to Product

Want to create great products?  The path to success in this endeavor has more to do about how you think about value creation, think about your customers and organize your team than it does having brilliant ideas.  And here’s the kicker – while many of us think some of these concepts are brand new (including the founders of AKF who contributed to the primary research on the topic), the fact is that great companies have known these secrets for quite some time.  Here are 5 “Must Dos” for product teams to create great products:

1) Focus on customer value creation first!

In Peter Drucker’s “The Practice of Management” (1954) he wrote that “There is only one valid definition of a business purpose:  to create a customer.”  In later works he expanded on that notion by saying businesses must create AND keep customers and that profit was a necessity to stay in business, but not the sole purpose of a business.

Profit and shareholder value maximization are of course important to businesses.  Without profits, you can’t stay in business long.  Without creating shareholder value, you will be locked out of equity markets.  But by and large these are dependent variables outside of a firm’s control.  While we can control costs directly to effect profits, doing so may constrain our future growth.

If we instead focus on delighting the customer with the products we create, we can create internal and external enthusiasm for the product.  In doing so we grow revenues (part of profits) and excitement within the company.


2) Eliminate the “IT Mindset” and develop as a Product team

In the first edition of The Art of Scalability (2009), we cautioned teams away from the “IT Mindset”.  The IT Mindset is cost and efficiency focused versus the Product Mindset which is customer, market, product and revenue focused (in that order).  The IT Mindset envisions product development as a manufacturing plant, rather than the creative and innovative process it must be to be successful.  The IT Mindset has a purpose – to serve the needs of employee efficiencies – but should come with a “Do Not Use with Products” warning label.  This IT Mindset stifles innovation and kills product team morale.  Marty Cagan, one of the greatest product minds and consultants alive, and a longtime colleague and business partner, has more to say about this debilitating phenomenon here.


 3) Organize around the objective – not functions.

While performing academic research on why some teams in the same industry seem to have higher levels of innovation than others, we stumbled upon some interesting veins of tangential research.  All of them pointed to multi-disciplinary teams comprised of all the skills necessary to complete an objective and organizing around outcomes having higher levels of innovation and success than teams organized around functional boundaries (e.g. product management, software engineering, QA, operations, infrastructure, etc).  While we contributed to this research, we found out we weren’t the first to identify this phenomenon!  In fact, this Harvard Business Review article (1986) hints at the same philosophy.


4) Don’t listen to what customers WANT – watch them and identify what they NEED

We’ve all heard Jobs’ famous saying that customers don’t know what they want until you show them.  Developing a customer “want” is costly and can greatly miss the greater market opportunity.  As we point out in this post, product teams need to focus on the hypothesis for a market need, start small (MVP) and iterate their way to success to maximize the potential of a product to meet the true need.


5) Eliminate the concept of insular innovation

Forget the concept of a single great innovator running a company and generating great product idea after great product idea.  That concept is a myth perpetuated by marketing teams and egotistical executives.  The existing research on this topic is clear:  The teams with the highest levels of innovation source innovation from a diverse network of individuals inside and outside the company.  See slide 10 on network diversity in our scalable organizations presentation.  But don’t just take our word on it, Walter Isaacson comes to the same conclusion in his NY Times Bestseller “The Innovators”.  And yes, he debunks the notion that Jobs was the sole reason for Apple’s product success as well.

Send to Kindle

Comments Off

The Difference between “Want” and “Need”

We often hear Steve Jobs or Henry Ford quoted as reasons why companies should not listen to their customers.   People love to throw “Customers don’t know what they want until you show it to them” (Jobs) and “If I had asked people what they wanted, they would have said a faster horse” (Ford) as reasons why innovation should be a company run, insular, closed to the public process where a handful of smart employees define the future.

The problem with using these statements to defend insular, introverted innovation is two-fold.  First, such a position misunderstands both the context within which these statements were made and subsequently the point both innovators were attempting to make.  Second and most importantly, the position of supporting insular innovation simply isn’t supported and in fact is refuted by the extant research on the drivers of innovation.  The companies with the highest levels of innovation are and always have been outwardly focused and intent upon learning how customers interact with their products (see The Power of Customer Misbehavior and our research on innovation and scalable organizations).

Let’s tackle the misunderstanding of these statements first.  Both Jobs and Ford are identifying the difference between what customers want and what a given market needs.  Their point is that what a customer says they want is seldom what a market (a large group of customers) truly need – or at the very least that what customers want won’t be as good as identifying and meeting their true need. Specifying and fully developing a want is misguided by an untested hypotheses associating the to-be product with a desired outcome.  Because the specification isn’t guided and course-corrected by iterative testing against a market environment, the longer the program of development runs (and the larger the product), the more likely it is that the product will miss the maximum opportunity.  Waterfall development, while appropriate in some areas (such as negotiated contracts without room for testing against a real need), is all about developing a want codified within a product specification.

The alternative approach is to start with a necessary outcome (e.g. first digital encapsulated music player without removable mass storage media, or better transportation) and a hypothesis as to how to get there (hard drive for mass storage and software for transferal, 8 HP 2 speed engine and transmission with 2 or 4 seats).  In these cases, neither product took a long time to build (especially for “hardware”).  Instead, the companies looked to bring a product to market quickly and learn from it.  To show how quickly the teams were iterating and fixing the mistakes in their initial products, Apple released a new generation of their iPod or a new model every year for at least six straight years and corrected such initial deficiencies as not supporting Windows for the iTunes OS and not having a solution for digital music downloads (the iTunes store).  Ford produced 4 new car models (the Model AC, Model C, Model B and Model F) within the 4 years after initial Model A launch in 1903.  These vehicles addressed the engine being underpowered, overheating, weight limitations, etc.

The point here is that great product teams understand that the greatest value is derived from achieving the outcomes associated with a need, not the specifications of a want.  Needs are met by defining a measurable outcome, building a testable hypotheses (minimum viable product or MVP) as to what will partially fulfill that outcome and then iteratively and rapidly correcting the hypotheses (MVP) to achieve the desired results.

Send to Kindle

Comments Off

CTO Bootcamp: March 10th & 11th in Brooklyn



We are excited to announce AKF Partners very first CTO Bootcamp. This unique two day event is designed for current CTOs, VPs of Engineering, Chief Architects, and other technology executives that want to improve their management, leadership, and technology skills. Marty Abbott, Mike Fisher, and Mike Paylor from AKF Partners will share their combined decades of experience as CTOs and technology executives at both large organizations and start-ups.

The two-day bootcamp will cover the following topics:

The CTO Role: A discussion on the diversity of expectations and responsibilities from the 400 companies we have worked with at AKF Partners.

The Right People & Roles: Ensuring the right talent is placed in positions for success.

Management & Leadership: The skills of a transformational leader and highly effective manager.

Conflict & Innovation: A discussion of good and bad conflicts in organizations and how to increase innovation.

Multidisciplinary Agile Teams: Building innovative teams with diverse experience and skills.

Team Goals & KPIs: Setting goals, metrics, and KPIs for Agile teams to ensure success.

The Experiential Chasm: The widening gap between business leaders and technology leaders and how to close it.

Service Delivery Mindset: The most successful technology organizations are structured with a service oriented mindset and we will discuss how to transform your organization and mindset.

AKF Risk Model: Our viewpoint of risk and how to manage it successfully in your architecture, people, and processes.

Highly Scalable Architectures: An in-depth look at creating highly scalable and available architectures

  • AKF Scale Cube: Our approach to designing highly scalable architectures.
  • Creating Fault Isolation: The importance of isolation for availability and time to market.
  • Architecture Principles: An in-depth look at the top architecture principles and how to apply them.

Processes for a Learning Organization: The most effective processes to put in place to create a successful learning organization.


Our first bootcamp will be held on March 10th & 11th in New York. If you are interested in attending or sending a member of your organization please register.

Send to Kindle

Comments Off

Building Scalable Organizations

Embedded below is a presentation on building scalable organizations. The presentation walks through our model of innovation detailing how factors such as cognitive conflict, affective conflict, and a sense of empowerment impact a company’s ability to be innovative. The slides then depict how in most functional based organizations there is conflict when trying to deliver a service such as a SaaS product offering. The remainder of the presentation focuses on how to fix this with some real world examples of companies that have reorganized to focus on improving innovation.

Send to Kindle

Comments Off

How and Why the ALS Ice Bucket Challenge Works

Fish recently wrote about the ALS Ice Bucket Challenge, explaining the mathematical constructs behind viral growth.  If you read the article, you may have pondered how something like the Ice Bucket Challenge goes viral.  Ponder no more!  This article briefly explains our research into the drivers of viral growth.  For a deeper explanation, pick up a copy of our recently published book The Power of Customer Misbehavior.

First and foremost, for anything to go “viral”, it must be both be easy to use and useful to the user.  The ease with which one can use a cell phone to take and post video nearly anywhere fulfills the ease of use requirement.   Usefulness is also clearly fulfilled as a requirement as most people participating in the challenge see the value in contributing to a cause as worthy as ALS (commonly referred to as Lou Gehrig’s Disease).

These two requirements (ease of use and usefulness), while necessary, aren’t sufficient to trigger viral growth.  Think of all the things in your life that are both useful and easy to use but that have not gone “viral” or “exploded” in their adoption within some confined time period.  These may range from anything from the type of soap that you use to a brand of underwear that you wear.   Another example may be a particular type of tool that you like to use around the house.  Maybe it is a type of light bulb of which you are particularly fond, a skin care product that you use or a brand of toothbrush you commonly purchase.  Why don’t these things, which are incredibly useful and easy to use explode in their usage overnight?  There are lots of common answers, including commoditization of these particular products, price, etc.  But these answers alone don’t have statistically strong explanatory powers.

One reason we uncovered from our research is that these products don’t allow people to interact with them and co-create or co-produce value.  Co-creation is the commonly defined as an act of creating value through content contribution and co-production is the act of using a product in new and unforeseen ways.  The Ice Bucket challenge does both of these.  Individuals co-create by producing new content videos of them getting soaked (see Bill Gates or George W as examples).  As importantly, users can modify and extend the format (co-production) by changing the challenge in new and innovative ways.  Charlie Sheen is a perfect example of a move of co-production (note the tag line – “big twist” in the article).

Knowing that usefulness, ease of use, the ability to co-create and co-produce are key to viral growth is indeed useful.  But these examples may leave you wondering why one would co-create or co-produce in the first place?  We use the example of Harley Davidson in the Power of Customer Misbehavior to explain exactly this question.  Why do people purchase and then modify (co-produce and co-create) Harleys?  These beautiful rides certainly aren’t cheap!

The answer to this question is that people modify Harleys (think of the origination of the “chopper”) because of what it says about them.  “I’m a free spirit” or “I’m a rebel” or “I’m a badass biker dude who also happens to be an accountant”.  The act of creating something with their “hogs” says something unique about them while simultaneously helping them to identify with another group of people.  The same is true for why we might wear NFL football jerseys or collegiate “hoodies”.  These things are all part of our identity.  Participating in the Ice Bucket Challenge identifies us with our friends, family and others who are of a similar philanthropic mind.  We get to show to others that we care and in so doing affiliate ourselves with others who care.

The model below, from The Power of Customer Misbehavior, shows these relationships.  Briefly, the ALS Challenge works because it is useful (gives to a good cause), is easy to use (take a video and post), allows us to co-create and co-produce (add valuable content and modify/extend the content) and says something about us to others (identity).

POCM Model












If you enjoyed this article, please pick up a copy of the Power of Customer Misbehavior.  And please give to ALS.  It is a cause near and dear to our firm’s heart as historically military veterans represent a statistically disproportionately large share of people afflicted with this terrible disease.

Send to Kindle

Comments Off

Explaining the ALS Ice-Bucket Challenge

By now you’ve undoubtedly seen all of the ALS ice-bucket challenge videos that have been popping up on our social media feeds. I like most people enjoy watching my friends dump buckets of ice on their heads but what I like about this fund-raising campaign even more is that it is a brilliant example of viral growth. If we take a quick look at the power of viral growth we can easily see why the ALS Association reported that it raised $15.6 million as a result of the challenge, nine times what it normally raises in the same time frame. Project ALS and ALS TDI, two other ALS charities, reported donations up between 10 and 50 times normal just since the beginning of August.

For viral growth we start with a simple formula for our viral coefficient (Cv), which is essentially how effective our campaign is at spreading from one person to another. In the equation we have Fan Out, how many people one person asks to join, and Conversion Rate, how many people actually join. Most people making ALS ice-bucket challenge videos call out or invite 3 other people to join. I suspect not everyone converts, which as I understand the rules is even better for the charity because you are supposed to donate $10 if you do the challenge and $100 if you don’t. However, it appears that the Conversion Rate is very high; my guess is as high as 75%. This would yield a viral coefficient of 3 x 0.75 = 2.25. For every one person that produces a video and donates they attract 2.25 people on average to also produce a video, donate, and nominate 3 other people.

    Cv=Fan Out*Conversion Rate

In order to see the cumulative effect of this spread we turn to one more formula, Cumulative Donors. This is simple the Viral Coefficient multiplied by the Retention Rate, which matters a lot if you are a social media site that needs users coming back day after day but for donations just participating in the challenge is sufficient so we can use 100% for that variable. One of the cleverest ideas of the ice-bucket challenge is calling people out and giving them only 24-hours to accept the challenge. This forces the cycle of fan out to be very high. In our equation the frequency of usage is 1 since people only make one video and then the cycle is 1 day (24 hours).

    Cumulative Donors=(Cv*Retention Rate)^(Frequency*Cycle)

If we start with one person on day 1, it requires just a few hours past the 20th day for the number of cumulative donors to exceed the world’s population of approximately 7 billion people (see the graph below). Pretty nice for a fund-raising campaign! Of course, all the interesting growth occurs that last few days. You might even notice that this week your social media feed will be inundated with new videos.


What the graph above does not show is that adoption of anything (technologies to fund raisers) is that the curve is really an ‘S’ curve in that once the adoption hits a maximum it flattens out. There is only a certain number of users, customers, or donors that will ever user your product or donate to your cause. But it’s certainly a fun ride getting there.

If you find this interesting you’d probably enjoy our latest book, The Power of Customer Misbehavior.

Send to Kindle

1 comment

5-95 Rule

Previously, I wrote about mitigating risk in the face of uncertainty. I suggested that an agile development model was one way successful companies have been able to mitigate risk. In that post I compared the similarities between organizing into “Scrums” to how Army Special Forces organized in order to succeed in uncertain operating conditions. In addition to the way a company is organized, the way a company approaches project planning can mitigate risk. One of the most often overlooked aspects of project management is contingency planning.

Army Green Berets are fond of the saying, “No plan survives contact with the enemy,” a quote attributed to the famous Prussian General Helmut Von Moltke. Von Moltke and his Prussian contemporaries were brilliant strategists and sought to perfect the “Theory of War.” Their ideas still serve as basis for our doctrine today. Moltke understood that battles can be broken down to a near infinite set of complex options, each of them in turn having still more options depending upon the enemy’s response. A plan only goes so far, at which point the enemy ultimately casts his vote. Von Moltke provided his subordinate commanders with his intentions (a method still taught today in military basic leadership courses), and held them responsible for extensively preparing for all plausible contingencies.

As a Special Forces Detachment Commander, once my team received our orders, we immediately began to plan. Along with the mission, we were given a specific deadline by which we needed to brief our commander. Regardless of the deadline, whether it was 6 hours or a week, we spent approximately 5% of the time coming up with a solid, practical, and safe plan. We spent the other 95% of the time “war-gaming” the plan. During the “war-gaming” portion, we would go through every step of the plan from the time we left our barracks to the time we got back. We thought of every possible thing that could go wrong. What if only two helicopters showed up and not four? What if the helicopter couldn’t land where we wanted it? What if someone got injured? What if more bad guys were on the objective than we had originally thought? We would break our mission down into distinct pieces, or milestones, and would work in teams to come up with solutions to every possible contingency. We would collaborate with our partners, the pilots for example, and let the subject matter experts take the lead in their scope of responsibility. Time permitting, we built mock-ups of the buildings we anticipated operating in, and conducted detailed rehearsals. The rehearsals revealed other contingencies we hadn’t planned for, such as equipment that was being carried by the wrong guy or individuals who needed to work together that weren’t located near each other. We did this because we knew the battlefield was going to be fluid and dynamic. Being prepared not only enabled us to be successful, it saved lives.

While the tech industry doesn’t deal in life or death, although it certainly might feel like that at times, Von Moltke’s wisdom still applies, especially in complex project development. What if equipment doesn’t arrive on time during a data center build? A critical engineer or developer gets sick during a launch or gets hired away? AKF Partners is a company heavily influenced by veterans and our collective experience on and off the battlefield. We encourage our clients to practice the AKF “5-95 Rule” in their Agile methodology. Having a solid plan is a great start but understanding the possible variations in the project’s execution will help ensure the projected is delivered on time and within the budget. Remember the AKF “5-95 Rule” and spend 5 percent of your time planning and 95 percent of your time developing contingencies.

Send to Kindle

Keep Asking Why

We’ve written about After Action Reviews and Postmortems before but I thought it would be worth providing an updated example of the importance of getting to true root causes. Yes, that’s plural “causes” because there are almost always multiple root causes, not just one.

I recently watched a postmortem that followed AKF’s recommended T-I-A process of creating a timeline, identifying the issues, and assigning action items to owners. However, the list of issues included such things as “deployment script failed to stop when a node was down.” While this is certainly a contributing issue to the incident, it is not a root cause. It’s not a root cause in that if you fix the script but not the process that allowed the script to fail in the first place, you’re only solving for a very narrow problem. If you dig deeper (keep asking “why”), you’ll soon realize that there are truer root causes perhaps there is no process for code reviewing scripts or there is no process for testing scripts or there is no build vs. buy decision for scripting tools whereby you’re having to home-grow all the tools. These root causes, once solved, will fix a much broader set of problems that you will encounter instead of just fixing a broken script.

In order to be a true learning organization you need to dig deep. Get to true root cause by keep asking “why.” You know you’ve achieved the correct depth when solving the issue will fix many failure modes and not just the one that caused the incident.

Send to Kindle

Comments Off