GROWTH BLOG: Learning from Failure: Conducting Postmortems
AKF Partners Logo Technology ConsultingScalability - We wrote the book on it ℠

Growth Blog

Scalability and Technology Consulting Advice for SaaS and Technology Companies

Top 3 Failures in Digital Transformations

July 11, 2019  |  Posted By: Marty Abbott

Attempting to transform a company to compete effectively in the Digital Economy is difficult to say the least.  In the experience of AKF Partners, it is easier to be “born digital” than to transform a successful, long tenured business, to compete effectively in the Digital age. 

There is no single guaranteed fail-safe path to transformation.  There are, however, 10 principles by which you should abide and 3 guaranteed paths to failure. 

Avoid these 3 common mistakes at all costs or suffer a failed transformation.

Top 3 Digital Transformation Failures

Having the Wrong Team and the Wrong Structure

If you have a successful business, you very likely have a very bright and engaged team.  But unless a good portion of your existing team has run a successful “born digital” business, or better yet transformed a business in the digital age, they don’t have the experience necessary to complete your transformation in the timeframe necessary for you to compete.  If you needed lifesaving surgery, you wouldn’t bet your life on a doctor learning “on the job”.  At the very least, you’d ensure that doctor was alongside a veteran and more than likely you would find a doctor with a successful track record of the surgery in question.  You should take the same approach with your transformation.

This does not mean that you need to completely replace your team.  Companies have been successful with organization strategies that include augmenting the current team with veterans.  But you need new, experienced help, as employees on your team. 

Further, to meet the need for speed of the new digital world, you need to think differently about how you organize.  The best, fastest performing Digital teams organize themselves around the outcomes they hope to achieve, not the functions that they perform.  High performing digital teams are

It also helps to hire a firm that has helped guide companies through a transformation.  AKF Partners can help. 

Planning Instead of Doing

The digital world is ever evolving.  Plans that you make today will be incorrect within 6 months.  In the digital world, no plan survives first contact with the enemy.  In the old days of packaged software and brick and mortar retail, we had to put great effort into planning to reduce the risk associated with being incorrect after rather long lead times to project completion.  In the new world, we can iterate nearly at the speed of thought.  Whereas being incorrect in the old world may have meant project failure, in the new world we strive to be incorrect early such that we can iterate and make the final solution correct with respect to the needs of the market.  Speed kills the enemy.

Eschew waterfall models, prescriptive financial models and static planning in favor of Agile methodologies, near term adaptive financial plans and OKRs.  Spend 5 percent of your time planning and 95% of your time doing.  While in the doing phase, learn to adapt quickly to failures and quickly adjust your approach to market feedback and available data. 

The successful transformation starts with a compelling vision that is outcome based, followed by a clear near-term path of multiple small steps.  The remainder of the path is unclear as we want the results of our first few steps to inform what we should do in the next iteration of steps to our final outcome.  Transformation isn’t one large investment, but a series of small investments, each having a measurable return to the business.

Knowing Instead of Discovering

Few companies thrive by repeatedly being smarter than the market.  In fact, the opposite is true – the Digital landscape is strewn with the corpses of companies whose hubris prevented them from developing the real time feedback mechanisms necessary to sense and respond to changing market dynamics.  Yesterdays approaches to success at best have diminishing returns today and at worst put you at a competitive disadvantage.

Begin your journey as a campaign of exploration.  You are finding the best path to success, and you will do it by ensuring that every solution you deploy is instrumented with sensors that help you identify the efficacy of the solution in real time.  Real time data allows us to inductively identify patterns that form specific hypothesis.  We then deductively test these hypotheses through comparatively low-cost solutions, the results of which help inform further induction.  This circle of induction and deduction propels us through our journey to success.

Subscribe to the AKF Newsletter

Contact Us

If You Are Not Measuring, You Are Not Managing

July 10, 2019  |  Posted By: Bill Armelin

