AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Category » Leadership and Management

Product Discovery (the Right Way)

Product Discovery: Sales Driven vs. Market Driven

Product discovery is a core process to any successful software company. While your engineers need to focus on building the product right (making it highly scalable and available), your product owners need to ensure they’re building the right product.

All too often, we find product owners serving essentially as “ticket takers” that run requests from sales to engineering. While the product owners may add a little design and elaboration, the ideas originate solely from the “asks” of the sales department. This “sales-driven” approach is limiting. It tends to stifle innovation and frequently allocates engineering effort to one-off features requested by a single customer. Overall, it is indicative of an immature product management process.

In contrast, mature product organizations take a “market-driven” approach, receive input from a variety of sources, and focus engineering efforts on penetrating new market segments. These differences translate into measurable business outcomes. Market-driven companies (e.g. Salesforce, Apple, Amazon, WorkDay) are routinely valued at 10-15 times revenue, while sales-driven companies (e.g. Dell, Samsung, Oracle, SAP, Rackspace, WalMart.com) typically trade for only 1.5-6 times revenue.

Highlighting the differences of these two approaches will demonstrate how organizations focused on innovation and faster time to market are better served by a market-driven approach.

Sales Led Product Discovery

In a sales-driven product organization, the product ideation process begins with sales obtaining feedback from customers (or potential customers) on desired features and functionality. These requests are then translated into requirements and added to the product backlog. Prioritization — if it occurs at all — is based on the size of the contract and/or relative importance of the customer. The process itself is simple and straightforward, but unfortunately it often leads to poor outcomes.

Frequently, features not yet implemented are promised and assigned deadlines as part of the sales contract. These binding commitments tie the hands of product and engineering anywhere from several weeks to months, forcing them on a treadmill that never quite allows enough breathing room to experiment with innovative features or new products. It becomes impossible for the product organization to pivot without months of lead time or executive intervention.

Additionally, the particular needs of each customer lead them to request features and functionality that only they will use. Product evolution therefore becomes haphazard, with the engineering team jumping from one custom feature to the next.

Furthermore, these feature commitments are often granted in an all or nothing approach with highly articulated use cases. A consequence is that releases to production are infrequent, perhaps quarterly or less, making it difficult to acquire feedback from the larger customer base. Few releases result in less feedback from customers overall and fewer opportunities to pivot away from a poorly chosen feature set.

Consequently, the product itself becomes bloated with a large number of features that one or maybe two customers use and these one-off features add complexity both to the interface (making it difficult to use) and to the code (making it difficult to maintain). This over development makes the product unsatisfying to use and a drain on engineering resources to maintain.

The bottom-line is sales-driven products simply lack vision. Your sales department (quite rightly) is too focused on selling and your customers (quite naturally) are too focused on solving the business problems of today to steer the future vision of your product. The limitations of sales driven approaches are best summarized by the old Henry Ford quote “If I asked my customers what they wanted, it would have been a faster horse.”

Market Led Product Discovery

If a sales-driven approach is a dead end, what is the alternative?

In a market-driven approach, product ideas aren’t limited to sales and customer asks but come from a variety of sources (e.g. charter customer feedback, actual usage metrics, customer service, engineering, sales, executive team). This generates a surplus of ideas — the majority of which, the product owners will have to say “no” to. In fact, the most important function of product owners is to say “no” to ideas that will divert engineering effort away from creating maximum value.

When a new product is launched, an MVP concept is prototyped and tested among a small set of charter customers. Prototypes (interactive mockups) are created with tools like Balsamiq, Axure, etc. and iterated over multiple times, allowing a huge number of ideas to be tested and refined with almost no coding. This process also identifies the minimum feature set required to solve a problem in a particular market segment, thereby minimizing the engineering effort required to implement it.

