AKF Partners

Abbott, Keeven & Fisher Partners Partners in Growth

Growth Blog

Advice on how to fix broken $#*!

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.



Does Dunning-Kruger, a recently popularized cognitive bias, exist in the Technology world?

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!”.

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.



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. 


Engineering Metrics

April 3, 2017  |  Posted By: AKF

A topic that often results in great debate is “how to measure engineers?” I’m a pretty data driven guy so I’m a fan of metrics as long as they are 1) measured correctly 2) used properly and 3) not taken in isolation. I’ll touch on these issues with metrics later in the post, let’s first discuss a few possible metrics that you might consider using. Three of my favorite are: velocity, efficiency, and cost.

  • Velocity – This is a measurement that comes from the Agile development methodology. Velocity is the aggregate of story points (or any other unit of estimate that you use e.g. ideal days) that engineers on a team complete in a sprint. As we will discuss later, there is no standard good or bad for this metric and it is not intended to be used to compare one engineer to another. This metric should be used to help the engineer get better at estimating, that’s it. No pushing for more story points or comparing one team to another, just use it as feedback to the engineers and team so they can get more predictable in their work.
  • Efficiency – The amount of time a software developer spends doing development related activities (e.g. coding, designing, discussing with the product manager, etc) divided by their total time available (assume 8 – 10 hours per day) provides the Engineering Efficiency. This is a metric designed to see how much time software developers are actually spending on developing software. This metric often surprises people. Achieving 60% or more is exceptional. We often see dev groups below 40% efficiency. This metric is useful for identifying where else engineers are spending their time. Are there too many company meetings not directly related to getting products out the door? Are you doing too many HR training sessions, etc? This metric is really for the management team to then identify what is eating up the nondevelopment time and get rid of it.
  • Cost – Tech cost as a percentage of revenue is a good cost based metric to see how much you are spending on technology. This is very useful as it can be compared to other tech (SaaS or other webbased companies) and you can watch this metric change over time. Most startups begin with their total tech cost (engineers, hosting, etc) at well over 50% of revenue but this should quickly reduce as revenue grows and the business scales. Yes, scaling a business involves growing it cost effectively. Established companies with revenues in the tens of millions range usually have this percentage below 10%. Very large companies in the hundreds of millions in revenue often drive this down to 57%.

Now that we know about some of the most common metrics, how should they be used? The most common way managers and executives want to use metrics is to compare engineers to each other or compare a team over time. This works for the Efficiency and the Cost metrics, which by the way are primarily measurements of management effectiveness. Managers make most of the cost decisions including staffing, vendor contracts, etc. so they should be on the hook to improve these metrics. In terms of product out the door as measured by story points completed each sprint a.k.a. Velocity, as mentioned above, is to be used to improve estimates, not try to speed up developers. Using this metric incorrectly will just result in bloated estimates, not faster development.

An interesting comparison of developers comes from a 1967 article by Grant and Sackman in which they stated a ratio of 28:1 for the time required by the slowest versus the fastest programmer to complete a task. This has been a widely cited ratio but a paper from 2000 revised this number to 4:1 at the most and more likely 2:1. While a 2x difference in speed is still impressive it doesn’t optimize for the overall quality of the product. An engineer who is very fast and with high quality but doesn’t interact with the product managers isn’t necessarily the overall most effective. My point is that there are many other factors to be considered than just story points per release when comparing engineers.



April 3, 2017  |  Posted By: AKF

As a frequent technology writer I often find myself referring to the method or process that teams use to produce software. The two terms that are usually given for this are software development life cycle (SDLC) and product development life cycle (PDLC). The question that I have is are these really interchangeable? I don’t think so and here’s why.

Wikipedia, our collective intelligence, doesn’t have an entry for PDLC, but explains that the product life cycle has to do with the life of a product in the market and involves many professional disciplines. According to this definition the stages include market introduction, growth, mature, and saturation. This really isn’t the PDLC that I’m interested in. Under new product development (NDP) we find a defintion more akin to PDLC that includes the complete process of bringing a new product to market and includes the following steps: idea generation, idea screening, concept development, business analysis, beta testing, technical implementation, commercialization, and pricing.

Under SDLC, Wikipedia doesn’t let us down and explains it as a structure imposed on the development of software products. In the article are references to multiple different models including the classic waterfall as well as agile, RAD, and Scrum and others.

In my mind the PDLC is the overarching process of product development that includes the business units. The SDLC is the specific steps within the PDLC that are completed by the technical organization (product managers included). An image on HBSC’s site that doesn’t seem to have any accompanying explanation depicts this very well graphically.

Another way to explain the way I think of them is to me all professional software projects are products but not all product development includes software development.  See the Venn diagram below. The upfront (bus analysis, competitive analysis, etc) and back end work (infrastructure, support, depreciation, etc) are part of the PDLC and are essential to get the software project created in the SDLC out the door successfully.  There are non-software related products that still require a PDLC to develop.

Do you use them interchangeably?  What do you think the differences are?