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.
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).
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.
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.
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.
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.
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, email@example.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 companywide 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 longterm 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 datadriven intelligence. By combining consumer behavior with realtime 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 mobilecentric experience — is key to becoming the dominant technology in the future of real estate.
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.
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.
- Why Caching is Key to Optimizing Software Performance
- Why Software Companies Need to Adopt a Services Mindset
- One Big Warning Sign Your Organization Isn’t Structured to Scale
- Build or Buy? How to Decide if You Should Outsource Development
- Own the Goal! Tips for Empowering Teams to Innovate
- Companies should encourage customers to misbehave with their products and services
- How We’d Fix HealthCare.gov: Scalability Experts Speak
Make sure you follow Marty and Mike and AKF’s Facebook Pages to keep up to date with the latest.