Once in production, these MVPs are enhanced by further feature development. However, features aren’t selected to satisfy the needs of individual customers but to meet the collective needs of the market segment (i.e. Keep the aggregate customer mostly happy). Features themselves are initially released in minimum viable fashion and further articulated in later releases, allowing for a frequent release schedule and ready feedback from the customer base. Overall, this strategy avoids over-development while capturing as much of the market segment as possible. Specific customer one-off product needs can be pushed to a professional services group (internally or externally) and built as add-ons through a mechanism like an API framework, but not incorporated into the core product.

Once the current market segment has been saturated, focus shifts to conquering another market segment. This is the expansion strategy advocated by Geoffery Moore in Crossing the Chasm: “[target] a very specific niche market where you can dominate from the outset, drive your competitors out of that market niche, and then use it as a base for broader operations.”[1]

In contrast to the sales-driven approach above, this expansion is a deliberate process. Market research is conducted to identify the needs of these new customers. In some cases this means adding a collection of features to the existing product, but often it requires the launch of an entirely new product. Again, the use of extensive prototyping and feedback from charter customers play a key role.

This quick advance – prenetrating and saturating market segments in rapid succession – explains the stark differences in investor valuations between market-driven (10-15x Rev) and sales-driven (1.5-6x Rev) companies.

Conclusion

While more complex, the market-driven product discovery process helps your business focus on long-term growth vs. near-term individual customer wins. It draws upon a variety of sources for ideas, allows for early testing and feedback (for both MVP products and features), minimizes wasted engineering effort, and opens new market segments quicker than sales-driven approaches.

Many of our product management ideas are influenced by Marty Cagan at the SVPG. Click here to visit his website and learn more.

[1] Moore, Geoffrey A. (2014-01-28). Crossing the Chasm, 3rd Edition (Collins Business Essentials) (p. 79). HarperCollins. Kindle Edition.

Comments Off on Product Discovery (the Right Way)

Selecting Metrics for Your Agile Teams

One of our favorite sayings is “you can’t improve that which you do not measure.” When working with clients, we often emphasize the need to select and track performance metrics. It’s quite surprising (disheartening really) to see how many companies are limping along with decision-making based entirely on intuition. Metrics-driven institutions demonstrably outperform those that rely on “gut feel” and are able to quickly refocus efforts on projects that offer the greatest ROI.

Just as your top-level business KPIs govern strategic decision making, your agile teams (and their respective services) need their own “tactical” metrics to focus efforts, guide decision making, and make performance measurable. The purpose of agile development is to deliver high quality value to your customers in an iterative fashion. Agile facilitates rapid deployment, but also allows you to garner feedback from your customers that will shape the product. Absent a set of KPIs, you will never truly understand the effectiveness of your process. Getting it right, however, isn’t an easy task. Poorly chosen metrics won’t reflect the quality of service, will be easily gamed, or difficult to track, and may result in distorted incentives or undesirable outcomes.

In contrast, well-chosen metrics make it simple to track to performance and shape team incentives. For example, a search service could be graded against the speed and accuracy of search results while the shopping cart service is measured on the percentage of abandoned shopping carts. These metrics are simple, easy to track, difficult to game, and directly reflect the quality of service.

Be sure to dedicate the time and the mental energy needed to pick the right metrics. Feedback from team members is essential but the final selection isn’t something you can delegate. After all, If I’m allowed to pick my own performance metrics — I can assure you I’m always going to look awesome.