image of hands holding a caliper with the word goals in between

We are surprised at how often we go into a client and find that management does not have any metrics for their teams. The managers respond that they don’t want to negatively affect the team’s autonomy or that they trust the team to do the right things. While trusting your teams is a good thing, how do you know what they are doing is right for the company? How can you compare one team to another? How do you know where to focus on improvements?

Recently, we wrote an article about team autonomy, discussing how an empowered team is autonomous within a set of constraints. The article creates an analogy to driving a car, with the driver required to reach a specific destination, but empowered to determine WHAT path to take and WHY she takes it. She has gauges, such as a speedometer to give feedback on whether she is going too fast or too slow. Imagine driving a car without a speedometer. You will never know if you are sticking to the standard (the speed limit) or when you will get to where you need to go (velocity).

As a manager, it is your responsibility to set the appropriate metrics to help your teams navigate through the path to building your product. How can you hold your teams to certain goals or standards if you can’t tell them where they are in relation to the goal or standard today? How do you know if the actions you are taking are creating or improving shareholder value?

What metrics do you set for your teams? It is an important question. Years ago, while working at a Big 6 consulting firm, I had the pleasure of working with a very astute senior manager. We were redesigning manufacturing floors into what became Lean Manufacturing. He would walk into a client and ask them what the key metrics were. He would then proceed to tell them what their key issues were. He was always right. With metrics, you get what you measure. If you align the correct metrics with key company goals, then all is great. If you misalign them, you end up with poor performance and questionable behaviors.

So, what are the right metrics for a technology team? In 2017, we published an article on what we believe are the engineering metrics by which you should measure your teams. Some of the common metrics we focused on were velocity, efficiency, and cost. At initial glance, you might think that these seem “big brother-ish.” But, in reality, these metrics will provide your engineering teams with critical feedback to how they are doing. Velocity helps a team identify structural defects within the team (and should not be used to compare against other teams or push them to get more done). Efficiency helps the teams identify where they are losing precious development time to less valuable activities, such as meetings, interviews and HR training. It helps them and their managers quantify the impact of non-development and reduce such activities.

Cost helps the team identify how much they are spending on technology. We have seen this metric particularly used effectively in companies deploying to the cloud. Many companies allow cloud spending to significantly and uncontrollably increase as they grow. Looking at costs exposes things like the need for autoscaling to reduce the number of instances required during off peak times, or to purge unused instances that should be shut down.

The key to avoiding metrics from being perceived as overbearing is to keep them transparent. The teams must understand the purpose of the metric and how it is calculated. Don’t use them punitively. Use them to help the teams understand how they are doing in relation to the larger goals. How do you align the higher-level company goals to the work you teams are performing? We like to use Objectives and Key Results, or OKRs. This concept was created by Andy Grove at Intel and brought to Google by John Doerr. The framework aims to align higher level “objectives” to measurable “key results.” An objective at one level has several key results. These key results become the objectives for the next level down and defines another set of key results at that level. This continues all the way down to the lowest levels of the company resulting in alignment of key results and objectives across the entire company.

Choosing the Right Metric

Metrics-driven institutions demonstrably outperform those that rely on intuition or “gut feel.” This stated, poorly chosen metrics or simply too many metrics may hinder performance.

  1. A handful of carefully chosen metrics. Choose a small number of key metrics over a large volume. Ideally, each Agile team should be evaluated/tasked with improving 2-3 metrics (no more than 5). (Of note, in numerous psychological studies, the quality of decision-making has actual been shown to decrease when too much information is presented).
  2. Easy to collect and or calculate. A metric such as “Number of Customer Service Tickets per Week” although crude, is better than “Engineer Hours spent fixing service” as it requires costly time/effort to collect.
  3. Directly Controllable by the Team. Assigning a metric such as “Speed and Accuracy of Search” to a Search Service is preferred to “Overall Revenue” which is less directly controllable.
  4. Reflect the Quality of Service. The number of abandoned shopping carts reflects the quality of a Shopping Cart service, whereas number of shopping cart views is not necessarily reflective of service quality.
  5. Difficult to Game. The innate human tendency to game any system should be held in check by selecting the right metrics. Simple velocity measures are easily gamed while the number of Sev 1 incidents cannot be easily gamed.
  6. Near Real Time Feedback. Metrics that can be collected and presented over short-time intervals are most desirable. Information is most valuable when fresh — Availability week over week is better than a yearly availability measure.

