AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

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

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

Talent Search: Tech Lead, Princeton Review

The Princeton Review technology team is looking for a highly skilled lead engineer to help start up an Agile development team in Natick, Massachusetts. This person will be responsible for leading a multi-function team with direct reports to design the next generation of the web-site and online products. This is a great opportunity to work in an environment where you will have the opportunity to help shape and grow the engineering team. The candidate should have 2 to 5 years experience in a lead development role and experience with Web/Java Framework technologies, such as Spring, Struts, Hibernate, Tomcat, CXF, JSP, Tiles, HTML, Javascript, and Javascipt MVC frameworks is desired.

Interested candidates are requested to send their resume directly to: Tom Gernon. Click here for more details on the position.

Send to Kindle

Comments Off

Talent Search: VP of Engineering, BoomTown

BoomTown, www.boomtownroi.com, is looking for a VP of Engineering to join their talented team in Charleston, S.C. We have had the pleasure of working with BoomTown on several occasions and think this is a great opportunity. Please email Mike Paylor, mike.paylor@akfpartners.com if interested.

The Vice President of Engineering will join the BoomTown team and report to Founder & CEO, Grier Allen. S/he will lead the engineering and technology practice company­wide and will have all duties and authorities commensurate with the position.

BoomTown’s current engineering team is a group of roughly 30 engineers is operating without a centralized engineering leader. There is also the opportunity to lead a smaller team of designers and UI/UX personnel depending on the leader’s experience/interests.

BoomTown has spent the last five years building and solidifying its position as an innovator in real estate technology. At the same time, the company has established itself as a trusted partner to real estate professionals in a time when disruption of the real estate business model is a consistent theme. With the massive shift to online home search, brokers and agents must find new ways to effectively engage those consumers, establish long­term relationships, and reestablish their value, which is under continuous attack.

As the real estate market has rebounded, brokers and agents are scrambling to invest in technology that will diminish the threat of disruption. BoomTown is in a unique position to capture the mindshare of both agents and brokers at both the SMB and Enterprise/Franchise level. BoomTown believes that the ability to truly impact agent sales productivity is by connecting the right agent with the right consumer, at the right time, and with the right information is the key to why agents and brokers will adopt the next generation of real estate technology.

Central to BoomTown’s strategy is the focus on predictive data­driven intelligence. By combining consumer behavior with real­time listing activity and agent performance, BoomTown can focus agents on the most productive activity at any given moment. This enables agents to rapidly and effectively engage consumers throughout the lifecycle. BoomTown’s strategy — to marry predictive analytics with a mobile­centric experience — is key to becoming the dominant technology in the future of real estate.

Send to Kindle

Comments Off


Just over a month ago, the WebscaleSQL collaboration project was launched.  This project aims to create a community-developed branch of the popular MySQL DBMS that incorporates features to make large-scale deployments easier.  As many of our clients run large clusters of MySQL on commodity hardware (as a means to reduce costs and improve scalability) the WebScaleSQL project naturally drew our attention.

The project is currently developed by a small collaboration of engineers from Facebook, Google, Twitter, and LinkedIn.  Certainly no strangers to scalability challenges, the developers from these web giants all face similar challenges and must work continuously to improve performance and scalability of their MySQL deployments to remain competitive.  Aimed at minimizing the duplication of effort across these engineering teams, WebScaleSQL’s development is run as an open collaboration between these major contributors.  Contributions aren’t limited to major companies, however, and participation from outside engineers is encouraged.

Despite having only been around a few weeks, the WebScaleSQL project boasts some significant improvements overs its upstream parent (Oracle’s MySQL ver 5.6).  These advances include an automated testing framework, a stress testing suite, query optimizations and host of other changes that promise to improve the performance, testing, and deployment of large-scale DBs.

As WebScaleSQL matures, we’ll continue to track its development and report on our clients’  experiences (both good and bad) working with this new “scale friendly” branch of MySQL.