To keep you on the right track, below is a checklist of considerations to take into account before finalizing the selection of metrics for your agile teams:

  1. A handful of carefully chosen metrics should be preferred over a large volume of metrics. Ideally, each Agile team (and respective service) should be evaluated/tasked with improving 2-3 metrics (no more than 5). We have witnessed at least one company that proposed a total of 20 different metrics to measure an agile teams performance! Needless to say, being graded on that many metrics is disempowering at best, and likely to illicit either a panic attack or total apathy from your team. In contrast, having only a handful metrics to be graded against is empowering and helps to focus efforts.
  2. Easy to collect and or calculate. One startup suggested they would track “Engineering Hours Spent Bug-Fixing” as a way to determine code quality. The issue was quickly raised: Who would be doing this tracking? And how much time/effort did they estimate it would take?  It became obvious that tracking the exact amount of time spent would add a heavy productivity-tax to an already burdened engineering team.  While providing a very granular measure, the cost of collecting this information simply outweighed the benefits.  Ultimately we helped them decide that the “Number of Customer Service Tickets per Week” was the right metric. Sometimes a cruder measure is the right choice, especially if it is easier to collect and act upon.
  3. Directly Controllable by the Team. Choose metrics that your agile team has more or less direct control over. A metric they contribute towards indirectly is less empowering than something they know they own. For example, when measuring a search service the “Speed and Accuracy of Search” is preferable to “Overall Revenue” which the team only indirectly controls.
  4. Reflect the Quality of Service. Be sure to pick metrics that reflect the quality of that service. For instance, the number of abandoned shopping carts reflects the quality of a shopping cart service, whereas number of shopping cart views is an input metric but doesn’t necessarily reflect service quality.
  5. Difficult to Game. The innate human tendency to game any system should be held in check by selecting metrics that can’t easily be gamed. Simple velocity measures are easily (read: notoriously) gamed while the number of “Severity 1” incidents your service invoked can’t be so easily massaged.
  6. Near Real Time Feedback. Metrics than can be collected and presented over short-time intervals are the most actionable. Information is more valuable when fresh — providing availability data weekly (or even daily) will foster better results than a year-end update.

Most importantly, well-chosen metrics tracked regularly should pervade all aspects and all levels of your business. If you want your business to become a lean, performance driven machine, you need to step on the scale every day. It can often be uncomfortable, but it’s necessary to get the returns of which you are capable.


Comments Off on Selecting Metrics for Your Agile Teams

Building Scalable Organizations

Embedded below is a presentation on building scalable organizations. The presentation walks through our model of innovation detailing how factors such as cognitive conflict, affective conflict, and a sense of empowerment impact a company’s ability to be innovative. The slides then depict how in most functional based organizations there is conflict when trying to deliver a service such as a SaaS product offering. The remainder of the presentation focuses on how to fix this with some real world examples of companies that have reorganized to focus on improving innovation.



Comments Off on Building Scalable Organizations

A-Teams

In his book, The Lean Start-Up, Eric Ries defines a start-up as a “human institution designed to deliver a new product or service under conditions of extreme uncertainty.” Operating in uncertainty is inherently risky. What makes many start-ups successful, among other things, is their ability to mitigate risk. One way a company can remain adaptive and responsive during uncertainty, and therefore reduce risk, is employing an agile development model. A good example of such an organization is Spotify, which continues to embrace, practice, and improve on agile fundamentals even after growing to over 30 development teams in three different locations.

There are striking similarities between the way Spotify organizes their teams and the way U.S. Army Special Forces organizes their Operational Detachments-Alpha, aka “A-Teams.” It makes sense that the two would be similar because the A-Team was in fact an innovation designed to deliver a “service” under conditions of extreme uncertainty. In this case, the “service” was military assistance to the struggling Republic of Vietnam, and later to guerrilla forces and resistance movements waging unconventional warfare against the North Vietnamese. The U.S. Army had never undertaken a mission similar in objective and scope. They did not know the conditions, the support, or the communication capabilities that their soldiers would find. The U.S. Army needed a self-sustaining team with all the skills necessary to complete a mission with a broad and evolving scope. Moreover, the team would have to operate autonomously and would have to be trusted to make decisions normally left to upper echelons.

HALO

The U.S. Army assessed and selected twelve of their most seasoned veterans, and then trained them each in one of six specialties: medicine, engineering, communications, weapons and tactics, or intelligence. Having redundancy in each position was desired in case one soldier got injured, and it also gave the team the ability to pair a new member with a more senior member of the same specialty. Redundancy also facilitated the ascension of the team’s most senior soldier to the role of Operations Sergeant. The A-Team Operations Sergeant is comparable to the role of Spotify’s Agile Coach, or sometimes called a “Scrum Master” in other organizations. He no longer fills a specialty function on the A-team. He is the team’s mentor and draws on his experience to coach the team. He wants his team to be efficient and safe, which equates to a quality product in their realm. It is the also the Operations Sergeant’s job to advise and informally train the A-team’s commander on the team’s competences and potential with respect to their assigned mission. He ensures that the commander does not over commit the A-team to the stakeholders.