Managers are responsible for the performance of their teams in relation to the company’s objectives and how they create shareholder value. Measuring how your teams are performing against or their contribution to those goals is only speculation if you don’t have the correct measurements and metrics in place. The bottom line is, “If you are not measuring, you are not managing.”

Are you having difficult defining the right metrics for your teams? Are you interested in defining OKRs but don’t know where or how to get started? AKF has helped many companies identify and implement key metrics, as well as implementing OKRs.  We have over 200 years of combined experience helping companies ensure their organizations, processes, and architecture are aligned to the outcomes they desire. Contact us, we can help.

Subscribe to the AKF Newsletter

Contact Us

Technology Consulting Services: Key Differences between Due Diligence for IT and Due Diligence for Product Technology

June 28, 2019  |  Posted By: Roger Andelin

Due Diligence Header for AKF Growth Blog
The two most common types of technology due diligence requests we see at AKF are

  • Product Technology Due Diligence
  • Information Technology, or IT, Due Diligence.

Both types are very different from each other, but often get confused. This article will explain the differences between Product Technology and
Information Technology – and why understanding the difference is critical to a company’s success and profitability.

IT Department

An IT department is typically led by a Chief Information Officer (CIO). The focus of the CIO is on information technology that supports the ongoing operations of the business. The CIO and the IT team’s key outcomes are typically around employee productivity and efficiency, applying technology to improve productivity and to lower costs. This includes technologies that run the financial and accounting systems, sales and operations systems, customer support systems,  and the networks, servers, and storage underlying these systems. The CIO is also responsible for the technologies that are used in the office such as email, chat, video conferencing systems, printers, and employees’ desktop computers.

Product Technology

Conversely, Product Technology (or Digital Product Technology) is typically led by a Chief Technology Officer (CTO). The focus of the CTO is building a product or service for customers out of software and running that product or service on cloud systems or company-owned systems, although the latter is becoming less common. Put another way, CTOs build and run software as revenue generating products and services

Whereas the CIO runs a cost center and is responsible for employee productivity, the CTO is responsible for revenue and cash-flow. Sales growth, time to market, costs of goods sold, and R&D spend are some of the factors included within key outcomes for the CTO.

For example, if you were running a newspaper business, your primary product is the news. However, you also must build applications to read news like mobile apps and web apps. It is the job of your CTO to build, maintain, and run these apps for your customers. Your CTO would be accountable for business metrics – such as the number of downloads, users, and revenue. If your CTO is distracted by CIO issues of running the day-to-day business of the office, they are being taken away from their work to build and implement the revenue generating products and services your company is trying to create.

Differences

Product Technologies and IT Technologies are very different. CIOs and CTOs have very different skills and competencies to manage these differences. For example, a CIO often possesses deep knowledge of back-office applications such as accounting systems, finance systems, and warehouse management systems. In many cases they likely rose up through the technology ranks writing, maintaining, and running those systems for other departments in the company. They are excellent at business analysis, collecting requirements from company users and translating those requirements into project plans. CIOs are often proficient at waterfall development methodologies often used to implement back-office applications.

The IT team is often largely staffed with people who know how to integrate and configure third-party products, with a small amount of custom development. The opposite is true for most product technology teams typically staffed with software engineers who are building new solutions and a smaller number of engineers integrating infrastructure components.