WebScaleSQL source is currently hosted on GitHub (https://github.com/webscalesql/webscalesql-5.6) and released under version 2 of the GNU public license.

Send to Kindle

Comments Off


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.

Send to Kindle

Comments Off

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


Send to Kindle

Comments Off

Seizing the Initiative

As a young Army Lieutenant leading a Platoon in Iraq in 2006, I was faced with a crisis. Our platoon was continually getting ambushed during our patrols in sector. The uncertainty of waiting to be attacked, the physical, mental and emotional strain on the men, not to mention the damage to our vehicles and equipment, started to take its toll. The ensuing battles would generally last for hours. We would stay out in sector for upwards of 16 hours. This would only leave 8 hours to come back to the forward operating base, refit and conduct maintenance on our vehicles. This type of operation couldn’t be sustained. Our morale was starting to fall, tensions were starting to rise between my platoon and the maintenance crews servicing our vehicles. We’d bring in leaking, limping, bullet ridden trucks and expect to jump back in them and roll out in a matter of hours. In military terms, we had “lost the initiative.” That is to say, the enemy was dictating where and when and how the battle would go. We were only reacting. We were compelled to react to the enemy’s strengths and capabilities. We were treading water trying to stay afloat. In this crisis, my men depended on me to come up with a plan to take back control, or “seize the initiative.” The importance of having a plan is emphasized in Sun Tzu’s famous quote, “ Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.” My platoon and I were at war, and trying to win.


The crisis I experienced in Iraq is similar to the challenges many executives face with regard to scaling. Granted, no one is shooting at them, but the enemy can represent any or all of the variables and uncertainty in the industry; the customer, the competition, the software, the hardware, the market, etc. Some executives find they are compelled to react to daily incidents, i.e. “lets just make it another 24 hrs without an outage,” and it’s a struggle to maintain, let alone scale effectively. Just like with my platoon, this type of operation takes a toll on an organization. Aside from being bad for business, it sows the seeds of despair, brings down morale, and possibly creates tension between the engineers and the business folks similar to that between my troops and our maintenance crews. The leader needs to take a step back, understand what is going on and figure out a plan to get his or her team out of it.

For me, the solution was counter-intuitive at first. I knew we needed to take time to regroup, but I hesitated to not keep pressing the enemy. I feared that we’d lose what little ground we had. Then, I remembered something my instructor told me while learning to navigate in the woods with a map and a compass. He warned us, “If you don’t know where you are going, don’t walk as fast. You’ll only get lost in a hurry.” In our eagerness to get out into sector and fight the enemy we were getting lost in a hurry. We had gone to war, and were now trying to win. It is a difficult decision to halt operations, or take a product offline. Aggressive leaders are often very successful because they persevere in the face of adversity. However, there is a fine line between perseverance and stubbornness. I made the call to postpone operations. I needed time to develop an effective sustainable strategy.

“Seizing the initiative” requires leaders to make sound decisions under uncertain conditions and to anticipate events so their organization can recognize and leverage opportunities. The key to anticipating events is to understand the problem. In my case, we really did not understand the enemy. From an institutional standpoint, we had been training to fight the soviets for the last 40 years, and here we were faced against an adaptive and evolving enemy. We scaled our operations back at first, focused on reconnaissance and understanding the enemy. In doing so we were better able to anticipate events, and began setting the conditions of the fight. We were engaging the enemy when and where we wanted. We had seized the initiative. Regardless of your type of organization, if you are struggling just to maintain, if you have lost the initiative, the best solution is to take the necessary pause in operations, understand the problem, and develop a strategy for a sustainable effective approach.

Send to Kindle

Comments Off

The Phoenix Project – Book Review

After several friends recommended that I read the book The Phoenix Project, I at last downloaded it to my kindle and read it on one of my transcontinental flights. I really enjoyed it and thought it was both entertaining and enlightening which is difficult to accomplish. However, I don’t believe it goes far enough in describing how the most modern and efficient technology shops run. More about that later, first a recap.

The story line is that the fictional company, Parts Unlimited, is failing to keep up with competition and at risk of being split up and sold off. The root cause of the company’s issues are IT. We join the story after two IT executives are fired and the hero of our story, Bill, is asked to take over as the VP of IT Operations. He is introduced to his sensei, Erik, a tech / business / process genius, who leads Bill through the path to enlightenment by comparing IT Operations to a manufacturing plant. Through this journey the reader is introduced to concepts such as kanban, work-in-process (WIP), work centers, Theory of Constraints, Lean Startup, and the overarching concept of DevOps. In fact the book ends with most of the main characters at a party where Bill reflects “Maybe everyone attending this party is a form of DevOps, but I suspect it’s something much more than that. It’s Product Management, Development, IT Operations, and even Information Security all working together and supporting one another.”

I’m a fan of DevOps but to me the integration of tech ops and development is one small step for technology driven companies. In order to truly be nimble and effective, teams need to incorporate development, tech ops, product management, quality assurance, and any other function such as marketing or analytics that are needed to make the team autonomous. We’ve written about this concept several times The Agile Org, The Agile Org Solution, and The Agile Exec. We call these teams PODs and most importantly they need to be aligned to swim lanes in the architecture. By doing this, you essentially create mini-startups. These teams can make decisions themselves, deploy independently, and are responsible for their service from idea to production support.

I really enjoyed the book The Phoenix Project and I too highly recommend that you read it, especially if you are not familiar with the concepts mentioned above. As the authors are obviously talented writers and technologist, I would love to see them write another book that takes Parts Unlimited to the next level by creating autonomous teams. The authors hint at this concept when they state

“You’ve helped me see that IT is not merely a department. Instead, it’s pervasive, like electricity. It’s a skill, like being able to read or do math. Here at Parts Unlimited, we don’t have a centralized reading or math department—we expect everyone we hire to have some mastery of it. Understanding what technology can and can’t do has become a core competency that every part of this business must have. If any of my business managers are leading a team or a project without that skill, they will fail.”

Hopefully this is foreshadowing of another book to come.

Send to Kindle

Comments Off