The A-Team was designed to operate deep behind enemy lines. They would not maintain frequent contact to their command. Because the complexity of the mission at hand, the A-Team worked not only for their command, but on the on behalf of many other stakeholders, such as the U.S. State Department, CIA, and other government agencies. In the absence of guidance from their command, and other key stakeholders, it is crucial that the commander, with input from the team, manage the team’s priorities with respect to the mission’s goals. Just like Spotify’s Product Owner, it is the A-team’s commander who ensures the team is on track to accomplish the stakeholders’ desired end state by prioritizing projects and associated tasks.

The way that Spotify tweaked the idea of a Matrix Org to facilitate product-centered teams while managing professional development and adherence to standards across functional areas resembles the method used by A-teams. Spotify organizes their development teams or “Squads,” into “Tribes” of 100 contributors of varying disciplines such as software engineering, hardware engineering, DBAs, etc. Each Tribe has a “Chapter” in which contributors with the same competencies are grouped. Chapters are led by “Chapter Leads” who are responsible for the quality of work produced by his or her chapter. Special Forces A-Teams are organized into “Companies” of six multi-disciplinary teams (around 70 people). A-Team “Companies” have a headquarters unit that is responsible for the professional development and standards of each specialty on the team. As an example, the medics on each team practice medicine under the license of a medical doctor assigned to the headquarters unit. The doctor’s function is similar to that of a Chapter Lead because he is responsible for each medic’s continued professional growth, refresher training, and the overall standard of care that is provided by his chapter.

The A-Team model’s structure has not significantly changed since their inception. During the Vietnam War, and most recently in Iraq and Afghanistan, Special Forces A-Teams have produced tangible results where larger, conventional military units have not. Their self-sufficient and decentralized approach allows the team to focus on mission accomplishment. The conventional Army’s centralized and hierarchical structure doesn’t allow for the flexibility needed to mitigate risk in uncertain environments. Results often become secondary to strict adherence to protocol for protocol’s sake, and the approval of long reporting chains. Similarly, in the technology industry, companies like Spotify who adhere to agile fundamentals are able to scale and grow successfully amid the uncertainty, while larger, less “agile” organizations become bogged down in bureaucracy, and can not navigate the evolving and uncertain market.


Comments Off on A-Teams

Seizing the Initiative

As a young Army Lieutenant leading a Platoon in Iraq in 2006, I was faced with a crisis. Our platoon was continually getting ambushed during our patrols in sector. The uncertainty of waiting to be attacked, the physical, mental and emotional strain on the men, not to mention the damage to our vehicles and equipment, started to take its toll. The ensuing battles would generally last for hours. We would stay out in sector for upwards of 16 hours. This would only leave 8 hours to come back to the forward operating base, refit and conduct maintenance on our vehicles. This type of operation couldn’t be sustained. Our morale was starting to fall, tensions were starting to rise between my platoon and the maintenance crews servicing our vehicles. We’d bring in leaking, limping, bullet ridden trucks and expect to jump back in them and roll out in a matter of hours. In military terms, we had “lost the initiative.” That is to say, the enemy was dictating where and when and how the battle would go. We were only reacting. We were compelled to react to the enemy’s strengths and capabilities. We were treading water trying to stay afloat. In this crisis, my men depended on me to come up with a plan to take back control, or “seize the initiative.” The importance of having a plan is emphasized in Sun Tzu’s famous quote, “ Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.” My platoon and I were at war, and trying to win.

sun_tzu_general