CTOs possess entirely different technology skills needed to build and maintain software as a service (SaaS) for the company’s customers. CTOs possess the skills to architect software applications that are scalable as the company grows its customer base. The AKF Scale Cube is an invaluable reference tool for the CTO building a scalable software solution based on scalable microservices. CTOs must have the skills to run product teams, including user experience design, along with software development. CTOs are more likely to be proficient in Agile development methodologies, such as Scrum. CTOs are expected to know the product development lifecycle (PDLC), mitigate technical debt liability, and know how to build software release pipelines to support continuous integration and delivery(CI/CD).

What We See In The Wild

Regularly, when AKF is called to perform technology due diligence, we often find that Product and IT are combined!  This has been especially true for older, established companies, with traditional IT departments. CIOs took on the responsibility of building and running customer-facing internet and mobile software products and services rather than creating a separate Product Development Team under a CTO. The results are often not positive because the technical, product, and process skills are very different between the two.

This mistake is not exclusive to older companies. We see startup CEO’s making the same mistake, often under the rationale of reducing burn. However, when a startup CEO looks to the CTO to help set up new employees’ desktop computers or to fix a problem with email, it is a huge distraction for the CTO who should be focused on building and improving the company’s revenue-generating products.

AKF Recommendations

AKF recommends that CEOs not combine Product Development and IT departments. Understanding this distinction and why these two very different departments need to function separately is critically important.  Our primary expertise at AKF is to help successful companies become more successful at delivering digital products. AKF focuses its expertise on helping product development teams succeed. We have developed intellectual property, including the AKF Scale Cube, used to evaluate product architecture and to guide successful product development teams. 

We also help CEOs, CTOs, CIOs and IT departments who are looking to improve performance and deliver more business value by creating efficient product development processes and architectures. Give us a call, we can help!

Subscribe to the AKF Newsletter

Contact Us

Results and Outcomes – Why Companies Fail

April 21, 2019  |  Posted By: Pete Ferguson

picture of woman looking at iPad with graphs and reports

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: 

Observation:

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.

Outcomes:

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

Observation:

Ongoing cost cutting to “make the quarter.”

Outcomes:

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

Observation:

Focusing efforts on Sales Department’s latest contract.

Outcomes:

  • 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)

Observation:

Focus is on mergers and acquisitions instead of core strengths and products.

Outcomes:

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

Conclusions

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

Contact Us

The AKF Difference

December 4, 2018  |  Posted By: Marty Abbott

akf difference

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

Contact Us

Diagnosing and Fixing Software Development Performance

November 20, 2018  |  Posted By: Roger Andelin

Two software developers at a desk computer

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:

AKF Partners Velocity plus Business Value equals 10 xers which are high performers

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:

  1. Teams are spending extra time in planning meetings to refine requirements and evaluating effort.
  2. Team members are being interrupted by customer incidents which they are required to support.
  3. The team must support the weekly release process in addition to their other engineering tasks.
  4. 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

Contact Us

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

Contact Us

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

Contact Us

SaaS Risk and Value Shift

August 2, 2018  |  Posted By: Marty Abbott

Hand illustration of different risks
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.

Risk and Cost Shift Inherent to SaaS Transitions

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. 

Cost Models of Various Cloud Implementations

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.

Cloud Cost Models - Operating Expense and Cost of Goods Sold

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

Contact Us

The Phases of SaaS Grief

July 24, 2018  |  Posted By: Marty Abbott

frustrated guy at a computer Photo by Tim Gouw from Pexels
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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Risk shift from on premise to SaaS products

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. 


Summary
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:

  1. 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.
  2. Ensuring that everyone understands the cost of failure, helping to instill some small level in fear that should help drive cultural change.
  3. Ensuring that a known villain or competitor exists, against which we are competing to help boost performance and speed of transition.
  4. 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

Contact Us

 1 2 3 > 

Categories:

Most Popular: