AKF Partners

Abbott, Keeven & Fisher Partners Partners in Technology

Growth Blog

Scalability and Technology Consulting Advice for SaaS and Technology Companies

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.


What Happened??

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

Permalink

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

Permalink

Tuckman’s Stages and Agile Development

November 8, 2017  |  Posted By: AKF

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.

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

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

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

Performing
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

Permalink

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.

 

Subscribe to the AKF Newsletter

Permalink

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

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

Permalink

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

Permalink

Scalability Workshops

April 19, 2017  |  Posted By: AKF

AKF Scalability Workshop
Phoenix Feb 7 - 8, 2018!

Register Now for our next workshop! 

Workshop Overview

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
destinationhotels.com
(480) 894-1400

Other area hotel options:
Aloft Tempe
951 E Playa Del Norte Dr, Tempe, AZ 85281
alofttempe.com
(480) 621-3300

Holiday Inn Express & Suites Phoenix Tempe - University
1031 E Apache Blvd, Tempe, AZ 85281
ihg.com
(480) 966-7202

AC Hotel by Marriott Phoenix Tempe/Downtown
100 E Rio Salado Pkwy, Tempe, AZ 85281
marriott.com
(480) 642-6140

Baymont Inn & Suites Tempe/Scottsdale
808 N Scottsdale Rd, Tempe, AZ 85281
wyndhamhotels.com
(480) 900-3496

MOXY Phoenix Tempe/ASU
1333 S Rural Rd, Tempe, AZ 85281
marriott.com
(480) 968-3451

Residence Inn by Marriott Tempe Downtown/University
510 S Forest Ave, Tempe, AZ 85281
marriott.com

Courtyard by Marriott Tempe Downtown
601 S Ash Ave, Tempe, AZ 85281
marriott.com
(480) 966-2800

Hyatt Place Tempe/Phoenix Airport
1413 W Rio Salado Pkwy, Tempe, AZ 85281
phoenixairport.place.hyatt.com
(480) 804-9544

 

Register Now for our next workshop!

 

Subscribe to the AKF Newsletter

Permalink

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

Permalink