The crisis I experienced in Iraq is similar to the challenges many executives face with regard to scaling. Granted, no one is shooting at them, but the enemy can represent any or all of the variables and uncertainty in the industry; the customer, the competition, the software, the hardware, the market, etc. Some executives find they are compelled to react to daily incidents, i.e. “lets just make it another 24 hrs without an outage,” and it’s a struggle to maintain, let alone scale effectively. Just like with my platoon, this type of operation takes a toll on an organization. Aside from being bad for business, it sows the seeds of despair, brings down morale, and possibly creates tension between the engineers and the business folks similar to that between my troops and our maintenance crews. The leader needs to take a step back, understand what is going on and figure out a plan to get his or her team out of it.

For me, the solution was counter-intuitive at first. I knew we needed to take time to regroup, but I hesitated to not keep pressing the enemy. I feared that we’d lose what little ground we had. Then, I remembered something my instructor told me while learning to navigate in the woods with a map and a compass. He warned us, “If you don’t know where you are going, don’t walk as fast. You’ll only get lost in a hurry.” In our eagerness to get out into sector and fight the enemy we were getting lost in a hurry. We had gone to war, and were now trying to win. It is a difficult decision to halt operations, or take a product offline. Aggressive leaders are often very successful because they persevere in the face of adversity. However, there is a fine line between perseverance and stubbornness. I made the call to postpone operations. I needed time to develop an effective sustainable strategy.

“Seizing the initiative” requires leaders to make sound decisions under uncertain conditions and to anticipate events so their organization can recognize and leverage opportunities. The key to anticipating events is to understand the problem. In my case, we really did not understand the enemy. From an institutional standpoint, we had been training to fight the soviets for the last 40 years, and here we were faced against an adaptive and evolving enemy. We scaled our operations back at first, focused on reconnaissance and understanding the enemy. In doing so we were better able to anticipate events, and began setting the conditions of the fight. We were engaging the enemy when and where we wanted. We had seized the initiative. Regardless of your type of organization, if you are struggling just to maintain, if you have lost the initiative, the best solution is to take the necessary pause in operations, understand the problem, and develop a strategy for a sustainable effective approach.


Comments Off on Seizing the Initiative

Conflict and Innovation

Executives often complain to us about the level of conflict within their teams, or the abilities of their teams to resolve conflict.  Often, in the same session, they will wonder as to why they don’t achieve greater levels of innovation in their products.  Sometimes we hear things like “My team is too conflict avoidant – they won’t resolve their issues”, or “I simply don’t get why product and engineering won’t get along”, or “My engineers (or finance team, or team XYZ) simply won’t listen to the rest of the business teams”.  With respect to innovation, quotes range from “Why aren’t we more innovative” to “It seems like I’m the only one with ideas around here!”  Well guess what?  It’s YOUR FAULT!

The simple truth is that what we do and just as importantly, do not do as executive teams sets the stage for the creation and escalation of conflict and maximization or minimization of innovation within our teams.  Before I get into some of the drivers and results of both conflict and innovation, let me first spend some time trying to define some terms and clear up some fallacies surrounding the term “conflict”.

2 Types of Conflict

Psychologists and sociologists, especially those who study conflict, conflict resolution and innovation, recognize the following:

1)      Affective Conflict (sometimes termed Role Based) is “bad conflict”.  Affective conflict typically involves “who” should be responsible for doing something or “how” something should be done.  Any way you cut it, our jobs as leaders are to try to minimize this type of conflict and set up systems to reduce the probability that it happens.  Affective conflict is never good.

2)      Cognitive Conflict is “good conflict”.  This type of conflict deals with “what” should be done and “why” something should be done.  When handled properly, it helps increase strategic possibilities, open up new doors for innovation and drives teams to better answers.  When left unhandled by leaders, it will often escalate into affective conflict and be detrimental to overall performance.

I will just call these terms “bad conflict” and “good conflict”.

Outcomes (or consequences) of Conflict

Here we see why affective conflict is “bad” and cognitive conflict is “good”.

1)      High levels of bad conflict are highly correlated with lower morale, high rates of employee turnover within teams, slower time to market, lower levels of financial/business performance, and lower levels of perceived performance within teams.  Bad conflict minimizes and very often can completely eliminate innovation within a team.

