Results and Outcomes – Why Companies Fail
April 21, 2019 | Posted By: Pete Ferguson
Results = Results
Apple, Google, and Amazon don’t exist based on a Utopian promise of what is to come – though certainly those promises keep their customers engaged and hopeful for the future. These companies exist because of the value they have delivered to date and created expectations for us as consumers for a consistent result.
I’m amazed at how simple of a concept Results = Results is – yet constantly we see companies struggle with the concept and we see it as a recurring theme in our 2-3 day workshops with our clients and something we look for in our technical due diligence reviews.
As a corporate survivor of 18 years, looking back I can see where I was distracted by day-today meetings, firefighting, and getting hijacked by initiatives that seemed urgent to some senior leader somewhere – but were not really all that important.
Suddenly the quarter or half was over and it was time to do a self-evaluation and realize all the effort, all the stress, all the work, wasn’t getting the desired results I’d committed to earlier in the year and I’d have to quickly shuffle and focus on getting stuff done.
While keeping the lights on is important, it diminishes in importance when to do so is at the expense of innovating and adding value to our customers – not just struggling to maintain the status quo.
Outcomes and Key Results (OKRs)
Adapted from John Doerr’s “Objectives” and key results – at AKF we find it more to the point to focus on “outcomes.” Objectives (definition: a thing aimed at or sought) are a path where as “outcomes” are a destination that is clearly defined to know you have arrived.
Outcomes are the only things that matter to our customers. Hearing about a desired Utopian state is great and may excite customers to stick around for awhile and put up with current limitations or lack of functionality – but being able to clearly define that you have delivered an outcome and the value to your customers is money in the bank and puts us ahead of our competition.
Yet the majority of our clients have teams who are so focused on cost-cutting for many years that they leave a wide open berth for young startups and their competition to move in and start delivering better outcomes for the customer.
How to Focus on Results and Outcomes
It is easy to become distracted in the day-to-day meetings, incident escalations, post mortems, ect. As an outside third party, however, it is blatantly obvious to us usually within the first hour of meeting with a new team whether or not they are properly focused.
Here are some of the common themes and questions to ask:
- Is there effective monitoring to discover issues before our customers do?
- Do we monitor business metrics and weigh the success (and failure) of initiatives based not on pushing out a new platform or product but whether or not there was significant ROI?
- How much time is spent limping along to keep a legacy application up and running vs. innovating?
- Do we continually push off hardware/software upgrades until we are held hostage by compliance and/or end-of-life serviceability by the vendor?
Hopefully the common theme here is obvious – what is the customer experience and how focused are we on them vs internal castle building or day-to-day distractions?
Recently in a team interview the IT “keep the lights on” team told us they were working to be strategic and innovative by hiring new interns. While the younger generations are definitely less prone to accepting the status quo, the older generation are conceding that they don’t want to be part of the future. And unfortunately they may not be sooner than planned if they don’t grasp their role in driving innovation and the importance of applying their institutional knowledge.
Not focusing on customer/shareholder related outcomes means that shareholders and customers are negatively impacted. Here are a few problems with the associated outcomes I’ve seen in my short tenure with AKF and previously as a corporate crusader:
Monolithic applications to save costs: Why organizations do it? Short term cost savings focus development on one application. Allows teams to only focus on development of their one area.
- One failure means everyone fails.
- Organizations are unable to scale vis-a-vis Conway’s Law (organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations).
- Often the teams who develop the monolith don’t have to support it, so they don’t understand why it is a problem.
- Teams become very focused on solving the problems caused by the monolith just long enough to get it back up and running but fail to see the long-term recurrent loss to the business and wasted hours that could have been spent on innovating new products and services.
- Catastrophic failure - Intuit pre SaaS, early renditions of iTunes and annual outages when everyone tried to redeem gift cards Christmas morning, early days of eBay, stay tuned, many more yet to come.
Ongoing cost cutting to “make the quarter.”
- MIssed tech refresh results in machines and operating systems no longer supported and vulnerable to external attacks.
- Teams become hyper focused on shutting down additional spending, but never take the time to calculate how much wasted effort is spent on keeping the lights on for aging systems with a declining market share or slowed new customer adoption rate.
- Start saying no to the customer based on cost opening the door for new upstarts and the competition to take away market share.
Focusing efforts on Sales Department’s latest contract.
- Too much investment in legacy applications instead of innovating new products.
- “A-team” developers become firefighters to keep customers happy.
- Sales team creates moral hazards for development teams (i.e. “I smoke, but you get lung cancer” - teams create problems for other teams to fix instead of owning the end-to-end lifecycle of a product)
Focus is on mergers and acquisitions instead of core strengths and products.
- Distracted organizations give way for upstarts and competition.
- Become okay or maybe even good at a lot of things but not great at one or two things.
- Company culture becomes very fragmented and silos create red tape that slows or stifles innovation.
Results = Results. And nothing else equals results.
If OKRs are not measuring the results needed to compete and win, then teams are wasting a lot of effort, time, and money and the competition is getting a free pass to innovate and outperform your ability to delight and please your customers.
Need an outside view of your organization to help drive better results and outcomes? Contact us!
Photo by rawpixel.com from Pexels
Subscribe to the AKF Newsletter
The AKF Difference
December 4, 2018 | Posted By: Marty Abbott
During the last 12 years, many prospective clients have asked us some variation of the following questions: “What makes you different?”, “Why should we consider hiring you?”, or “How are you differentiated as a firm?”.
The answer has many components. Sometimes our answers are clear indications that we are NOT the right firm for you. Here are the reasons you should, or should not, hire AKF Partners:
Operators and Executives – Not Consultants
Most technology consulting firms are largely comprised of employees who have only been consultants or have only run consulting companies. We’ve been in your shoes as engineers, managers and executives. We make decisions and provide advice based on practical experience with living with the decisions we’ve made in the past.
Engineers – Not Technicians
Educational institutions haven’t graduated enough engineers to keep up with demand within the United States for at least forty years. To make up for the delta between supply and demand, technical training services have sprung up throughout the US to teach people technical skills in a handful of weeks or months. These technicians understand how to put building blocks together, but they are not especially skilled in how to architect highly available, low latency, low cost to develop and operate solutions.
The largest technology consulting companies are built around programs that hire employees with non-technical college degrees. These companies then teach these employees internally using “boot camps” – creating their own technicians.
Our company is comprised almost entirely of “engineers”; employees with highly technical backgrounds who understand both how and why the “building blocks” work as well as how to put those blocks together.
Product – Not “IT”
Most technology consulting firms are comprised of consultants who have a deep understanding of employee-facing “Information Technology” solutions. These companies are great at helping you implement packaged software solutions or SaaS solutions such as Enterprise Resource Management systems, Customer Relationship Management Systems and the like. Put bluntly, these companies help you with solutions that you see as a cost center in your business. While we’ve helped some partners who refuse to use anyone else with these systems, it’s not our focus and not where we consider ourselves to be differentiated.
Very few firms have experience building complex product (revenue generating) services and platforms online. Products (not IT) represent nearly all of AKF’s work and most of AKF’s collective experience as engineers, managers and executives within companies. If you want back-office IT consulting help focused on employee productivity there are likely better firms with which you can work. If you are building a product, you do not want to hire the firms that specialize in back office IT work.
Business First – Not Technology First
Products only exist to further the needs of customers and through that relationship, further the needs of the business. We take a business-first approach in all our engagements, seeking to answer the questions of: Can we help a way to build it faster, better, or cheaper? Can we find ways to make it respond to customers faster, be more highly available or be more scalable? We are technology agnostic and believe that of the several “right” solutions for a company, a small handful will emerge displaying comparatively low cost, fast time to market, appropriate availability, scalability, appropriate quality, and low cost of operations.
Cure the Disease – Don’t Just Treat the Symptoms
Most consulting firms will gladly help you with your technology needs but stop short of solving the underlying causes creating your needs: the skill, focus, processes, or organizational construction of your product team. The reason for this is obvious, most consulting companies are betting that if the causes aren’t fixed, you will need them back again in the future.
At AKF Partners, we approach things differently. We believe that we have failed if we haven’t helped you solve the reasons why you called us in the first place. To that end, we try to find the source of any problem you may have. Whether that be missing skillsets, the need for additional leadership, organization related work impediments, or processes that stand in the way of your success – we will bring these causes to your attention in a clear and concise manner. Moreover, we will help you understand how to fix them. If necessary, we will stay until they are fixed.
We recognize that in taking the above approach, you may not need us back. Our hope is that you will instead refer us to other clients in the future.
Are We “Right” for You?
That’s a question for you, not for us, to answer. We don’t employ sales people who help “close deals” or “shape demand”. We won’t pressure you into making a decision or hound you with multiple calls. We want to work with clients who “want” us to partner with them – partners with whom we can join forces to create an even better product solution.
Subscribe to the AKF Newsletter
Diagnosing and Fixing Software Development Performance
November 20, 2018 | Posted By: Roger Andelin
Diagnosing the cause of poor performance from your engineering team is difficult and can be costly for the organization if done incorrectly. Most everyone will agree that a high performing team is more desirable than a low performing team. However, there is rarely agreement as to why teams are not performing well and how to help them improve performance. For example, your CFO may believe the team does not have good project management and that more project management will improve the team’s performance. Alternatively, the CEO may believe engineers are not working hard enough because they arrive to the office late. The CMO may believe the team is simply bad and everyone needs to be replaced.
Often times, your CTO may not even know the root causes of poor performance or even recognize there is a performance problem until peers begin to complain. However, there are steps an organization can take to uncover the root cause of poor performance quickly, present those findings to stakeholders for greater understanding, and take steps that will properly remove the impediments to higher performance. Those steps may include some of the solutions suggested by others, but without a complete understanding of the problem, performance will not improve and incorrect remedies will often make the situation worse. In other words, adding more project management does not always solve a problem with on time delivery, but it will add more cost and overhead. Requiring engineers to start each day at 8 AM sharp may give the appearance that work is getting done, but it may not directly improve velocity. Firing good engineers who face legitimate challenges to their performance may do irreversible harm to the organization. For instance, it may appear arbitrary to others and create more fear in the department resulting in unwanted attrition. Taking improper action will make things worse rather than improve the situation.
How can you know what action to take to fix an engineering performance problem? The first step in that process is to correctly define and agree upon what good performance looks like. Good performance is comprised of two factors: velocity and value.
Velocity is defined as the speed at which the team works and value is defined as achievement of business goals. Velocity is measured in story points which represent the amount of work completed. Value is measured in business terms such as revenue, customer satisfaction or conversion. High performing engineering teams work quickly and their work has a measurable impact on business goals. High performing teams put as much focus on delivering a timely release as they do on delivering the right release to achieve a business goal.
Once you have agreement on the definition of good engineering performance, rate each of your engineering teams against the two criteria: velocity and value. You may use a chart like the one below:
Once each team has been rated, write down a narrative that justifies the rating. Here are a few examples:
Bottom Left: Velocity and Value are Low
“My requests always seem to take a long time. Even the most simple of requests takes forever. And, when the team finally gets around to completing the request, often times there are problems in production once the release is completed. These problems have negatively impacted customers’ confidence in us so not only are engineers not delivering value – they are eroding it!”
Upper/Middle Left: Velocity is Good and Value is Low
“The team does get stuff done. Of course I’d like them to go faster, but generally speaking they are able to get things done in a reasonable amount of time. However, I can’t say if they are delivering value – when we release something we are not tracking any business metrics so I have no way of knowing!”
Upper Right: Velocity is High and Value is High
“The team is really good. They are tracking their velocity in story points and have goals to improve velocity. They are already up 10% over last year. Also, they instrument all their releases to measure business value. They are actively working with product management to understand what value needs to be delivered and hypothesize with the stakeholders as to what features will be best to deliver the intended business goal. This team is a pleasure to work with.”
Unknown Velocity and Unknown Value
“I don’t know how to rate this team. I don’t know their velocity; its always changing and seems meaningless. I think the team does deliver business value, but they are not measuring it so I cannot say if it is low or high.”
With narratives in hand it’s time to begin digging for more data to support or invalidate the ratings.
Diagnosing Velocity Problems
Engineering velocity is a function of time spent developing. Therefore, the first question to answer is “what is the maximum amount of time my team is able to spend on engineering work under ideal conditions?”
This is a calculated value. For example, start with a 40 hour work week. Next, assuming your teams are following an Agile software development process, for each engineering role subtract out the time needed each week for meetings and other non-development work. For individual contributors working in an Agile process that number is about 5 hours per week (for stand up, review, planning and retro). For managers the number may be larger. For each role on the team sum up the hours. This is your ideal maximum.
Next, with the ideal maximum in hand, compare that to the actual achievement. If your teams are not logging hours against their engineering tasks, they will need to do this in order to complete this exercise. Evaluate the gap between the ideal maximum and the actual. For example, if the ideal number is 280 hours and the team is logging 200 hours, then the gap is 80 hours. You need to determine where that 80 hours is going and why. Here are some potential problems to consider:
- Teams are spending extra time in planning meetings to refine requirements and evaluating effort.
- Team members are being interrupted by customer incidents which they are required to support.
- The team must support the weekly release process in addition to their other engineering tasks.
- Miscellaneous meeting are being called by stakeholders including project status meetings and updates.
As you dig into this gap it will become clear what needs to be fixed. The results will probably surprise you. For example, one client was faced with a software quality problem. Determined to improve their software quality, the client added more quality engineers, built more unit tests, and built more automated system tests. While there is nothing inherently wrong with this, it did not address the root cause of their poor quality: Rushing. Engineers were spending about 3-4 hours per day on their engineering tasks. Context switching, interruptions and unnecessary meetings eroded quality engineering time each day. As a result, engineers rushing to complete their work tasks made novice mistakes. Improving engineering performance required a plan for reducing engineering interruptions, unnecessary meetings, and enabling engineers to spend more uninterrupted time on their development tasks.
At another client, the frequency of production support incidents were impacting team velocity. Engineers were being pulled away from their daily engineering tasks to work on problems in production. This had gone on so long that while nobody liked it, they accepted it as normal. It’s not normal! Digging into the issue, the root cause was uncovered: The process for managing production incidents was ineffective. Every incident was urgent and nearly every incident disrupted the engineering team. To improve this, a triage process was introduced whereby each incident was classified and either assigned an urgent status (which would create an interruption for the team) or something lower which was then placed on the product backlog (no interruption for the team). We also learned the old process (every incident was urgent) was in part a response to another velocity problem; stakeholders believed that unless something was considered urgent it would never get fixed by the engineering team. By having an incident triage process, a procedure for when something would get fixed based on its urgency, the engineering team and the stakeholders solved this problem.
At AKF, we are experts at helping engineering teams improve efficiency, performance, fixing velocity problems, and improving value. In many cases, the prescription for the team is not obvious. Our consultants help company leaders uncover the root causes of their performance problems, establish vision and execute prescriptions that result in meaningful change. Let us help you with your performance problems so your teams can perform at their best!
Subscribe to the AKF Newsletter
Are you compromised?
September 14, 2018 | Posted By: Larry Steinberg
It’s important to acknowledge that a core competency for hackers is hiding their tracks and maintaining dormancy for long periods of time after they’ve infiltrated an environment. They also could be utilizing exploits which you have not protected against - so given all of this potential how do you know that you are not currently compromised by the bad guys? Hackers are great hidden operators and have many ‘customers’ to prey on. They will focus on a customer or two at a time and then shut down activities to move on to another unsuspecting victim. It’s in their best interest to keep their profile low and you might not know that they are operating (or waiting) in your environment and have access to your key resources.
Most international hackers are well organized, well educated, and have development skills that most engineering managers would admire if not for the malevolent subject matter. Rarely are these hacks performed by bots, most occur by humans setting up a chain of software elements across unsuspecting entities enabling inbound and outbound access.
What can you do? Well to start, don’t get complacent with your security, even if you have never been compromised or have been and eradicated what you know, you’ll never know for sure if you are currently compromised. As a practice, it’s best to always assume that you are and be looking for this evidence as well as identifying ways to keep them out. Hacking is dynamic and threats are constantly evolving.
There are standard practices of good security habits to follow - the NIST Cybersecurity Framework and OWASP Top 10. Further, for your highest value environments here are some questions that you should consider: would you know if these systems had configuration changes? Would you be aware of unexpected processes running? If you have interesting information in your operating or IT environment and the bad guys get in, it’s of no value unless they get that information back out of the environment; where is your traffic going? Can you model expected outbound traffic and monitor this? The answer should be yes. Then you can look for abnormalities and even correlate this traffic with other activities in your environment.
Just as you and your business are constantly evolving to service your customers and to attract new ones, the bad guys are evolving their practices too. Some of their approaches are rudimentary because we allow it but when we buckle down they have to get more innovative. Ensure that you are constantly identifying all the entry points and close them. Then remain diligent to new approaches they might take.
Don’t forget the most common attack vector - humans. Continue evolving your training and keep the awareness high within your staff - technical and non-technical alike.
Your default mental model should be that you don’t know what you don’t know. Utilize best practices for security and continue to evolve. Utilize external or build internal expertise in the security space and ensure that those skills are dynamic and expanding. Utilize recurring testing practices to identify vulnerabilities in your environment and to prepare against emerging attack patterns.
We commonly help organizations identify and prioritize security concerns through technical due diligence assessments. Contact us today.
Subscribe to the AKF Newsletter
Expanding Agile Throughout
September 6, 2018 | Posted By: James Fritz
In our experience we have seen how Agile practices provide organizations within successful companies many benefits which is leading to more and more companies adopting frameworks of Agile outside of software development. Whether they are looking for reduced risk, higher product quality, or even the capability to “fail fast” and rectify mistakes, Agile provides many benefits, particularly in management.
While effort has been expended to identify how to create Agile product delivery teams (Organizing Product Teams for Innovation) and conversely why they fail (The Top Five Most Common Agile PDLC Failures) – a lot of the focus is on the successes and failures of the delivery teams themselves. But the delivery is only as good as the group that surrounds that team.
So how does Agile work beyond your delivery teams? An essay published in 1970 by Robert K. Greenleaf, The Servant as Leader, is credited with introducing the idea of a Servant-Leader, someone who puts their employees’ needs ahead of their own. This is counter-intuitive to a normal management style where management has a list of needs that require completion.
Looking at an Agile team, the concept of waiting for management to drive needs is not conducive to meeting the requirements of the market. A highly competent Agile team has all the necessary tools and authority to get the job done that is required of them. If normal management tactics sit over an Agile team, failure is going to occur.
This is where the philosophy of Servant-Leadership comes into play. If managers, all the way to the C-Suite, understand that they work for their employees, but their employees are accountable to them, then everyone is working towards one goal: the needs of the market. Management needs to be focused on securing the resources necessary for product delivery teams to meet the demands of the market, whether from a high level of the CEO and CFO for additional funding or further down with ensuring that technical debt and other tasks are assigned out appropriately to meet delivery goals. This empowerment for teams may seem risky, but the morale improvement and greater innovation that can be achieved far exceeds the level of risk that would be accepted.
Embracing Agile throughout a company is key to the company being able to survive beyond the first couple sprints. Small changes in management can play a huge role in that. Asking simple questions like, “what do you need to meet your goals”, or “what factors stand in your way of accomplishment” help to enable employees instead of limiting them. Asking yourself why you are successful as a company also helps to identify what segment is responsible for your success.
If the delivery of your services is what customers buy, then identifying ways to enable employees who create those services is vital. This isn’t to say that other roles in the company aren’t important. Without support from the entire company, no one particular segment can succeed. This is why it is so vital for Agile to permeate throughout your entire organization. If you need assistance in identifying gaps in Agile and figuring out how to employ it, reach out to AKF.
Subscribe to the AKF Newsletter
SaaS Risk and Value Shift
August 2, 2018 | Posted By: Marty Abbott
The movement to SaaS specifically, and more broadly “Anything” (X) as a Service (XaaS) is driven by demand side (buyer) forces. In early cases within any industry, the buyer seeks competitive advantage over competitors. The move to SaaS allows the buyer to focus on core competencies, increasing investments in the areas that create true differentiation. Why spend payroll on an IT staff to support ERP solutions, mail solutions, CRM solutions, etc when that same payroll could otherwise be spent on engineers to build product differentiating features or enlarge a sales staff to generate more revenue?
As time moves on and as the technology adoption lifecycle advances, the remaining buyers for any product feel they have no choice; the talent and capabilities to run a compelling solution for the company simply do not exist. As such, the late majority and laggard adopters are almost “forced” into renting a service over purchasing software.
Whether for competitive reasons, as in the case of early adopters through the early majority, or for lack of alternatives as in the case of late majority and laggards, the movement to SaaS and XaaS represents a shift in risk as compared to the existing purchased product options. This shift in risk is very much like the shift that happens between purchasing and leasing a home.
Renting a home or an apartment is almost always more expensive than owning the same dwelling. The reason for this should be clear: the person owning the property expects to make a profit beyond the costs of carrying a mortgage and performing upkeep on the property over the life of the owner’s investment. There are special “inversion” cases where renting is less expensive, such as in a low rental demand market, but these cases tend to reset the market ownership prices (house prices fall) as rents no longer cover mortgages or ownership does not make sense.
Conversely, ownership is almost always less expensive than renting or leasing. But owners take on more risk: the risk of maintenance activities; the risk of market prices; the risk and costs associated with remodeling to make the property attractive, etc.
The matrix below helps put the shift described above into context.
A customer who “owns” an on-premise solution also “owns” a great deal of risk for all of the components necessary to achieve their desired outcomes: equipment, security, power, licenses, the “-ilities” (like availability), disaster recovery, release management, and monitoring of the solution. The primary components of this risk include fluctuation in asset valuation, useful life of the asset, and most importantly – the risk that they do not have the right skills to maximize the value creation predicated on these components.
A customer who “rents” a SaaS solution transfers most of these risks to a provider who specializes in the solution and therefore should be better able to manage the risk and optimize outcomes. In exchange, the customer typically pays a risk premium relative to ownership. However, given that the provider can likely operate the solution more cost effectively, especially if it is a multi-tenant solution, the risk premium may be small. Indeed, in extreme cases where the company can eliminate headcount, say after eliminating all on-premise solutions, the lessee may experience an overall reduction in cost.
But what about the provider of the service? After all, the “old world” of simply slinging code and allowing customers to take all the risk was mighty appealing; the provider enjoyed low costs of goods sold (and high gross margins) and revenue streams associated with both licensing and customization. The provider expects to achieve higher revenue from the risk premium charged for services. The provider also expects overall margins through greater efficiencies in running solutions with significant demand concentration at scale. The risk premium more than compensates the provider for the increased cost of goods sold relative to the on-premise business. Overall, the provider assumes risk for greater value creation. Both the customer and the provider win.
Architecture and product financial decisions are key to achieving the margins above.
Gross margins are directly correlated with the level of tenancy of any XaaS provider (Y axis). As such, while we want to avoid “all tenancy” for availability reasons, we desire a high level of tenancy to maximize equipment utilization and increase gross margins. Other drivers of gross margins include the level of demand upon shared components and the level of automation on all components – the latter driving down cost of labor.
The X axis of the chart above shows the operating expense associated with various business models. Multi-tenant XaaS offerings collapse the number of “releases supported in the wild” – reducing the operating expense (and increasing gross margins) associated with managing a code base.
Another way of viewing this is to look at the relative costs of software maintenance and administration costs for various business models.
Plotted in the “low COGS” (X axis), “low Maintenance quadrant of the figure above is “True XaaS”. Few versions of a release reduce our cost to maintain a code base, and high equipment utilization and automation reduces our cost to provision a service.
In the upper right and unattractive quadrant is the ASP (Application Service Provider) model, where we have less control over equipment utilization (it is typically provisioned for individual customers) and less control over defining the number of releases.
Hosting a solution on-premise to the customer may reduce our maintenance fees, if we are successful in reducing releases, but significantly increases our costs. This is different than the on-premise model (upper left) in which the customer bears the cost of equipment but for which we have a high number of releases to maintain. The XaaS solution is clearly beneficial overall to maximize margins.
AKF Partners helps companies transition on-premise, licensed software products to SaaS and XaaS solutions. Let us help you on your journey.
Subscribe to the AKF Newsletter
The Phases of SaaS Grief
July 24, 2018 | Posted By: Marty Abbott
Over a decade of helping on-premise and licensed software companies through the transition to “Something as a Service” – whether that be Software (SaaS), Platform (PaaS), Infrastructure (IaaS), or Analytics (AaaS) – has given us a rather unique perspective on the various phases through which these companies transition. Very often we find ourselves in the position of a counselor, helping them recognize their current phase and making recommendations to deal with the cultural and operational roadblocks inherent to that phase.
While rather macabre, the phases somewhat resemble those of grieving after the loss of a loved one. The similarities make some sense here, as very often we work with companies who have had a very successful on-premise and/or licensed software business; they dominated their respective markets and “genetically” evolved to be the “alphas” in their respective areas. The relationship is strong, and their past successes have been very compelling. Why would we expect anything other than grieving?
But to continue to evolve, succeed, and survive in light of secular forces these companies must let their loved one (the past business) go and move on with a new and different life. To be successful, this life will require new behaviors that are often diametrically opposed to those that made the company successful in their past life.
It’s important to note that, unlike the grieving process with a loved one, these phases need not all be completed. The most successful companies, through pure willpower of the management team, power through each of these quickly and even bypass some of them to accelerate to the healing phase. The most important thing to note here is that you absolutely can move quickly – but it requires decisive action on the part of the executive team.
Phase 1: Denial This phase is characterized by the licensed/on-premise software provider completely denying a need to move to an “X” (something) as a Service (XaaS, e.g. SaaS, PaaS) model.
Commonly heard quotes inside the company:
- “Our customers will never move to a SaaS model.”
- “Our customers are concerned about security. IaaS, SaaS and PaaS simply aren’t an option.”
- “Our industry won’t move to a Cloud model – they are too concerned about ownership of their data.”
- “To serve this market, a solution needs to be flexible and customizable. Proprietary customer processes are a competitive advantage in this space – and our solution needs to map exactly to them.”
Reinforcing this misconceived belief is an executive team, a sales force, and a professional services team trapped in a prison of cognitive biases. Hypothesis myopia and asymmetric attention (both forms of confirmation bias) lead to psychological myopia. In our experience, companies with a predisposed bias will latch on to anything any customer says that supports the notion that XaaS just won’t work. These companies discard any evidence, such as pesky little startups picking up small deals, as aberrant data points.
The inherent lack of paranoia blinds the company to the smaller companies starting to nibble away at the portions of the market that the successful company’s products do not serve well. Think Seibel in the early days of Salesforce. The company’s product is too expensive and too complex to adequately serve the smaller companies beneath them. The cost of sales is simply too high, and the sales cycle too long to address the needs of the companies adopting XaaS solutions. In this phase, the company isn’t yet subject to the Innovator’s Dilemma as the blinders will not let them see it.
Ignorance is bliss…for awhile…
How to Avoid or Limit This Phase
Successful executive teams identify denial early and simply shut it down. They establish a clear vision and timeline to move to the delivery of a product as a service. As with any successful change initiative, the executive team creates, as a minimum:
- The compelling reason and need for change. This visionary element describes the financial and operational benefits in clear terms that everyone can understand. It is the “pulling” force necessary to motivate people through difficult times.
- A sense of fear for not making the change. This fear becomes the “stick” to the compelling “carrot” above. Often given the secular forces, this fear is quite simply the slow demise of the company.
- A “villain” or competitor. As is the case in nearly any athletic competition, where people perform better when they have a competitor of equivalent caliber (vs say running against a clock), so do companies perform better when competing against someone else.
- A “no excuses” cultural element. Everyone on the team is either committed to the result, or they get removed from the team. There is no room for passive-aggressive behavior, or behaviors inconsistent with the desired outcome. People clinging to the past simply prolong or doom the change initiative. Fast success, and even survival, requires that everyone be committed.
Phase 2: Reluctant but Only Partial Acceptance
This phase typically starts when a new executive, or sometimes a new and prominent product manager, is brought into the company. This person understands at least some of – and potentially all of – the demand side forces “pulling” XaaS across the curve of adoption, and notices the competition from below. Many times, the Innovator’s Dilemma keeps the company from attempting to go after the lower level competitors.
Commonly heard quotes inside the company:
- “Those guys (referring to the upstarts) don’t understand the complexities of our primary market – the large enterprise.”
- “There’s a place for those products in the SMB and SME space – but ‘real’ companies want the security of being on-premise.”
- “Sure, there are some companies entertaining SaaS, but it represents a tiny portion of our existing market.”
- “We are not diluting our margins by going down market.”
The company embarks upon taking all their on-premise solutions and hosting them, nearly exactly as implemented on-premise, as a “service”.
Many of the company’s existing customers aren’t yet ready to migrate to XaaS, but discussions are happening inside customer companies to move several solutions off-premise including email, CRM and ERP. These customers see the possibility of moving everything – they are just uncertain as to when.
How to Avoid or Limit This Phase
The answer for how to speed through or skip this phase is not significantly different than that of the prior phase. Vision, fear of death, a compelling adversary, and a “no excuses” culture are all necessary components.
Secular forces drive customers to seek a shift of risk. This shift is analogous to why one would rent instead of owning a home. The customer no longer wants the hassle of maintenance, nor are they truly qualified to perform that maintenance. They are willing to accept some potential increase in costs as capex shifts to opex, to relieve themselves of the burden of specializing in an area for which they are ill-equipped.
If not performed during the Denial phase, now is the time to remove executives who display behaviors inconsistent with the new desired SaaS Principles
Phase 3: Pretending to Have an Answer
The pretending phase starts with the company implementing essentially an on-premise solution as a “SaaS” solution. With small modifications, it is exactly what was shipped to customers before but presented online and with a recurring revenue subscription model. We often like to call this the “ASP” or “Application Service Provider” model. While the revenue model of the company shifts for a small portion of its revenue to recurring services fees, the solution itself has not changed much. In fact, for older client-server products Citrix or the like is often deployed to allow the solution to be hosted.
The product soon displays clear faults including lower than desired availability, higher than necessary cost of operations, higher than expected operating expenses, and lower margins than competitors overall. Often the company will successfully hide these “SaaS” results as a majority of their income from operations still come from on-premise solutions.
The company will often use nebulous terms like “Cloud” when describing the service offering to steer clear of direct comparisons with other “born SaaS” or “true SaaS” solutions. Sometimes, in extreme cases, the company will lie to itself about what they’ve accomplished, and it will almost always direct the conversation to topics seen as differentiating in the on-premise world rather than address SaaS Principles.
Commonly heard quotes inside the company:
- “Our ‘Cloud’ solution is world class – it’s the Mercedes of all solutions in the space with more features and functionality than any other solution.”
- “The smaller guys don’t have a chance. Look at how long it will take them to reach feature parity. The major players in the industry simply won’t wait for that.”
- “We are the Burger King of SaaS providers – you can still have it your way. And we know you need it your way.”
Meanwhile, customers are starting to look at true SaaS solutions. They tire of availability problems, response time issues, the customization necessary to get the solution to work in a suitable fashion and the lack of configurability. The lead time to implementation is still too long.
Sales people continue to sell the product the same way; promising whatever a customer wants to get a sale. Engineers still develop the same way, using the same principles that made the company successful on-premise and completely ignorant of the principles necessary to be successful in the SaaS world.
How to Avoid or Limit This Phase
It’s not completely a bad thing to launch, as a first step, a “hosted” version of a company’s licensed product. But the company must understand internally that it is only an interim step.
In addition to the visionary and behavioral components of the previous phases, the company now must accept and be planning for a smaller functionality solution that will be more likely adopted by “innovators” and “early majority” companies. The concept of MVP relative to the Technology Adoption Lifecycle is important here.
Further, the company must be aggressively weeding product, sales, and technology executives who lack the behaviors or skills to be successful and seeding the team with people who have “done this before”. Sales teams must act similarly to used car sales people in that they can only sell “what is on the lot” that will fit customer “need”, as compared to new car sales people who can promise options and colors from the factory (“It will take more time”) that more precisely fit a customer’s “want”.
Phase 4: Fear
The company loses its first major deal or two to a rival product that appears to be truly SaaS and abides by SaaS Principles. They realize that their ASP product simply isn’t going to cut it, and Sales people are finally “getting” that the solution they have simply won’t work. The question is: Is the company too late? The answer depends on how long it took the company to get to this position. A true SaaS solution is at the very least months away and potentially years away. If the company moves initially right to the “Fear” stage and properly understands the concepts behind the TALC, they have a chance.
Commonly heard quotes inside the company:
- “We’re screwed unless we get this thing re-architected in order to properly compete in the XaaS space.”
- “Stop behaving like we used to – stop promising customizations. That’s not who we are anymore.”
- “The new product needs to do everything the old product did.” [Incorrect and prone to failing]
- “Think smaller, and faster. Think some of today’s customers – not all of them – for the first release. Understand MVP is relative to the TALC.” [Correct and will help drive success]
How to Avoid or Limit This Phase
This is the most easily avoided phase. With proper planning and execution in prior phases, a company can completely skip the fear stage.
When companies find themselves here, its typically because they have not addressed the talents and approach of their sales, product, and engineering teams. Sales behaviors must change to only sell what’s “on the car lot”. Engineers must understand how to build the “-ilities” into products from day 1. Product managers must switch to identifying market need, rather than fulfilling customer want. Executives must now run an entirely different company.
Final Phase: Healing or Marginalization
Companies successful enough to achieve this phase do so only through launching a true XaaS product – one that abides by XaaS principles built and run by executives, managers and individual contributors who truly understand or are completely wedded to learning what it means to be successful in the XaaS world.
The phases of grief are common among many of our customers. But unlike grieving for a loved one, they are not necessary. Quick progression, or better yet avoidance, of these phases can be accomplished by:
- Establishing a clear and compelling vision based on market and secular force analysis, and an understanding of the technology adoption lifecycle. As with any vision, it should not only explain the reason for change, but the positive long-term financial impact of change.
- Ensuring that everyone understands the cost of failure, helping to instill some small level in fear that should help drive cultural change.
- Ensuring that a known villain or competitor exists, against which we are competing to help boost performance and speed of transition.
- Aggressively addressing the cultural and behavioral changes necessary to be successful. Anyone who is not committed and displaying the appropriate changes in behavior needs to be weeded from the garden.
This shift often results in a significant portion of the company departing – sometimes willingly and sometimes forcefully. Some people don’t want to change and can find other companies (for a while) where their skills and behaviors are relevant. Some people have the desire, but may not be capable of changing in the time necessary to be successful.
Image Credit: Tim Gouw from Pexels
Subscribe to the AKF Newsletter
People Due Diligence
July 12, 2018 | Posted By: Robin McGlothin
Most companies do a thorough job of financial due diligence when they acquire other companies. But all too often, dealmakers simply miss or underestimate the significance of people issues. The consequences can be severe, from talent loss after a deal’s announcement, to friction or paralysis caused by differences in decision-making styles.
When acquirers do their people homework, they can uncover skills & capability gaps, points of friction, and differences in decision making. They can also make the critical people decisions - who stays, who goes, who runs the various lines of business, what to do with the rank and file at the time the deal is announced or shortly thereafter. Making such decisions within the first 90 days is critical to the success of a deal.
Take for example, Charles Schwab’s 2000 acquisition of US Trust. Schwab & the nation’s oldest trust company set out to sign up the newly minted millionaires created by a soaring bull market. But the cultures could not have been farther apart – a discount do-it-yourself stock brokerage style and a full-service provider devoted to pampering multimillionaires can make for a difficult integration. Six years after the merger, Chuck Schwab came out of retirement to fix the issues related to culture clash. The acquisition reflects a textbook common business problem. The dealmakers simply ignored or underestimated the significance of people and cultural issues.
Another example can be found in the 2002 acquisition of PayPal by eBay. The fact that many on the PayPal side referred to it as a merger, sets the stage for conflicting cultures. eBay was often embarrassed by the fact that PayPal invoice emails for a won auction arrived before the eBay end of auction email - PayPal made eBay look bad in this instance and the technology teams were not eager to combine. As well, PayPal titles were discovered to be one level higher than eBay titles considering the scope of responsibilities. Combining the technology teams did not go well and was ultimately scrapped in favor of dual teams - not the most efficient organizational model.
People due diligence lays the groundwork for a smooth integration. Done early enough, it also helps acquirers decide whether to embrace or kill a deal and determine the price they are willing to pay. There’s a certain amount of people due diligence that companies can and must do to reduce the inevitable fallout from the acquisition process and smooth the integration.
Ultimately, the success or failure of any deal has to do with people. Empowering people and putting them in a position where they will be successful is part of our diligence evaluation at AKF Partners. In our experience with clients, an acquiring company must start with some fundamental question:
1. What is the purpose of the deal?
2. Whose culture will the new organization adopt?
3. Will the two cultures mesh?
4. What organizational structure should be adopted?
5. How will rank-and-file employees react to the deal?
Once those questions are answered, people due diligence can focus on determining how well the target’s current structure and culture will mesh with those of the proposed new company, who should be retained and by what means, and how to manage the reaction of the employee base.
In public, deal-making executives routinely speak of acquisitions as “mergers of equals.” That’s diplomatic, politically correct speak and usually not true. In most deals, there is not only a financial acquirer, there is also a cultural acquirer, who will set the tone for the new organization after the deal is done. Often, they are one and the same, but they don’t have to be.
During our Technology Due Diligence process at AKF Partners, we evaluate the product, technology and support organizations with a focus on culture and think through how the two companies and teams are going to come together. Who the cultural acquirer is dependes on the fundamental goal of the acquisition. If the objective is to strengthen the existing product lines by gaining customers and achieving economies of scale, then the financial acquirer normally assumes the role of the cultural acquirer.
People due diligence, therefore, will be to verify that the target’s culture is compatible enough with the acquirers to allow for the building of necessary bridges between the two organizations. Key steps that are often missed in the process:
• Decide how the two companies will operate after the acquisition — combined either as a fully integrated operating company or as autonomous operating companies.
• Determine the new organizational structure and identify areas that will need to be integrated.
• Decide on the new executive leadership team and other key management positions.
• Develop the process for making employment-related decisions.
With regard to the last bullet point, some turnover is to be expected in any company merger. Sometimes shedding employees is even planned. It is important to execute The Weed, Seed & Feed methodology ongoing not just at acquisition time. Unplanned, significant levels of turnover negatively impact a merger’s success.
AKF Partners brings decades of hands-on executive operational experience, years of primary research, and over a decade of successful consulting experience to the realm of product organization structure, due diligence and technology evaluation. We can help your company successfully navigate the people due diligence process.
Agile and Dealing With The Cone of Uncertainty
July 8, 2018 | Posted By: Dave Berardi
The Leap of Faith
When we embark on building SaaS product that will delight customers we are taking a leap of faith. We often don’t even know whether or not the outcomes targeted are possible. Investing and building software is often risky for several reasons:
- We don’t know what the market wants.
- The market is changing around us.
- Competition is always improving their time to market (TTM) releasing competitive products and services.
We have to assume there will be project assumptions made that will be wrong and that the underlying development technology we use to build products is constantly changing and evolving. One thing is clear on the SaaS journey – the future is always murky!
The journey that’s plagued with uncertainty for developing SaaS is seen throughout the industry and is evidenced by success and failure from big and small companies – from Facebook to Apple to Salesforce to Google. Google is one of many innovating B2C companies that have used the cone of uncertainty to help inform how to go to market and whether or not to sunset a service. The company realizes that in addition to innovating, they need to reduce uncertainty quickly.
For example, Google Notebook, a browser-based note-taking and information sharing service, was killed and resurrected as part of Google Docs and has a mobile derivative called Keep. Google Buzz, Google’s first attempt at a social network was quickly killed after a little over a year in 2011. These are just a few B2C examples from Google. All of these are examples of investments that faced the cone of uncertainty. Predicting successful outcomes longer term and locking in specifics about a product will only be wasteful and risky.
The cone of uncertainty describes the uncertainty and risk that exist when an investment is made for a software project. The cone depicts the amount of risk and degree of precision for certainty thru the funnel. The further out we try to forecast features, capabilities, and adoption, the more risk and uncertainty we must assume. This is true for what we attempt to define as a product to be delivered and the timing on when we will deliver it to market. Over time, firms must make adjustments to the planned path along the way to capture and embrace changing market needs.
In today’s market we must quickly test our hypothesis and drive innovation to be competitive. An Agile product development life cycle (PDLC) and appropriately aligned organization helps us to do just that. To address the challenge the cone represents, we must understand what an Agile PDLC can do for the firm and what it cannot do for the firm.
Address the Uncertainty of the Cone
When we use an Agile approach, we must fix time and cost for development and delivery of a product but we allow for adjustment and changes to scope to meet fixed dates. The team can extend time later in the project but the committed date to delivery does not change. We also do not add people since Brooks Law teaches us that adding human resources to a late software project only delays it further. Instead we accelerate our ability to learn with frequent deployments to market resulting in a reduction in uncertainty. Throughout this process, discovery of both what the feature set needs to be for a successful outcome and how something should work is accomplished.
Agile allows for frequent iterations that can keep us close to the market thru data. After a deployment, if our system is designed to be monitored, we can capture rich information that will help to inform future prioritization, new ideas about features and modifications that may be needed to the existing feature set. Agile forces us to frequently estimate and as such produce valuable data for our business. The resulting velocity of our sprints can be used to revise future delivery range forecasts for both what will be delivered and when it will be delivered. Data will also be produced throughout our sprints that will help to identify what may be slowing us down ultimately impacting our time to market. Positive morale will be injected into the tams as results can be observed and felt in the short term.
What agile is not and how we must adjust?
While using an Agile method can help address the cone of uncertainty, it’s not the answer to all challenges. Agile does not help to provide a specific date when a feature or scope will be delivered. Instead we work towards ranges. It also does not improve TTM just because our teams started practicing it. Company philosophies, principles, and rules are not defined through an Agile PDLC. Those are up to the company to define. Once defined the teams can operate within the boundaries to innovate. Part of this boundary definition needs to start at the top. Executives need to paint a vivid picture of the desired outcome that stirs up emotion and can be measurable. The vision is at the opening of the cone. Measurable Key Results that executives define to achieve outcomes allow for teams to innovate making tradeoffs as they progress towards the vision. Agile alone does not empower teams or help to innovate. Outcomes, and Key Results (OKRs) cascaded into our organization coupled with an Agile PDLC can be a great combination that will empower teams giving us a better chance to innovate and achieve desirable time to market. Implementing an OKR framework helps to remove the focus of cranking out code to hit a date and redirects the needed attention on innovation and making tradeoffs to achieve the desired outcome.
Agile does not align well with annual budget cycles. While many times, an annual perspective is required by shareholders, an Agile approach is in conflict with annual budgeting. Since Agile sees changing market demands, frequent budget iterations are needed as teams may request additional funding to go after an opportunity. It’s key that finance leaders embrace the importance of adjusting the budgeting approach to align with an Agile PDLC. Otherwise the conflict created could be destructive and create a barrier to the firms desired outcome.
Applying Agile properly benefits a firm by helping to address the cone and reducing uncertainty, empowering teams to deliver on an outcome, and ultimately become more competitive in the global marketplace. Agile is on the verge of becoming table stakes for companies that want to be world class. And as we described above noting the importance of a different approach to something like budgeting, its not just for software – it’s the entire business.
Let Us Help
AKF has helped many companies of all sizes when transitioning to an organization, redefining PDLC to align with desired speed to market outcomes, and SaaS migrations. All three are closely tied and if done right, can help firms compete more effectively. Contact us for a free consultation. We would love to help!
Subscribe to the AKF Newsletter
Marriage counseling for technology and business partners!
July 8, 2018 | Posted By: Dave Swenson
AKF often finds itself required to act as a marriage counselor trying to improve the relationship between technology and business ‘spouses’. In fact, we rarely find the relationship between these partners without at least some opportunity for a 3rd party, external, unbiased perspective to produce some suggestions. Given the backgrounds of the prototypical CEO or CTO, it is no surprise there are misunderstandings, miscommunication, and misalignment – there is a substantial experiential chasm between the two…
Recognizing how big this chasm, where it is narrow vs. wide between the two partners is vital to bridging this gap. One of the key aspects we try to immediately ascertain is whether there is a true partnership in place, versus a customer / order taker mindset. How much trust is currently present? Is a single language being used by the two, or is it bits and bytes vs. $$$?
Whether you are a CTO or a business executive, we suggest you go through the following set of questions. Even better, ask your tech or business partner to do their side and discuss and compare! Additionally, this self-analysis shouldn’t occur only at the highest levels, but all throughout the organization, particularly if you’re organizationally aligned.
Questions for Technology Leaders:
- When did you last come up with a proposal to increase revenue?
The best and perhaps most extreme, example of this is AWS, where the technology team took an internal solution built to improve Amazon developer productivity, recognized that all developers must face the same infrastructure challenges, and proposed it to Bezos as a new business line. Are you constantly seeking out ways in product, marketing, sales, technology to generate additional revenue, or solely focused on cost containment?
- Do you understand the balance sheet, statement of cash flows and income statement of your company?
These artifacts describe how the overall business community, your investors, are measuring you. Learning the meaning of these documents aids in spanning the bits & bytes vs. $$$ language barrier. This is where getting an MBA provides the most value.
- Can you represent the importance of addressing technical debt to your business peers?
You are responsible for the technical debt in your codebase, not your business. If you can’t explain the true ongoing cost of the incurred debt, if you can’t justify the periodic pay down of that debt, you frankly are failing as a technology leader, at least if you have a business partner willing to listen.
- Can you state the highest priority issues facing your business peers today?
We love the following quote from Camille Fournier ( former CTO of Rent the Runway and author of The Manager’s Path):
“If the CTO does not have a seat at the executive table and does not understand the business challenges the company is facing, there is no way the CTO can guide the technology to solve those problems”
- Do you feel your team, your engineers, understand how their daily activities affect the business and your customers?
I once left a company producing a relational database to then join a startup that had built its application on top of that RDBMS. I quickly found issues that I knew could easily and cheaply be addressed, but had never heard of these pain points until I personally experienced them! I vowed to never be so removed and distant from my customers again. Zappos requires all new employees to take a month long customer service stint, spending 40 hours on the phones. During the holiday peak, all employees are expected to jump on the phones to ensure the same level of response as the rest of the year. Don’t just “eat your own dog food”, but understand how your customers eat it.
- Do your engineers understand what each functional product component costs to build, maintain, and support - relative to the value it brings to the business? Do they push back against product and business when there’s a minimal or even negative ROI?
A great vehicle to explain revenue flow is a Dupont diagram, mapping out the user experience flow, and assigning value across that flow. That value makes it clear that say, a .5% improvement in relevant search results can turn into a .025% uptick in items in cart, that turns into $X increase in revenue.
- Do you provide early feedback on the likelihood of making key dates? Is that feedback consistently incorrect?
If you’ve ever had your house remodeled, you’ll agree that there’s little that is more frustrating than a contractor who consistently under-delivers, and it late on agreed to delivery dates. You’ve got plans hinging upon the construction completion date, and when that date slips, it destroys your plans. Your business peers feel the same way when your date slips, or scope gets cut. Are you actively seeking out the causes of such delays? How can you be transparent with your partners when you don’t understand the causes?
- Does your technology team measure themselves against metrics that are meaningful to the business?
Ensure your teams are measuring the outcome of their work, not simply the completion and delivery of that work. And, that outcome measurement should be made in business terms. Velocity should always be measured, but an increase in velocity is frankly less important than moving targeted business needles in the desired direction!
- What are you least transparent about, and why?
Typically, the issues we are most reluctant to share are those we ourselves are uncomfortable with. The answer to this question can show you the areas where you are paying the least attention.
Questions for Business Executives:
- What is your reaction when you hear that a date has slipped?
“Shit happens” is too simple of an explanation, but there are many reasons why a key date slips. There might have been a change in prioritization, driven from the highest levels. There could have been critical site issues that pulled the team away from new functionality. The scope could have been grossly underestimated, or have grown for innumerable reasons along the way. The key thing is that your technology partner should be able to explain the causes - so don’t be afraid to ask for an explanation. Just don’t start the conversation by pointing a finger.
- Do you feel technology as a whole understands the business? Are engineers close enough to your customers to really understand the value you bring them?
I am always dismayed when I find engineers who don’t understand what value, and how, your product provides the customer. An engineer shouldn’t only be motivated by technology problems, but should appreciate the value their product provides. I had the great pleasure of witnessing a company adopt Agile, resulting in tighter bonds between customers, business, and technology. A particular engineer had never understood the value of their product, not to just to their immediate customers but their customers’ customers. As this was a medically-oriented product, that end value was basically a better life. The engineer had worked at this company for a few years, yet never witnessed the true value of the product he had been building – a tragedy in my book. Make the effort to ensure everyone in your company understands the value your products provide, and the revenue stream flowing into the company – it will absolutely be worth the investment!
- Do you as a business leader spend as much time attempting to understand the technology team as they are hopefully trying to learn to read financial statements? Any time?
I absolutely love when a business leader is present at an AKF workshop/engagement. I certainly appreciate the dedication of time, but more importantly, the desire to better understand. Have you asked your technology team for a walkthrough of how the systems work? What their challenges are?
- Do the business leaders understand how to ask questions to know whether dates are both aggressive and achievable?
Your car has a redline. Do you typically exceed that redline RPM? Doubtful. Do you understand when your technology team has over-extended themselves? When they have relied upon heroics to meet a delivery?
- Does the business spend time in the beginning of a product life cycle figuring out how to measure success?
The entire company, business / support / sales / marketing / product / technology teams should be driving to achieve important business goals, and measure themselves by the progress, the outcomes, towards those goals. Delivering new functionality is critical, but more important are the improvements in business metrics that functionality brings. Are you measuring how you are affecting business metrics?
Questions for Both:
- What are your shared goals?
We are firm believers in OKRs (Objectives & Key Results), shared across the entire company. Alignment around these goals help frame discussions.
- Who gives more than takes? How are compromises reached?
There should be no real scorecard on this (classic passive/aggressive move, don’t go there), but can you provide examples of where you met in the middle? As in every relationship, it is critical to both give and take.
- Do you meet mostly by exception? When was the last time you did lunch?
I hated my dentist for years, until I met him on a soccer field and saw the whole individual, not just the guy that causes me pain. Commit to meeting your technology/business partner on a regular basis, including periodic out-of-the-office meetings.
- What is your “Marriage Math”?
Psychologist John Gottman, Ph.D., when trying to determine a methodology to predict which marriages will last and which will end in a divorce, found that when the ratio of positive to negative interactions fell below 5:1 (5 positive for every negative interaction), divorce was likely. Do you have a healthy line of communication with your partner, or does the communication quickly degrade into contempt and name calling?
Hopefully now you agree that a look at your relationship with your technology/business partner is of value. Every relationship requires investment and commitment on both sides. Consider bringing AKF to help facilitate these discussions – we are excellent marriage counselors.
Subscribe to the AKF Newsletter
The No Surprises Rule
May 23, 2018 | Posted By: AKF
We blogged recently about how to write precisely and concisely, highlighting how important it was to learn the “Three Sentence Rule” early in our careers so that when we communicated with other executives, we communicated with extreme brevity and clarity. We might think of this as the “what” of executive communication. Today, we’d like to quickly describe a few ground rules with respect to the “when” and “how” of communicating as executives.
10 or 15 years ago, a fad swept through technology, executives everywhere were writing “How to Communicate with Me” articles for their teams and co-workers. In the most positive light, these were serious attempts by quirky executives to help their teams learn to conform to their own bizarre communications requirements. We would argue that a modern technology executive with a reasonably non-quirky personality need not pen such narcissistic claptrap. Communications is so basic, we should not over-think the process.
In today’s world, we have a variety of communications channels available: face-to-face, email, text message, internal communications tools (e.g. Slack) and the good old telephone. When an unexpected issue occurs on our watch, our primary duty is to inform our superior, by any means necessary as quickly as possible.
Whether we work in a large corporate environment with thousands of employees or in a small team with 10 people, immediate communications are an absolute requirement. If we fail to do so, our superiors may hear of the unexpected news before we have a chance to tell them. Think of a major system outage… while we work to determine a root cause, the VP of Marketing sends a quick text to our boss (let’s say the CEO in this case.). Now the CEO is in possession of bad news about something we are responsible for. Our phone will ring immediately, and we’ll be on our back feet explaining why we hadn’t taken a moment to call.
A worse example might be a system outage that we, as CTO, were not aware of, and the very same VP of Marketing texts the CEO again. Now when the phone rings, we are surprised, just as the CEO was surprised by the VP of Marketing. Our team has failed at a very fundamental level.
There’s an informal rule that states: No Surprises. The corollary is, communicate as early as possible and as often as possible. A site outage demands an immediate upward missive with frequent updates. The leaders who work under us must also live by this rule. We can never be left out in the cold when it comes to significant information. Furthermore, we are solely accountable for the communication of negative news up to our bosses.
The idea of communicating early and communicating often has a number of uses beyond crisis communications. In the early days of eBay, Marty Abbott (managing partner of AKF Partners) set 4 objectives for the site operations teams: Availability (99.9%), Scalability, Cost and Operational Excellence. Every member of the operations teams knew the current availability as it was communicated nearly continuously. The other 3 objectives were communicated with equal frequency. It would be a significant surprise if a colleague was working on a project that was not associated with Availability, Scalability, Cost or Operational excellence. A few years later, we borrowed Marty’s objectives at Shutterfly and simplified: Up, Fast, Cheap and Easy. All 50 operations team members knew those goals and we repeated them like a mantra.
The quickest path to failure as technology executives is non-communication, the opposite of communicating clearly and frequently. Worse, those executives that don’t stay ahead of the surprises technology throws at us every day will find themselves working in a different industry.
To summarize how to communicate:
When: early and often
How: any means available
What: 3 sentences.
We don’t need to write 5 page essays on how to communicate unless we are quite peculiar.
Subscribe to the AKF Newsletter
Three Reasons Your Software Engineers May Not Be Successful
May 10, 2018 | Posted By: Pete Ferguson
Three Reasons Your Software Engineers May Not Be Successful
At AKF Partners, we have the unique opportunity to see trends among startups and well-established companies in the dozens of technical due diligence and more in-depth technology assessments we regularly perform, in addition to filling interim leadership roles within organizations. Because we often talk with a variety of folks from the CEO, investors, business leadership, and technical talent, we get a unique top-to-bottom perspective of an organization.
Three common observations
- People mostly identify with their job title, not the service they perform.
- Software Engineers can be siloed in their own code vs. contributing to the greater outcome.
- CEO’s vision vs. frontline perception of things as they really are.
Job Titles Vs. Services
The programmer who identifies herself as “a search engineer” is likely not going to be as engaged as her counterpart who describes herself as someone who “helps improve our search platform for our customers.”
Shifting focus from a job title to a desired outcome is a best practice from top organizations. We like to describe this as separating nouns and verbs – “I am a software engineer” focuses on the noun without an action: software engineer instead of “I simplify search” where the focus is on verb of the desired outcome: simplify. It may seem minor or trivial, but this shift can be a contributing impact on how team members understand their contribution to your overall organization.
Removing this barrier to the customer puts team members on the front line of accountability to customer needs – and hopefully also the vision and purpose of the company at large. To instill a customer experience, outcome based approach often requires a reworking of product teams given our experience with successful companies. Creating a diverse product team (containing members of the Architecture, Product, QA and Service teams for example) that owns the outcomes of what they produce promotes:
- Creating products customers love
If you have had experience in a Ford vehicle with the first version of Sync (bluetooth connectivity and onscreen menus) – then you are well aware of the frustration of scrolling through three layers of menus to select “bluetooth audio” ([Menu] -> [OK] -> [OK] -> [Down Arrow]-> [OK] -> [Down Arrow] -> [OK]) each time you get into your car. The novelty of wireless streaming was a key differentiator when Sync first was introduced – but is now table stakes in the auto industry – and quickly wears off when having to navigate the confusing UI likely designed by product engineers each focused on a specific task but void of designing for a great user experience. What was missing is someone with the vision and job description: “I design wireless streaming to be seamless and awesome - like a button that says “Bluetooth Audio!!!”
Hire for – and encourage – people who believe and practice “my real job is to make things simple for our customers.”
Avoiding Siloed Approach
Creating great products requires engineers to look outside of their current project specific tasks and focus on creating great customer experiences. Moving from reactively responding to customer reported problems to proactively identifying issues with service delivery in real time goes well beyond just writing software. It moves to creating solutions.
Long gone are the “fire and forget” days of writing software, burning to a CD and pushing off tech debt until the next version. To Millennials, this Waterfall approach is foreign, but unfortunately we still see this mentality engrained in many company cultures.
Today it is all about services. A release is one of many in a very long evolution of continual improvement and progression. There isn’t Facebook V1 to be followed by V2 … it is a continual rolling out of upgrades and bug fixes that are done in the background with minimum to no downtime. Engineers can’t afford to be laggard in their approach to continual evolution, addressing tech debt, and contributing to internal libraries for the greater good.
Ensure your technical team understands and is very closely connected to the evolving customer experience and have skin in the game. Among your customers, there likely is very little patience with “wait until our next release.” They expect immediately resolution or they will start shopping the competition.
Translating the Vision of the CEO to the Front Lines
During our our more in-depth technology review engagements we interview many people from different layers of management and different functions within the organization. This gives us a unique opportunity to see how the vision of the CEO migrates down through layers of management to the front-line programmers who are responsible for translating the vision into reality.
Usually - although not always - the larger the company, the larger the divide between what is being promised to investors/Wall Street and what is understood as the company vision by those who are actually doing the work. Best practices at larger companies include regular all-hands where the CEO and other leaders share their vision and are held accountable to deliverables and leadership checks that the vision is conveyed in product roadmaps and daily stand up meetings. When incentive plans focus directly on how well a team and individual understand and produce products to accomplish the company vision, communication gaps close considerably.
Creating and sustaining successful teams requires a diverse mix of individuals with a service mindset. This is why we stress that Product Teams need to be all inclusive of multiple functions. Architecture, Product, Service, QA, Customer Service, Sales and others need to be included in stand up meetings and take ownership in the outcome of the product.
The Dev Team shouldn’t be the garbage disposal for what Sales has promised in the most recent contract or what other teams have ideated without giving much thought to how it will actually be implemented.
When your team understands the vision of the company - and how customers are interacting with the services of your company - they are in a much better position to implement it into reality.
As a CTO or CIO, it is your responsibility to ensure what is promised to Wall Street, private investors, and customers is translated correctly into the services you ultimately create, improve, and publish.
As we look at new start-ups facing explosive 100-200% year-over-year growth, our question is always “how will the current laser focus vision and culture scale?” Standardization, good Agile practices, understanding technical debt, and creating a scalable on-boarding and mentoring process all lend to best answers to this question.
When your development teams are each appropriately sized, include good representation of functional groups, each team member identifies with verbs vs. nouns (“I improve search” vs. “I’m a software engineer”), and understand how their efforts tie into company success, your opportunities for success, scalability, and adaptability are maximized.
Do You Know What is Negatively Affecting Your Engineers’ Productivity? Shouldn’t You?
Enabling Time to Market (TTM) With Contributor Model Teams
Experiencing growing or scaling pains? AKF is here to help! We are an industry expert in technology scalability, due diligence, and helping to fill leadership gaps with interim CIO/CTO and other positions in addition to helping you in your search for technical leaders. Put our 200+ years of combined experience to work for you today!
Subscribe to the AKF Newsletter
The Top Five Most Common Agile PDLC Failures
April 27, 2018 | Posted By: Dave Swenson
Agile Software Development is a widely adopted methodology, and for good reason. When implemented properly, Agile can bring tremendous efficiencies, enabling your teams to move at their own pace, bringing your engineers closer to your customers, and delivering customer value
quicker with less risk. Yet, many companies fall short from realizing the full potential of Agile, treating it merely as a project management paradigm by picking and choosing a few Agile structural elements such as standups or retrospectives without actually changing the manner in which product delivery occurs. Managers in an Agile culture often forget that they are indeed still managers that need to measure and drive improvements across teams.
All too often, Agile is treated solely as an SDLC (Software Development Lifecycle), focused only upon the manner in which software is developed versus a PDLC (Product Development Lifecycle) that leads to incremental product discovery and spans the entire company, not just the Engineering department.
Here are the five most common Agile failures that we see with our clients:
- Technology Executives Abdicate Responsibility for their Team’s Effectiveness
Management in an Agile organization is certainly different than say a Waterfall-driven one. More autonomy is provided to Agile teams. Leadership within each team typically comes without a ‘Manager’ title. Often, this shift from a top-down, autocratic, “Do it this way” approach to a grass-roots, bottoms-up one sways way beyond desired autonomy towards anarchy, where teams have been given full freedom to pick their technologies, architecture, and even outcomes with no guardrails or constraints in place. See our Autonomy and Anarchy article for more on this.
Executives often become focused solely on the removal of barriers the team calls out, rather than leading teams towards desired outcomes. They forget that their primary role in the company isn’t to keep their teams happy and content, but instead to ensure their teams are effectively achieving desired business-related outcomes.
The Agile technology executive is still responsible for their teams’ effectiveness in reaching specified outcomes (e.g.: achieve 2% lift in metric Y). She can allow a team to determine how they feel best to reach the outcome, within shared standards (e.g.: unit tests must be created, code reviews are required). She can encourage teams to experiment with new technologies on a limited basis, then apply those learnings or best practices across all teams. She must be able to compare the productivity and efficiencies from one team to another, ensuring all teams are reaching their full potential.
- No Metrics Are Used
The age-old saying “If you can’t measure it, you can’t improve it” still applies in an Agile organization. Yet, frequently Agile teams drop this basic tenet, perhaps believing that teams are self-aware and critical enough to know where improvements are required. Unfortunately, even the most transparent and aware individuals are biased, fall back on subjective characteristics (“The team is really working hard”), and need the grounding that quantifiable metrics provide. We are continually surprised at how many companies aren’t even measuring velocity, not necessarily to compare one team with another, but to compare a team’s sprint output vs. their prior ones. Other metrics still applicable in an Agile world include quality, estimation accuracy, predictability, percent of time spent coding, the ratio of enhancements vs. maintenance vs. tech debt paydown.
These metrics, their definitions and the means of measuring them should be standardized across the organization, with regular focus on results vs. desired goals. They should be designed to reveal structural hazards that are impeding team performance as well as best practices that should be adopted by all teams.
- Your Velocity is a Lie
Is your definition of velocity an honest one? Does it truly measure outcomes, or only effort? Are you consistent with your definition of ‘done’? Take a good look at how your teams are defining and measuring velocity. Is velocity only counted for true ‘ready to release’ tasks? If QA hasn’t been completed within a sprint, are the associated velocity points still counted or deferred?
Velocity should not be a measurement of how hard your teams are working, but instead an indicator of whether outcomes (again, e.g.: achieve 2% lift in metric Y) are likely to be realized - take credit for completion only when in the hands of customers.
- Failure to Leverage Agile for Product Discovery
From the Agile manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Many companies work hard to get an Agile structure and its artifacts in place, but ignore the biggest benefit Agile can bring: iterative and continuous product discovery. Don’t break down a six-month waterfall project plan into two week sprints with standups and velocity measurements and declare Agile victory.
Work to create and deliver MVPs to your customers that allow you to test expected value and customer satisfaction without huge investment.
- Treating Agile as an SDLC vs. a PDLC
As explained in our article PDLC or SDLC, SDLC (Software Development Lifecycle) lives within PDLC (Product Development Lifecycle). Again, Agile should not be treated as a project management methodology, nor as a means of developing software. It should focus on your product, and hopefully the related customer success your product provides them. This means that Agile should permeate well beyond your developers, and include product and business personnel.
Business owners or their delegates (product owners) must be involved at every step of the PDLC process. PO’s need to be embedded within each Agile team, ideally colocated alongside team members. In order to provide product focus, POs should first bring to the team the targeted customer problem to be solved, rather than dictating only a solution, then work together with the team to implement the most effective solution to that problem.
AKF Partners helps companies transition to Agile as well as fine-tune their existing Agile processes. We can readily assess your PDLC, organization structure, metrics and personnel to provide a roadmap for you to reach the full value and benefits Agile can provide. Contact us to discuss how we can help.
Subscribe to the AKF Newsletter
Achieving Results, Culture, and the AKF Equation
April 24, 2018 | Posted By: Marty Abbott
We can tell a lot about a company within the first hour or so of any discussion. Consider the following statement fragments:
“We have a lot of smart people here…”
“We have some of the hardest working engineers…”
Contrast these with the following statement fragments:
“We measure ourselves against very specific business KPIs…”
“We win or lose daily based on how effectively we meet our customer expectations…”
There is a meaningful difference in the impact these two groups of statements have on a company’s culture and how that culture enables or stands in the way of success. The first group of statements are associated with independent variables (inputs) that will rarely in isolation result in desired outcomes (dependent variables). When used in daily discourse, they reinforce the notion that something other than outcomes are the things upon which a company prides itself. Our experience is that these statements create an environment of hubris that often runs perpendicular to, and at best in no way reinforces, the achievement of results. Put another way, when we hear statements like this, we expect to find many operational problems.
The second group of statements are focused on meaningful and measurable outcomes. The companies with which we’ve worked that frequently communicate with these statements are among the most successful we’ve seen. Even when these companies struggle, their effort and focus is solidly behind the things that matter – those things that create value for the broadest swath of stakeholders possible.
The point here is that how we focus communication inside our companies has an important impact on the outcomes we achieve.
Success is often a result of several independent variables aligning to achieve a desired outcome. These may include, as Jim Collins points out, being in the right place at the right time – sometimes called “luck”. Further, there is rarely a single guaranteed path to success; multiple paths may result in varying levels of the desired outcome. Great companies and great leaders realize this, and rather than focusing a culture on independent variables they focus teams on outcomes. By focusing on outcomes, leaders are free to attempt multiple approaches and to tweak a variety of independent variables to find the most expedient path to success. We created the AKF Equation (we sometimes refer to it as the AKF Law) to help focus our clients on outcomes first:
Two very important corollaries follow from this equation or “law”:
Examples of Why Results, and Not Paths Matter
Intelligence Does Not Equal Success
As an example of why the dependent variable of results and not an independent variable like intelligence is most important consider Duckworth and Seligman’s research. Duckworth and Seligman and associates (insert link) conducted a review of GPA performance in adolescents. They expected to find that intelligence was the best indication of GPA. Instead, they found that self-discipline was a better indication of the best GPAs:
Lewis Terman, a mid-20th century Stanford Pyschology professor hypothesized that IQ was highly correlated with success in his famous termite study of 1500 students with an average IQ of 151. Follow on analysis and study indicated that while these students were successful, they were half as successful as a group of other students with a lower IQ.
Chris Langan, the world’s self-proclaimed “most intelligent man” with an IQ of 195 can’t seem to keep a job according to Malcolm Gladwell. He’s been a cowboy, a stripper, a day laborer and has competed on various game shows.
While we’d all like to have folks of average or better intelligence on our team, the above clearly indicates that it’s more important to focus on outcomes than an independent variable like intelligence.
Drive Does Not Equal Success
While most successful companies in the Silicon Valley started with employees that worked around the clock, The Valley is also littered with the corpses of companies that worked their employees to the bone. Just ask former employees of the failed social networking company Friendster. Hard work alone does not guarantee success. In fact, most “overnight” success appears to take about 10,000 hours of practice just to be good, and 10 years of serious work to be truly successful (according to both Ramit Sethi and Malcolm Gladwell.)
Hard work, if applied in the right direction and to the right activities should of course help achieve results and success. But again, it’s the outcome (results and success) that matter.
Wisdom Does Not Equal Success
Touting the age and experience of your management team? Think again. There’s plenty of evidence that when it comes to innovative new approaches, we start to “lose our touch” at the age of 40. The largest market cap technology companies of our age were founded by “youngsters” – Bezos being the oldest of them at the age of 30. Einstein posited all of his most significant theories well before the age of 40 – most of them in the “miracle year” at the age of 26 in 1905. The eldest of the two Wright Brothers was 39.
While there are no doubt examples of successful innovation coming after the age of 40, and while some of the best managers and leaders we know are over the age of 40, wisdom alone is not a guarantee for success.
Only Success = Success
Most of the truly successful and fastest growing companies we know focus on a handful of dependent variables that clearly identify results, progress and ultimately success. Their daily manners and daily discourse are carefully formulated around evaluation of these success criteria. Even these company’s interaction with outside firms focuses on data driven indications of success time and time again – not on independent variables such as intelligence, work ethic, wisdom (or managerial experience), etc.
These companies identify key performance indicators for everything that they do, believing that anything worth doing should have a measurable value creation performance indicator associated with it. They maniacally focus on the trends of these performance indicators, identifying significant deviations (positive or negative) in order to learn and repeat the positive causes and avoid those that result in negative trends. Very often these companies employ agile planning and focus processes similar to the OKR process.
The most successful companies rarely engage in discussions around spurious relationships such as intelligence to business success, management experience to business success, or effort to business success. They recognize that while some of these things are likely valuable in the right proportions, they are rarely (read never) the primary cause of success.
AKF Partners helps companies develop highly available, scalable, cost effective and fast time-to-market products. We know that to be successful in these endeavors, companies must have the right people, in the right roles, with the right behaviors - all supported by the right culture. Contact us to discuss how we can help with your product needs.
Subscribe to the AKF Newsletter
How to write concisely
April 11, 2018 | Posted By: Geoffrey Weber
The Three Sentence Rule
Variations of the Three Sentence Rule have been around for a long time. The differences are multiplicative but the base rule is a useful and often necessary tool to teach concision to the wordy.
Say what you need to say in THREE sentences, or less.
Anyone who has been through flight school learns how to be concise on the radio. Who are you? Where are you? What do you want? That happens to be three sentences. “Palo Alto Tower, Cessna 15957X; 5 miles southwest of SLAC with information Echo; request landing.” The need to be precise, accurate and speedy is a requirement at a tower as busy as Palo Alto tower. Controllers have no patience because there are 12 other aircraft waiting to communicate.
As technologists, we are generally rewarded for producing details, the more the better. Engineers have to be obsessed with substance; their work is about precision and there are no shortcuts when it comes to building complex tools. It wouldn’t make any sense to try and distill how Cassandra compares to a relational database, in three sentences, in a room filled with colleagues, at a meet-up.
But what if our CEO asks us about Cassandra? How can we possibly explain to someone who is just a wee bit tech-illiterate the differences between two very different data stores? Moreover, why on earth would we try and distill that down to three sentences?? Let’s start at the beginning… before there were databases there were Hollerith Cards…
Lack of brevity is a death sentence to any technologist who finds themselves interacting with non-technologists on a regular basis. We see this as a common anti-pattern for CTOs; some never learn the difference between a novel, a paragraph, or sentence and why each has utility.
The controller in the tower could care less about why we’re in an airplane today, that we’re stopping at the restaurant for the traditional $100 hamburger and that we need to be home for dinner tonight:
- Who are you?
- Where are you?
- What do you want?
- Cassandra is a new database technology.
- It’s very different than what we use today.
- It will lower costs in the next 12 months.
That is the CEO-version of Cassandra in three sentences. “What is it called, why should I remember it, what does it do for me?”
At AKF Partners, we believe that technology executives need to start practicing a version of the three sentence rule as soon as they transition into their first leadership role. Specialists in Operations roles have an advantage because of the daily chaos and need for ongoing communications: “Customer sign-in unavailable for 15 minutes; 100% of our customers are impacted for 15 minutes; we are restarting the service for 100% operations in 10 minutes—update in 20 minutes.”
- What happened?
- What is the impact?
- When is it going to be fixed?
There’s a practical reason for such precision: most CEOs are consuming information on tiny screens, sometimes over really bad internet (Detroit Airport) at 2 in the morning, and news also just arrived about a sales crisis in Europe, there’s a supply-chain issue in India, and the Wall Street Journal is doing a feature about the product that’s going live next week. If we mentioned Hollerith, or even thought about it for a second, we’re Exploring Alternative Employment. If they have a moment to breath, they can ask for more detail. Or maybe next week.
Sometimes we’re required to communicate when there’s no answer. Try this:
- Impact update,
- Standard procedures failed, assembled SWAT,
- Updates every 15 minutes until resolution.
An equally important rule for executives is the “No Surprise Rule” (stay tuned) and zero sentences are as fatal as 4 sentences at the wrong time. Keeping a CEO waiting for 2 hours until root cause is determined is stupid.
The final place to consider the Three Sentence Rule is the boardroom itself. Most boards members are not going to read through the 200 page board deck, and our ten minutes to discuss the Cassandra project is unlikely to resonate with most of the attendees. Up and coming executives understand the need for absolute precision. Steve Jobs could do it with a single slide:
Three sentences, if you count the background gradient as a sentence.
For the Board:
- We’re introducing new technology next fiscal year.
- It’s called Cassandra.
- A year from now I will demonstrate how it increased EBITDBA by $2M.
- Anything can be explained in 3 sentences
- Even concepts so fantastic they seem magical
- If you don’t believe me, Books in 3 Sentences
At AKF Partners, we can help with mentoring, coaching and leadership training.
Subscribe to the AKF Newsletter
SaaS Migration Challenges
March 12, 2018 | Posted By: Dave Swenson
More and more companies are waking up from the 20th century, realizing that their on-premise, packaged, waterfall paradigms no longer play in today’s SaaS, agile world. SaaS (Software as a Service) has taken over, and for good reason. Companies (and investors) long for the higher valuation and increased margins that SaaS’ economies of scale provide. Many of these same companies realize that in order to fully benefit from a SaaS model, they need to release far more frequently, enhancing their products through frequent iterative cycles rather than massive upgrades occurring only 4 times a year. So, they not only perform a ‘lift and shift’ into the cloud, they also move to an Agile PDLC. Customers, tired of incurring on-premise IT costs and risks, are also pushing their software vendors towards SaaS.
SaaS Migration is About More Than Just Technology – It is An Organization Reboot
But, what many of the companies migrating to SaaS don’t realize is that migrating to SaaS is not just a technology exercise. Successful SaaS migrations require a ‘reboot’ of the entire company. Certainly, the technology organization will be most affected, but almost every department in a company will need to change. Sales teams need to pitch the product differently, selling a leased service vs. a purchased product, and must learn to address customers’ typical concerns around security. The role of professional services teams in SaaS drastically changes, and in most cases, shrinks. Customer support personnel should have far greater insight into reported problems. Product management in a SaaS world requires small, nimble enhancements vs. massive, ‘big-bang’ upgrades. Your marketing organization will potentially need to target a different type of customer for your initial SaaS releases - leveraging the Technology Adoption Lifecycle to identify early adopters of your product in order to inform a small initial release (Minimum Viable Product).
It is important to recognize the risks that will shift from your customers to you. In an on-premise (“on-prem”) product, your customer carries the burden of capacity planning, security, availability, disaster recovery. SaaS companies sell a service (we like to say an outcome), not just a bundle of software. That service represents a shift of the risks once held by a customer to the company provisioning the service. In most cases, understanding and properly addressing these risks are new undertakings for the company in question and not something for which they have the proper mindset or skills to be successful.
This company-wide reboot can certainly be a daunting challenge, but if approached carefully and honestly, addressing key questions up front, communicating, educating, and transparently addressing likely organizational and personnel changes along the way, it is an accomplishment that transforms, even reignites, a company.
This is the first in a series of articles that captures AKF’s observations and first-hand experiences in guiding companies through this process.
Don’t treat this as a simple rewrite of your existing product –
Answer these questions first…
Any company about to launch into a SaaS migration should first take a long, hard look at their current product, determining what out of the legacy product is not worth carrying forward. Is all of that existing functionality really being used, and still relevant? Prior to any move towards SaaS, the following questions and issues need to be addressed:
Customization or Configuration?
SaaS efficiencies come from many angles, but certainly one of those is having a single codebase for all customers. If your product today is highly customized, where code has been written and is in use for specific customers, you’ve got a tough question to address. Most product variances can likely be handled through configuration, a data-driven mechanism that enables/disables or otherwise shapes functionality for each customer. No customer-specific code from the legacy product should be carried forward unless it is expected to be used by multiple clients. Note that this shift has implications on how a sales force promotes the product (they can no longer promise to build whatever a potential customer wants, but must sell the current, existing functionality) as well as professional services (no customizations means less work for them).
Many customers, even those who accept the improved security posture a cloud-hosted product provides over their own on-premise infrastructure, absolutely freak when they hear that their data will coexist with other customers’ data in a single multi-tenant instance, no matter what access management mechanisms exist. Multi-tenancy is another key to achieving economies of scale that bring greater SaaS efficiencies. Don’t let go of it easily, but if you must, price extra for it.
Who Owns the Data?
Many products focus only on the transactional set of functionality, leaving the analytics side to their customers. In an on-premise scenario, where the data resides in the customers’ facilities, ownership of the data is clear. Customers are free to slice & dice the data as they please. When that data is hosted, particularly in a multi-tenant scenario where multiple customers’ data lives in the same database, direct customer access presents significant challenges. Beyond the obvious related security issues is the need to keep your customers abreast of the more frequent updates that occur with SaaS product iterations. The decision is whether you replicate customer data into read-only instances, provide bulk export into their own hosted databases, or build analytics into your product?
All of these have costs - ensure you’re passing those on to your customers who need this functionality.
May I Upgrade Now?
Today, do your customers require permission for you to upgrade their installation? You’ll need to change that behavior to realize another SaaS efficiency - supporting of as few versions as possible. Ideally, you’ll typically only support a single version (other than during deployment). If your customers need to ‘bless’ a release before migrating on to it, you’re doing it wrong. Your releases should be small, incremental enhancements, potentially even reaching continuous deployment. Therefore, the changes should be far easier to accept and learn than the prior big-bang, huge upgrades of the past. If absolutely necessary, create a sandbox for customers to access new releases, but be prepared to deal with the potentially unwanted, non-representative feedback from the select few who try it out in that sandbox.
Wait? Who Are We Targeting?
All of the questions above lead to this fundamental issue: Are tomorrow’s SaaS customers the same as today’s? The answer? Not necessarily. First, in order to migrate existing customers on to your bright, shiny new SaaS platform, you’ll need to have functional parity with the legacy product. Reaching that parity will take significant effort and lead to a big-bang approach. Instead, pick a subset or an MVP of existing functionality, and find new customers who will be satisfied with that. Then, after proving out the SaaS architecture and related processes, gradually migrate more and more functionality, and once functional parity is close, move existing customers on to your SaaS platform.
To find those new customers interested in placing their bets on your initial SaaS MVP, you’ll need to shift your current focus on the right side of the Technology Adoption Lifecycle (TALC) to the left - from your current ‘Late Majority’ or ‘Laggards’ to ‘Early Adopters’ or ‘Early Majority’. Ideally, those customers on the left side of the TALC will be slightly more forgiving of the ‘learnings’ you’ll face along the way, as well as prove to be far more valuable partners with you as you further enhance your MVP.
The key is to think out of the existing box your customers are in, to reset your TALC targeting and to consider a new breed of customer, one that doesn’t need all that you’ve built, is willing to be an early adopter, and will be a cooperative partner throughout the process.
Our next article on SaaS migration will touch on organizational approaches, particularly during the build-out of the SaaS product, and the paradigm shifts your product and engineering teams need to embrace in order to be successful.
AKF has led many companies on their journey to SaaS, often getting called in as that journey has been derailed. We’ve seen the many potholes and pitfalls and have learned how to avoid them. Let us help you move your product into the 21st century. See our SaaS Migration service
Subscribe to the AKF Newsletter
There Are Always Plenty of Incidents from Which To Learn
January 13, 2018 | Posted By: Dave Swenson
Sorry, False Alarm…
On January 13, 2018, what felt like an episode of Netflix’s “Black Mirror” unfolded in real life. Just after 8 in the morning, residents and visitors of Hawaii were woken up to the following startling push notification:
Thankfully, the notification was a false alarm, finally retracted with a second notification nearly 40 interminable minutes later.
The amazing, poignant and sobering stories that occurred from those 40 minutes, included people:
- determining which children to spend their last minutes with,
- abandoning their cars on streets,
- sheltering in a lava tube,
- believing and acting as we all would if we believed the end was here.
Unfortunately, this wasn’t a Black Mirror episode and paralyzed an entire state’s population. Thankfully, the alarm was a false one.
A Muted President
As President Trump took office, he introduced a new means for a President to reach his constituents—Twitter, averaging 6 to 7 tweets per day during his first year. On November 2, 2017, many bots that were created to closely monitor the tweets of @realDonaldTrump started reporting that the account no longer existed. Clicking to his account took the user to the above error page.
For a deafening 11 minutes, the nation was unable to listen to its leader, at least via Twitter.
The Hawaiian false alarm was sent by the state’s Emergency Management Agency. Their explanation of the incident was that during a shift change, an employee clicked “the wrong button” while running a missile crisis test, then subsequently clicked through a confirmation prompt (“Are you sure you want to tell 1.5 million people this?”).
Twitter employees had reportedly tried for years to get management attention on ensuring accounts weren’t deleted without proper vetting. The company typically used contractors in the Philippines and Singapore to handle such account administration; Trump’s account was deleted by a German contract worker on his last day at Twitter. Acting on yet-another-Trump-complaint, believing such an important account couldn’t be suspended, the worker’s last action for Twitter was to click the suspend button, and then walked out of the building causing the Twitterverse to read far more into the account’s disappearance than they should have.
In both of these situations, the immediate focus was on the personnel involved in the incident. “Who pushed the button?” is typically always one of the initial questions. Assumptions that a new employee, or rogue worker were behind the incident are common, and both motive and intelligence of all involved are under inspection.
We at AKF Partners constantly preach “An incident is a terrible thing to waste”. Events such as these warp the known reality into “How the shit can that happen??”, causing enough alarm to warrant special attention and focus, if not panic. Yet, all too often we see teams searching frantically to find any cause, blame the most obvious, immediate factor, declare victory, and move on.
“Who pushed the button?” is only one of many questions.
Toyota’s Taichi Ohno, the father of Lean Manufacturing, recognized his team’s habit of accepting the most apparent cause, ignoring (wasting) other elements revealed by an incident, potentially allowing it to be eventually repeated. Ohno (the person, not the exclamation typically uttered during an incident) emphasized the importance of asking “5 Why’s” in order to move beyond the most obvious explanation (and accompanying blame), to peel the onion diving deeper into contributory causes.
Questions beyond the reflexive “What happened?” and “Who did it?” relevant to the false alarm and erroneous account deletion incidents include:
- Why did the system act differently than the individual expected (is there more training required, is the user interface a confusing one)?
- Why did it take so long to correct (is there no playbook for detecting / reversing such a message or key account activity)?
- Why does the system allow such an impactful event to be performed unilaterally, by a single person (what safeguards should exist requiring more than one set of hands?)
- Why does this particular person have such authorization to perform this action (should a non-employee have the ability to delete such a verified, popular and influential account)?
- Why was the possibility of this incident not anticipated and prevented (why were Twitter employee requests for better safeguards ignored for years, why wasn’t the ease of making such a mistake recognized and what other similar mistake opportunities are there)?
Both of these incidents have had an impact far beyond those directly affected (Hawaiian inhabitants or Trump Twitter followers), and have shed light on the need to recognize the world has changed and policies and practices of old might not be enough for today. The ballistic missile false alarm revealed that more controls need to be placed on all mass communication, but also that Hawaii (or anywhere/anyone else) is extremely unprepared for the unthinkable. The use of Twitter as a channel for the President now raises questions over the validity of it as a Presidential record, asks who should control such a channel, and raises concerns on what security is around the President’s account?
Ask 5 Whys, look beyond the immediate impact to find collateral learnings, and take notice of all that an incident can reveal.
AKF Partners have been brought in by over 400 companies to avoid such incidents, and when they do occur, to learn from them. Let us help you.
Subscribe to the AKF Newsletter
Conway’s Law – The Rest of the Story.. and How To Fix It
December 14, 2017 | Posted By: Marty Abbott
The Law that Almost Wasn’t
Conway’s law had a rather precarious beginning. Harvard Business Review rejected Conway’s thesis, buried as it was in the 43d paragraph of a 45-paragraph paper, on the grounds that he had not proven it.
But Mel had a PhD in Mathematics (from Case Western Reserve University – Go Spartans!), and like most PhDs he was accustomed to journal rejections. Mel resubmitted the paper to Datamation, a well-respected IT journal of the time, and his paper “How Do Committees Invent” was published in 1968.
It wasn’t until 1975, however, that the moniker “Conway’s Law” came to be. Fred Brooks both coined the term and popularized Conway’s thesis in his first edition of the Mythical Man Month. It has since been one of the most widely cited, important but nevertheless incorrectly understood and applied notions in the domain of product development.
Cliff’s Notes to “How Do Committees Invent” (the article in which the law resides)
Conway’s thesis, in his words:
… organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
Conway calls this self-similarity between organizations and designs homomorphism. Preamble to the thesis helps explain the breadth and depth:
… the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise
Every time a delegation is made … the class of design alternatives which can be effectively pursued is also narrowed.
Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.
Specifically, each individual must have at most one superior and at most approximately seven subordinates
Examples. A contract research organization had eight people who were to produce a COBOL and an ALGOL compiler. After some initial estimates of difficulty and time, five people were assigned to the COBOL job and three to the ALGOL job. The resulting COBOL compiler ran in five phases, the ALG0L compiler ran in three.
There are 4 very important points, and one very good example, in the quotes above:
1) Organizations and design/architecture and intrinsically linked. The organization affects and constrains the architecture - the opposite is not true.
2) Depth of an organization negatively effects design flexibility. The deeper the hierarchy of an organization, the less flexible (or alternatively more constrained) the resulting architecture.
3) We will make mistakes and must organize to quickly fix these.
4) Team size should always be small – which also has an implication to the size of the solution part a team can own (think Amazon’s re-branding of this point of the “2 Pizza Team” (author’s side note – read Scalability Rules for how this came about).
Important corollaries to Conway’s law suggest that if either an organization or a design change, without a corresponding change to the other, the product will be at risk.
Common Failures in Application of Conway’s Law and How to Fix Them
There are five very common failures in organization and architecture within our clients, the first four of which relate directly to Conway’s points above:
1) Organizations and architectures designed separately. Given the homomorphism that Conway describes, you simply CANNOT do this.
2) Deep, hierarchical organizations. Again – this will constrain design.
3) Lack of flexibility. Companies tend to plan for success. Instead, assume failure, learning, and adaptation (think “discovery” and “Agile” instead of “requirements” and “Waterfall”).
4) Large teams. Forget about these. Small teams, each owning a service or services that the team can support in isolation.
There is a fifth violation that is harder to see in Conway’s paper. Too often, our clients don’t build properly experienced teams around the solutions they deploy. Success in low-overhead organizations requires that teams be cross functional. Whatever a team needs to be successful should be within that team. If you deploy on your own hardware, you should have hardware experience. If you need DBA talent, the team should have direct access to that talent. QA folks should be embedded within the team, etc. Product managers or owners should also be embedded in the team. This creates our fifth failure:
5) Functional teams. Don’t build teams around “a skill” – build them around the breadth of skills necessary to accomplish the task handed to the team.
Conway’s Parting Shot and Food for Thought
Noodle on this: Conway identified a problem early in the life of a new domain. Yet what was true in Conway’s time as a contributor to the art is still true today, over 50 years after his first attempt to forewarn us:
Probably the greatest single common factor behind many poorly designed systems now in existence has been the availability of a design organization in need of work.
Like this article? Share it with friends here, and subscribe to the newsletter here.
AKF Partners helps companies ensure that their organizations and architectures are aligned to the outcomes they desire. We help companies develop better, more highly available and more highly scalable products with faster time to market and lower cost. Give us a call or shoot us an email. We’d love to help you achieve the success you desire.
Reach out to AKF
Subscribe to the AKF Newsletter
Tuckman’s Stages and Agile Development
November 8, 2017 | Posted By: Bill Armelin
In 1965, psychologist Bruce Tuckman published his theory of group dynamics. This theory describes the stages (or phases) through which a team progresses enroute to optimal productivity. While generally useful for any organization, and prescriptive as to what leaders should do when to boost performance, it has profound impacts to Agile development practices and how we build organizations around these Agile practices.
The first stage is forming. This is where the team first comes together. Here, the individuals are trying to get to know each other. They tend to be polite and cordial, but they do not fully trust each other.
In this stage, the team productivity and team conflict are low. The team spends time agreeing to what the team is supposed to do. This lack of agreement of the team’s purpose can cause members to miss goals because they are individually targeting different things. Team members rely on patterned behavior and look to the team leader for guidance and direction. The team members want to be accepted by the group. Cautious behavior on the part of the team starts to depress overall team outcomes. Good leadership, emphasizing goals and outcomes is important to set the stage for future team behaviors and outcomes.
Once the team’s goals are clear, they move into the next stage, storming. Here, the team starts to develop a plan to achieve the goal and defines what to do and who does it. Friction starts to occur as members propose different ideas. Trust within the team remains low and affective conflict rises as people vie for control. Cliques can form. Productivity drops even lower than in the first stage.
Once the team agrees on the plan and the roles and responsibilities, it can move to the next stage. Without agreement, the team can get stuck. Symptoms include poor coordination, people doing the wrong things and missing deadlines, to name a few. Good leadership here focuses on fast affective conflict resolution, and serves to help reinforce team goals and outcomes in order to quickly move to more productive phases.
Once team members agree to the plan and understand their roles, they enter the norming phase. Affective conflict goes down, cognitive (beneficial) conflict and trust increase. The team focuses on how to get things done and productivity begins to increase. The team develops “norms” about how to work together and collaborate. A lack of these norms can cause issues such as low quality and missed deadlines.
Leadership within the team becomes clear and cliques dissolve. Members begin to identify with one another and the level of trust in their personal relationships contributes to the development of group cohesion. The team begins to experience a sense of group belonging and a feeling of relief from resolving interpersonal conflicts. Team identity starts to take hold and innovation and creativity within the team increases. The members feel an openness and cohesion on both a personal and task level. They feel good about being part of the team.
The final stage, preforming, is not achieved by all teams. This stage is marked by an interdependence in personal relations and problem solving within the realm of the team’s tasks. Team members share a common goal, understand the plan to achieve it, know their roles and how to work together. The team is firing on all cylinders. At this point, the team is highly productive and collaborates well. They are trusting of each other and “have each other’s back.” Healthy conflict is encouraged. There is unity: group identity is complete, group morale is high, and group loyalty is intense.
Not all teams get to this phase. They can get stuck in a previous phase or slide back into them from a higher phase. Leadership that focuses on affective conflict resolution, team identity creation, a compelling vision and goals to achieve that vision is critical to reaching the Performing phase. It is usually not easy for teams to quickly progress through these stages, and it often takes 6 months or more for a team to reach the Performing phase.
Impact to Agile Development
We often see companies make the mistake of coalescing teams around initiatives. Sometimes called “virtual teams” or “matrixed teams”, these teams suffer the underperforming phases of Tuckman’s curve repeatedly, especially when these initiatives are of durations shorter than 6 months. But even with durations of a year, six months of that time is spent getting the team to an optimum level of performance.
Tuckman’s analysis indicates that teams should be together for no less than a year (giving a 6 month return on a 6-month investment) and ideally for about 3 years. The upper limit being informed by the research on group think and its implications to creativity, performance and innovation within teams. Teams then should become semi-permanent and we should seek to move work to teams rather than form teams around work. To be successful here, we need multi-disciplinary teams capable of handling all the work they may get assigned. Further, the team needs to be familiar and “own” the outcomes associated with the solution (or architectural components) with which they work. More on that in future articles discussing Conway’s Law and Empathy Groups.
AKF Partners helps companies understand and apply the extant theory around organizational development in order to turbo-charge engineering performance. Wondering if your engineering productivity decreases as you grow your engineering and product teams? We can help you fix that and get your productivity back to the level it was as a startup!
Reach out to AKF
Subscribe to the AKF Newsletter
What Google Got Right and Wrong with Firing James Damore
August 9, 2017 | Posted By: Marty Abbott
We have a saying in AKF Partners that “an incident is a terrible thing to waste”. When things go poorly in a firm, stakeholders (shareholders, partners, employees) pay a price. Having already paid a price, the firm must maximize the learning opportunity the incident presents. Google wasted such a learning opportunity by failing to capitalize on an incredible teaching moment with the termination of James Damore (the author of the sometimes called “Anti-Diversity Manifesto”). While Google seems to have “done the right thing” by firing Damore, it is unclear that they “did it for the right reason”. The “right reason” here is that diversity is valuable to a company because it increases innovation and in so doing increases the probability of success. Further, diversity is hard to achieve, takes great effort and can easily be derailed with very little effort. Companies simply cannot allow employees to work at odds with incredibly valuable diversity initiatives.
Diversity Drives Innovation and Success
My doctoral dissertation journey introduced me to diversity and its beneficial effects on innovation, time to market, and success within technology product firms. Put simply, teams that are intentionally organized to highlight both inherent (traits with which we are born) and acquired (traits we gain from experience) diversity achieve higher levels of innovation. Research published in the Harvard Business Review confirms this, indicating that diverse teams out innovate and out-perform other teams. Diverse teams are more likely to understand the broad base of needs of the market and clients they support. Companies with very diverse management teams are 35% more likely to have financial returns above the mean for their industry. Firms with women on their board on average have a higher ROE and net income than those that do not.
Differences in perspective and skills are things we should all strive to have in our teams. As we point out in The Art of Scalability, these differences increase beneficial cognitive conflict. Increases in cognitive conflict opens a range of strategic possibilities that in turn engender higher levels of success for the firm.
We have for too long allowed the struggle for diversity to be waged on the battleground of “fairness”. The problem with “fair” is that what is “fair’ to one person may seem inherently unfair to another. “Fair” is subjective and “fair” is too often political. “Success” on the other hand is objective and easily measured. Let’s move this fight to where it belongs and embrace diversity because it drives innovation and success. After all, anyone who can’t get behind winning, doesn’t deserve to be on a winning team.
Achieving Diversity is Hard
While the value of diversity is high, the cost to achieve it is also unfortunately high – especially within software teams. As my colleague Robin McGlothin recently wrote, the percentage of computer science degrees awarded to women over the last 25 years is declining. Most other minorities are similarly underrepresented in the field relative to their corresponding representation in the US population.
As in any market with high demand and low supply, companies need to find innovative ways to attract, grow and retain talent. These activities may include special mentoring programs, training programs, or scholarships at local universities meant to attract the group in question. These approaches may seem “unfair” to some, but they are in truth capitalism at its best - the application of market forces to solve a supply and demand problem. When a skill or trait is under high demand and short supply, the cost for that skill goes up. The extra activities above are nothing more than an increased cost to attract and retain the skills we value.
Companies desiring to achieve success in innovation through diversity MUST approach it in a steely, single-minded fashion. Any dissent as it relates to outcomes detracts from the probability of success. How many people with diverse backgrounds will leave or have left Google because of Damore’s missive? How many candidates won’t accept offers? Losing even one great candidate is an unacceptable additional cost given the already high cost to achieve success.
The Bottom Line
Structuring organizations and building cultures that tap the power of inherent and acquired diversity pays huge dividends for firms in terms of innovation, time to market, ROE and net income. While the rewards are high, the cost to achieve these benefits are also high. Success requires a steely, single-minded pursuit of diversity excellence.
The successful company will allow no dissent on this topic, as dissent makes the firm less attractive to the ideal candidate. Given a constrained supply under high demand, the candidate can and should go to the most welcoming environment available.
Put simply, Google did the right thing in firing Damore. But they failed to fully capitalize on the unfortunate event. The right answer, when asked about the reason for firing, would look something like this: “We recognize that diversity in experiences, background, gender and race drives higher levels of innovation and greater levels of success. Our culture will not tolerate employees who are not aligned with creating stakeholder value.”
Interested in driving innovation and time to market in your product and engineering teams? AKF Partners helps companies create experientially diverse product teams aligned with business outcomes to help turbo-charge performance and team innovation.
Subscribe to the AKF Newsletter
The Dunning-Kruger Effect in Tech
August 1, 2017 | Posted By: Dave Swenson
We all suffer from various cognitive biases, those mental filters or lenses that alter or warp the reality around us. With the election of 2016, one particular bias has gained widespread attention - the Dunning-Kruger Effect. Defined in wikipedia as:
“...a cognitive bias, wherein persons of low ability suffer from illusory superiority when they mistakenly assess their cognitive ability as greater than it is.”
(If you’ve ever wondered about the behind-the-scenes process of creating Wikipedia content, look at this entertaining discussion.)
In 1999, while a professor at Cornell, David Dunning joined Justin Kruger to co-author a paper titled “Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments”, based on studies indicating that people who are incompetent in an area are typically too incompetent to know they are incompetent. Or, simply put, we are often in a position where we don’t know what we don’t know, and therefore cannot judge our level of expertise in a particular area.
This effect or bias, is also known as the ‘Lake Wobegon effect’, or ‘illusory superiority’, and is closely tied to the Peter Principle. Donald Rumsfeld put it this way:
There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.
And in John Cleese’s words, stupid people do not have the capability to realize how stupid they are.
The story of how Dunning came to posit the D-K Effect is an amusing one. He read about an unusual bank robbery that occurred in Pittsburgh. What was unusual was that the robber, McArthur Wheeler, made absolutely no effort to disguise himself, and in fact, looked and smiled directly into the security cameras. Yet, he was surprised to quickly be arrested, telling authorities “...but I used the juice!”.
Wheeler told the police that they couldn’t arrest him based on the security videos, as wearing lemon juice, he was of course invisible. He had been told coating your face with lemon juice makes you invisible to cameras, perhaps similar to using lemon juice for invisible ink. Wheeler had even gone as far as to test the theory by taking a Polaroid picture of himself after coating his face with the lemon juice, and sure enough, his face didn’t appear in the print. The police never were able to explain this, but likely Wheeler was as incompetent at photography as he was at burglary. Clearly, Wheeler was too incompetent at burglary to know he was incompetent.
So, does Dunning-Kruger exist in the technology world? Absolutely…
Just as a typical driver believes their driving skills are Formula 1 worthy, until they’re on a track getting blown past by an inferior car driven by someone who has far better braking and cornering skills, we all tend to underestimate what is possible. We live in our own bubbles and are comparing our abilities only against those who also reside in our bubbles. Therefore, we don’t know what we don’t know - we don’t know there are far better drivers outside our bubbles.
You may think your organization is at the peak of efficiency, until you bring someone in from a Google, Facebook, Amazon, etc. who reveals what the true peak really can be - what fully Agile processes and cultures can do to reduce time to market, how effective SREs and DevOps can be, how to remain innovative, what continuous delivery can do to, etc.
AKF firmly believes in “Experiential Diversity” to cross-pollinate teams, injecting new DNA into a company or bubble that was grown in a different bubble. We see numerous companies with very static personnel, where the average employee tenure is over 15 years. There have been tremendous changes in the technology world in 15 years, and while reading a book or attending a conference on new processes brings some exposure to the latest and greatest, it isn’t enough. It is incredibly important to continually bring new blood into an organization, and to purposely tap into that diversity of processes, technologies, organizational structures that comes with the new blood.
Other techniques to mitigate the effect of D-K in technology, of eliminating our personal and organizational biases include:
- 360 degree reviews - Dunning himself has said “The road to self-insight runs through other people”. What better way to get feedback than from periodic 360 degree reviews?
- Code reviews - The likelihood that some percentage of your developers suffer from D-K means that you’re dependent upon code reviews to flush out their incompetence. Just make sure you’re not pairing up two D-K developers to perform the review!
- Planning Poker - requiring, in true Agile fashion, a team to estimate a task or project reduces the chance of that D-K estimate from torpedoing your development planning.
- Soliciting advice - the increasing utilization of open source software means there isn’t a vendor, with hopefully solid expertise, to turn to for advice. Instead of solely relying upon your own developer who only knows how to spell say Cassandra, leverage the appropriate OSS community. Just beware that you might not know whether that solicited advice is good advice.
- Proper interviewing - Ensure your interviewing process can weed out “confident idiots”. Consider planting bogus questions to gauge a candidate’s reactions, like Jimmy Kimmel’s “Lie Witness News”. At a minimum, require team interviewing and consensus for new candidates.
In short, Dunning-Kruger is as rampant within the Technology sector as it is anywhere else, if not even more so. Expect it to be present in your organization, and guard against it. Look at it within yourself as well. Who amongst us hasn’t experienced the shock of discovering we’ve failed a test that we actually thought we’d aced? We all have suffered at one time or another from the Dunning-Kruger effect.
Subscribe to the AKF Newsletter
Where have all the Women gone?
July 19, 2017 | Posted By: Robin McGlothin
We hear every day that more and more jobs are disappearing, yet the technology job sector cannot keep up with the unprecedented demand. So why are women falling behind in this growing career track?
When we look at the percentage of STEM bachelor’s degrees awarded to female students for the last two decades, based on NSF statistics, we find there are no gender difference in the bio sciences, the social sciences, or mathematics, and not much of a difference in the physical sciences. Great news for women scientists. The only STEM fields in which men genuinely outnumber women are computer science and engineering. What? Why the stagnant numbers in computer science?
At the PhD. level, women have clearly achieved equity in the bio sciences and social sciences, are nearly there (40 percent) in mathematics and the physical sciences, and are “over-represented” in psychology (78 percent). More good news. Again, the only fields in which men greatly outnumber women are computer science and engineering. Why no growth?
As I started my research for this blog post, I was pleasantly surprised to find women scientist representation growing in almost all aspects of STEM. And at the same time, disheartened to find my major, computer sciences, is stagnate in growth for women over the past two decades.
What’s different in the computer science & engineering aspects of STEM that seem to hold women back? There are many conflicting reports on how our environment and upbringing are sublimely programming women away from engineering and mathematics. We were told from an early age, math and science are for boys.
My mother was a pioneer and a strong female leader. She holds a PHD in Biochemistry, served as President for Academic Affairs and Provost at Salem International University. She demanded her daughters rise to any challenge and deliver to the best of our abilities. Never once did I doubt I had amazing talents and just needed to get busy using them. So, is it nature or nurture that helped me stay with STEM? Maybe a little of both.
I saw an article recently in the WSJ on Salesforce.com, where CEO Mark Benioff, is focused on ensuring women are represented fairly at every level in his company. Taking proactive steps like SFDC.com, to open doors for women, rings truer to me then the “poor little girl” theories on how to increase female participation in computer science and engineering.
The cloud-computing giant is two years into a companywide “women’s surge” in which managers must consider women when filling open positions at every level. They are also examining salaries for every role in the company to ensure women and men are paid equally. And finally, ensuring that women make up at least 30% of attendees at management summits or onstage roles at keynote presentations.
With some nurturing at home during early years of development and progress in the corporate landscape leveling the playing field, I believe we are finally set to see an upward trajectory for the last two laggard categories in STEM.
Future women engineers can see a world where their hard work and discipline will pay off, a road-map to success if you will. We no longer need to break through the old stereotypes, running faster and jumping higher to be considered half as good as our male counterparts. Instead, there will be fair and equal opportunity for career advancement for women engineers and computer scientists.
I would submit some of the best technology leaders today are women. My personal experience afforded me the opportunity to work with several top female technology executives. One of the best leaders I worked for is a power house that broke all the stereotypes, and worked circles around her male counterparts. As I look back and try to understand what propelled these successful women, they all possess some classic traits that are needed in any leadership role.
Collaboration. Women are skilled collaborators, able to work with all different people. This is an important quality for any professionals, as cross-departmental collaboration is key. Technology impacts every function in modern business, and those most successful will be able to collaborate with all different teams and individuals.
Communication. For many of the same reasons, technologist must also be strong communicators. Communication is an area where many women traditionally excel and it’s an important quality to have. For example, communicating with the sales department may be different from communicating with the IT department. Good technology leaders will be able to speak to everyone.
Perspective. Being able to inspire a team and see the big picture are both equally important. A technology leader must be able to not only collect and analyze data but draw meaningful insights and understand what it means for the company. The ability to holistically view a situation is a competitive differentiation for organizations as well as a positive attribute that many women possess.
In the past, women had to fight a little harder to push through the barriers that have prevented women from entering STEM, but the tide is turning. In today’s new business paradigm, with a strong technology sector jobs forecast, it’s a perfect time for young women to enter computer science and engineering field.
And to help drive this point home, President Donald Trump signed two laws that authorize NASA and the National Science Foundation to encourage women and girls to get into STEM fields. The Inspire Act directs NASA to promote STEM fields to women and girls, and encourage women to pursue careers in aerospace. The law gives NASA three months to present two congressional committees with its plans for getting staff—think astronauts, scientists and engineers—in front of girls studying STEM in elementary and secondary schools. The full name of the law is the Inspiring the Next Space Pioneers, Innovators, Researchers, and Explorers Women Act. The second law is the Promoting Women in Entrepreneurship Act. It authorizes the National Science Foundation to support entrepreneurial programs aimed at women.
The stage has been set – go forth future astronauts, scientist, coder girls! Let’s rock the world.
Subscribe to the AKF Newsletter
April 19, 2017 | Posted By: AKF
AKF Scalability Workshop
Phoenix Feb 7 - 8, 2018!
Register Now for our next workshop!
Our workshop is designed for technology executives who are responsible for delivering highly available and highly scalable technical platforms & products. The principles we share can be applied to large organizations and start-ups alike. Our principles are technology-agnostic – we believe you can successfully scale with almost any technology if key concepts are followed. During our two-day workshop, you’ll participate in sessions that integrate our experience, research, and the work we’ve done with over 450 clients since 2007.
How is the workshop structured?
The workshop is delivered in 14 collaborative sessions over the 2-day event. While a member of the AKF team will lead the discussion in each session, much of the interaction comes from the participants themselves. We keep the session size limited (maximum of 25 attendees) so that each attendee can be an active part of the conversation, share experiences, and ask questions from other executives who have been in your shoes. You’ll leave the workshop with principles, tools, and examples that you can continuously apply to your platform and organization.
Who should attend the workshop?
Our event is designed for current CTOs, VPs of Engineering, Chief Architects, and other technology executives who want to improve their management, leadership, and technology skills. We help companies scale their technology and product platforms. Although nearly any technical organization would benefit from the lessons shared in the workshop, our sessions will provide the most value to companies that use technology to deliver their core product or service (e.g. SaaS, eCommerce).
What topics are covered in the workshop?
• 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.
Who teaches this workshop?
Workshops are delivered by AKF Managing Partner/CEO, Marty Abbott, as well as other members of the AKF team. Marty, together with Mike Fisher and Tom Keeven, helped found AKF Partners nine years ago with the goal of leveraging their successes (and failures!) as technology executives to help other companies prepare for and achieve hyper-growth. To date, AKF has helped over 400 companies across 18 countries make progress towards their scalability goals (including many leaders in the internet industry). Marty and Mike have co-authored three books: “The Art of Scalability”, “Scalability Rules”, and “The Power of Customer Misbehavior.”
What hotel options are in the area?
We are holding the workshop at the Tempe Mission Palms Hotel. It’s busy season in the Phoenix area, so if you plan on staying at the same hotel, we suggest you reserve a room soon!
Tempe Mission Palms Hotel and Conference Center
60 E 5th St, Tempe, AZ 85281
Other area hotel options:
951 E Playa Del Norte Dr, Tempe, AZ 85281
Holiday Inn Express & Suites Phoenix Tempe - University
1031 E Apache Blvd, Tempe, AZ 85281
AC Hotel by Marriott Phoenix Tempe/Downtown
100 E Rio Salado Pkwy, Tempe, AZ 85281
Baymont Inn & Suites Tempe/Scottsdale
808 N Scottsdale Rd, Tempe, AZ 85281
MOXY Phoenix Tempe/ASU
1333 S Rural Rd, Tempe, AZ 85281
Residence Inn by Marriott Tempe Downtown/University
510 S Forest Ave, Tempe, AZ 85281
Courtyard by Marriott Tempe Downtown
601 S Ash Ave, Tempe, AZ 85281
Hyatt Place Tempe/Phoenix Airport
1413 W Rio Salado Pkwy, Tempe, AZ 85281
Register Now for our next workshop!
Subscribe to the AKF Newsletter
AKF Turns 10 – And It’s Still Not About the Tech
March 23, 2017 | Posted By: AKF
The caller ID was blocked but Marty had been expecting the call. Three “highly connected” people – donors, political advisers and “inner circle” people – had suggested AKF could help. It was October 2013 and Healthcare.gov had launched only to crash when users tried to sign up. President Obama appointed Jeffrey Zients to mop up the post launch mess. Once the crisis was over, the Government Accountability Office (GAO) released its postmortem citing inadequate capacity planning, software coding errors, and lack of functionality as root causes. AKF’s analysis was completely different – largely because we think differently than most technologists. While our findings indicated the bottlenecks that kept the site from scaling, we also identified failures in leadership and a dysfunctional organization structure. These latter, and more important, problems prevented the team from identifying and preventing recurring issues.
We haven’t always thought differently. Our early focus in 2007 was to help companies overcome architectural problems related to scale and availability. We’ve helped our clients solve some of the largest and challenging problems ever encountered – cyber Monday ecommerce purchasing, Christmas day gift card redemption, and April 15th tax filings. But shortly after starting our firm, we realized there was something common to our early engagements that created and sometimes turbocharged the technology failures. This realization, that people and processes – NOT TECHNOLOGY– are the causes of most failures led us to think differently. Too often we see technology leaders focusing too much on the technology and not enough on leading, growing, and scaling their teams.
We challenge the notion that technology leaders should be selected and promoted based on their technical acumen. We don’t accept that a technical leader should spend most of her time making the biggest technical decisions. We believe that technical executives, to be successful, must first be a business executive with great technical and business acumen. We teach teams how to analyze and successfully choose the appropriate architecture, organization, and processes to achieve a business outcome. Product effort is meaningless without a measurable and meaningful business outcome and we always put outcomes, not technical “religion” first.
If we can teach a team the “AKF way” the chance of project and business success increases dramatically. This may sound like marketing crap (did we mention we are also irreverent?), but our clients attest to it. This is what Terry Chabrowe, CEO eMarketer, said about us:
AKF served as our CTO for about 8 months and helped us make huge improvements in virtually every area related to IT and engineering. Just as important, they helped us identify the people on our team who could move into leadership positions. The entire AKF team was terrific. We’d never have been able to grow our user base tenfold without them.
A recent post claimed that 93% of successful companies abandon their original strategy. This is certainly true for AKF. Over the past 10 years we’ve massively changed our strategy of how we “help” companies. We’ve also quadrupled our team size, worked with over 350 companies, written three books, and most importantly made some great friendships. Whether you’ve read our books, engaged with our company, or connected with us on social media, thanks for an amazing 10 years. We look forward to the next 10 years, learning, teaching, and changing strategies with you.
Subscribe to the AKF Newsletter
AKF Interim Leadership Case Study
March 21, 2017 | Posted By: AKF
Read about one of our success stories in which we filled an interim CTO role at a marketing subscription company in New York.
AKF Long-term Case Study
Subscribe to the AKF Newsletter