2)      High levels of properly handled good conflict are highly correlated with higher morale, higher employee retention, higher levels of innovation, happier teams, faster time to market and higher levels of financial and business performance.

Put simply, you want lots of quickly resolved and properly facilitated good (“what and why”) conflict and very little bad (“who and how”) conflict.

Drivers of Bad Conflict

Research indicates that there are many drivers of “bad” conflict.  Here are some of the most frequent drivers:

1)      Team Alignment:  Without getting into the theoretical specifics, teams find themselves in conflict along team boundaries that are defined by organization structure and the resulting individual identities.  If you have an “engineering team” and a “product team” on your organization charts, the employees will identify with one or the other and sometimes conflict along those boundaries.

2)      Employee Tenure:  Research shows that employees also identify themselves along tenure boundaries.  These may be the “old guard” and the “new employees” or the “founding team” and the “new team”, etc.  While not codified within an org chart, this stratification of employee identities can lead just as much to conflict creation as an actual organization.

3)      Leadership Approach:  Engaging in quid-pro-quo management (“Do this for me, and I’ll do that for you”) is highly correlated with conflict creation.  Individuals think of themselves, rather than a team.

4)      Loosely Defined Responsibilities:  Chaos breeds conflict.  When people don’t understand the boundaries and expectations, they attempt to expand or define each for themselves which in turn increases strife.

Out with the Bad and In with the Good

Bad conflict is inversely correlated with good conflict.  The more bad conflict you have, the less good conflict you have.  Good conflict on the other hand correlates directly with innovation.  The higher the good conflict, the higher the level of innovation.  The fix to ending bad and promoting the good is to address each of the areas above.

1)      Team Alignment:  Create cross functional teams aligned around product or service initiatives – not functions or experiences.  Each team should have all the experience across all domains that it needs to be successful.

2)      Employee Tenure:  Eliminate old and new employees who cling to tenure based identities.  Ensure everyone understands there is one, and only one company identity (though there may be product identities within the company – but each of these has everything they need to be successful).

3)      Leadership Approach:  End quid pro quo leadership and talk about higher purposes and team accomplishments.  Make the job about something other than just the individual.  Eliminate people who are “in it for themselves” and won’t contribute to the higher cause.

4)      Loosely Defined Responsibilities:  A leader has many responsibilities and one of them is to eliminate uncertainty where possible.  Help people quickly resolve conflict with roles.  Don’t let employees come into conflict or stay in conflict about competing roles and responsibilities.


2 comments

Enablement

One of the most important aspects of managing a successful technology organization is ensuring that you are practicing & instilling the concept of enablement at all levels. This concept applies to both the product/service you are producing and for people. A good example for your organization is enabling decision-making at the lowest levels possible. I have often seen this represented as “delegation” but I believe that enablement of decision-making is a more powerful concept than delegation which is driven from the top-down. I recently had the opportunity to lead a large infrastructure team and one of the first changes we made was breaking apart into reasonable sized PODs with the primary purpose of ensuring that decisions for the product & technology were driven from the bottom-up while guidance was flowing in from various stakeholders. Many teams practice a flavor of Agile but without enabling each POD to make the appropriate decisions you will run into organizational scalability problems.

The allure of IaaS & PaaS is firmly rooted in the concept of enablement. Self-service is an amazing if you are a DBA, developer or even the end user of your product. The cloud may not be suitable for your needs but don’t let that stop your organization from thinking strategically about bringing those processes & technologies “in-house” for scalability reasons. Implemented correctly, the infrastructure and platform you are building should enable the users and not hinder them, as is sometimes the case. Reducing the number of dependencies between technology teams for launching products is not only good for cycle time of product launches but also critical in scaling up.

Consider making enablement part of your technology team’s DNA and you will likely see that employee morale, productivity and other metrics like NPS will rise.


Driving Change

Driving big changes can be difficult in an organization and it can be especially difficult for new managers. Change is necessary and we should never be happy with status quo as our competitors and the overall market is changing around us. The larger the organization, the harder change can be. We touched on this in an earlier blog titled Five Leadership Lessons From Former Bosses but decided to dive into a little more detail this time. As a former manager of engineers and other talented technologists, I recall in my early days how I simply wanted to identify where we were headed with my team without giving them time to collaborate and provide input. On one occasion, we were in the midst of changing our PDLC to Agile. Agile was fairly new at the time so many didn’t understand the basis of it and in turn were resistant to using it. That problem is easily solved, right? I could just tell the team this is where we are going and this is how we are going to do it, now make sure you execute. And in a couple weeks time, poof, the change would be made and life would be good. After all, that would have been easy, right?

Although I didn’t say the words “get onboard,” I might as well have. I can tell you this doesn’t work well. My team was zapped. At that point they were no longer empowered and didn’t have any ownership of the change and when that happens a team’s performance will be suboptimal. Yeah, I could use the excuse that my senior management dictated what they wanted and I could drum up a bunch of other excuses but the fact of the matter is I should have raised a flag with my leadership and encouraged better collaboration for input from the engineers, QA testers, product managers, and others.

There were two key learning points that I was able to take away from my experience. Technology leaders should ask themselves two simple questions before they start to drive change in their organizations.

1) How do I make sure that my team has input and ownership of the change we are about to make?

Sit down with the team and work with them on coming up with solutions and their recommended timing. Engineers love to problem solve and they are very good at it. Provide the team with the problem that needs solved and any constraints and let them determine the solution. For example, in the situation I described above, we needed to improve our time to market. Many products and features across the organization were being delivered late, payloads for deployments were too big, and the business was frustrated. As on overall company we decided that we would adopt Agile utilizing Scrum practices but there were still many problems that needed to be solved. Those included determining a branching strategy, determining a deployment strategy, identifying how to measure a sprints performance, and many others. By providing the context of why changes need to be made, the team will recognize the significance of their input and by allowing them to come up with solutions they will feel empowered and have ownership in the game. All of this will help you to create a higher performing engineering team.

2) What do I need to do as a leader to establish guardrails in my organization and sustain the change as my company grows?

Once the team has determined how to solve some of the problems, you will want to make sure that you sustain them in your organization. To do this, work with them to establish documented guardrails or principles that be used as the what. For example, the Agile Manifesto essentially identifies principles that you can use. One principle could be “Business people and developers must work together daily throughout the project.” This describes a behavior that’s needed but doesn’t identify how. The team can decide the specifics on how they will achieve the principle. We at AKF believe in establishing architectural and scaling principles that are essentially guardrails as well. (Visit our earlier blog on architectural principles for more details.) For example, Rule Number 39 – Ensure You Can Wire on and Off Functions in our book Scalability Rules identifies the need to have a framework where you can quickly disable and enable features to minimize impact to customers when a failure occurs. You can solve this many ways and your engineers can determine what the solution should be. Once your principles are established you should monitor them to make sure they are being upheld and reward results.

If you ask yourself these two simple questions before diving into a big change your road to success will be much easier. Now that you have empowered your team to determine how to solve the problem and you have documented your principles and guardrails, the team should be able to operate within them and make decisions on their own. In turn, you will find that they feel empowered and you will have helped to create and maintain a higher performing team.


1 comment

What Makes You Successful?

It is difficult – research shows nearly impossible – for any of us to accurately answer the question of “What makes us successful?”

At the intersection of cognitive biases (especially attribution bias) and the Dunning-Kruger effect lies this (to my knowledge unnamed) phenomenon that keeps all of us from understanding how our contributions might have resulted in a successful outcome.  Cognitive biases cause us to take far too much credit for successes, and incorrectly attribute the reasons for our success.   The Dunning-Kruger effect causes us overrate our abilities to achieve similar success in the future.   All of these work against us in trying to determine what allowed us to be successful.

Incorrectly attributing the causes for our success can be a huge problem.  Imagine that you decide that the reason your company achieved a particular successful outcome is because of your sales ability as a senior executive.  You might be inclined to believe, based on your personal analysis that your sales ability and sales execution will result in similar future successes.  There are two potential problems here.  The first is that we  incorrectly attributed the reason for success when the real reason was due to, for instance, the efficacy of our product.  The second is that we overrated our contribution and abilities when the real credit should go somewhere else.   Clearly both can lead to future disasters down the road.

You may be thinking that many people are successful time and time again by taking similar actions and by employing similar behaviors.  That is absolutely true.  The issue is not whether we can repeat our past successes – it’s that we can’t accurately identify (for ourselves) which actions or behaviors led to those successes.

Research suggests that we are much more likely, if we apply disciplined process, to learn from failures as compared to successes.  Even greater learning can be gleaned from comparing our successes and failures.   Furthermore, involving others helps us triangulate and either validate or invalidate our beliefs as to the causes of both successes and failures.  The key here is disciplined process coupled with introspection and outsider perspective to guard against cognitive bias and eliminate the Dunning-Kruger effect.

In summary:

1)      We are ill equipped to identify the causes of success without outside help.

2)      We are better equipped to identify the causes of failure.

3)      We are best equipped to compare successes and failures and draw conclusions.

4)      It is always best to involve multiple people in the identification of either success or failure.


21 comments

Five Leadership Lessons From Former Bosses

Over the past 16 years I have had a chance to work for more than 12 different bosses. While some have been better leaders than others I’ve tried to learn from each of them. Below are five leadership lessons that I’ve picked up from them and subsequently been able to use with my teams.

  • Retain Talent – Go out of your way to retain your good people. Make it personal and include the family when possible. One of my star players shared with me that she had dinner plans with her husband for their anniversary. I called ahead to the restaurant and bought them a bottle of wine with the message “Happy Anniversary and thanks for all of your hard work.”
  • Success Metrics – Use team success metrics to motivate your team and create a strong culture of driving to success rather than some arbitrary stopping point like a release. As we’ve written about before don’t confuse product releases with success. Identify and start to measure business metrics that the team can understand and rally around. Determine what to measure based on the drivers of revenue and cost of your business. Share these metrics with your organization and celebrate success and dig into areas where you are falling short to identify a get-well plan.
  • Guiding Principles – Empower your team with guiding principles that help them to make day-to-day decisions. Similar to architectural principles, guiding principles empower your team or organization to make decisions on their own. Have the team help develop them and make them visible. Revisit them on a regular basis. This especially helps during times when you need to drive mindset change. You will be surprised at the questions and conversations that come up as you drive to calibrate on mindset shift.
  • Poor Performers – Do not ignore your poor performers. Use these three axes to evaluate employees performance. If the problem is performance, attempt to help the employee by coaching and mentoring. If the problem is behavioral or if they don’t respond to coaching, you need to manage them out quickly. Depending on your organization, it may be difficult to manage poor performers out but this is not an excuse to ignore it. Poor performers can be a drag on the team, poor behaviors can be cancerous. And don’t forget they are a reflection of your work as well.
  • Feedback – Give feedback to your team members frequently and in real time. Don’t wait until the annual review to give feedback. Gen Y and Millenniums are more accustomed to instant feedback and communication. That means you may have to adjust your style as you work to coach and guide your direct reports. Utilize all available communication medium to praise. Send them an email recognizing them for their actions and tie it to the positive impact it had on the business or the team. Leave them a voice mail. And of course the good old fashioned in person or one by one conversation works well. You will soon seen the positive motivation you inject into your team.
  • Business KnowledgeUnderstand the business. The only way for you to be successful is to be able to speak and work with other business executives, which means you need to make the effort to understand their roles. Block off your calendar to sit with peers to see what they do on a day-to-day basis. The path to a CIO/CTO role is by being a great partner to the business.

Hopefully you can use some of these with your teams or at least make you aware that you should periodically look back for lessons learned. Often these lessons learned make great one-on-one topics for junior managers interested in improving their leadership.


8 comments