Browsed by
Author: Blake

start⬆Mngr handbook pt. 6: Before we start analyzing data…

start⬆Mngr handbook pt. 6: Before we start analyzing data…

First, a personal story.

I once helped a colleague on the customer success team (let’s call him Lou) analyze our retention data.

Lou asked me: “Can you help me get a report on the number of inbound service requests filed in the past quarter for each of our customers?” Easy enough I thought. I pulled the data from our help desk, created the report and sent it over to Lou. I thought that was the end of it.

A few days later, Lou came back and said: “Thanks for your help last time. Can you also get me a report on the amount of time that we spent responding to requests in the past quarter for each of our customers?”

The report wasn’t complicated to create, but we lacked the data. We did not track time spent servicing customers. After speaking with Lou, we decided to have the team start tracking their time. We recorded over a month of data before we created a first report. Lou looked happy with the results, so I thought this was again the end of that project.

Turns out, Lou didn’t really have a goal in mind..

Wrong. Over the following weeks, Lou requested half-dozen more reports, and we initiated the tracking of many new data points. A good amount of time and energy went into this retention analysis.

After Lou’s requests died down, I curiously asked: “So how did all the reports help you in the end? Did you find what you were looking for?”

Turns out, Lou didn’t really have a goal in mind… Lou was at first curious about how much resources we were spending per client, which led to follow up questions along the way. Based on the data, Lou eventually suggested to the customer success leadership to start setting limits to how many hours each client could access per month. Yet because of other priorities and constraints, the suggestion was never implemented. So nothing came out of the analysis.

The good news is that the new data points we tracked provided us a ton of useful information that eventually led to other changes that helped improve our retention goals. However, that took another few weeks. And fact is, the whole project could have been a complete waste of time.

Having worked on hundreds of analyses with dozens of data-driven companies, I can confidently say that teams without an analytical process in place have an extremely high chance of wasting time performing data analysis.

Start-up companies today have at their disposal an unprecedented amount of data, but it doesn’t guarantee good decisions. It doesn’t matter what BI tools we use. They are all useless if we don’t know what questions need to be answered.

To avoid wasting time and energy while pursuing analytics projects, this blog post will showcase an analysis process and framework to follow before any analytical work begins. Let’s make sure every analysis has a clear purpose.

For analysis projects to be successful, we need three main ingredients: the relevant data, people that can interpret that data, and an analytical process to ensure that we’re asking the right questions and creating the relevant reports. In part six of our startup manager handbook, we’ll thus be exploring the process of initiating data analyses to help:

  • Gather evidence to a problem;
  • Measure success and evaluate performance;
  • Take data-driven decisions;
  • Avoid performing the wrong analyses;
  • Avoid answering the wrong questions.

Before going further, let’s clarify that depending on the organization, analyses can also be referred to as measures, metrics, reports, and other quantitative or qualitative evidence based assessments.

We will not be discussing analytical/statistical methods (or data science methods), since there exists a ton of content on statistical methods out there already. However, to help those that are completely new to data analysis, I’ve included links to some of my favorite data science resources at the end of this blog post.

1. What is the problem and the goal?


The most critical step of an analysis is to ensure that it answers the right questionYet more often than not, we are so eager that we jump right into the data without a clear goal. The result is wasted time and resources in performing analyses that may not yield relevant insights, and doesn’t help with decision making.

This widespread behavior is likely from undergoing 15+ years as students where problems are defined for us, and all that’s expected of us is to solve them. Unintentionally, schools have failed to teach us how to define problems.

Strongly recommended reading on problem definition:

What is being asked?

Before going further, let’s first understand what is being asked. Here are the critical elements to acknowledge before any analysis work can be performed:

  • Is the question clear? There are often acronyms and ambiguous words used in describing a question, problem, or desired analysis. It’s important that there is clarity on how these words are interpreted to avoid miscommunication.
  • Does the requester have a specific vision for the end result chart or report? Analysis consumers may have an idea on the specific report(s) they’re looking for. So ask for it. While the envisioned report may not be best suited to their analysis goal, simply acknowledging it will help us understand the context and motivations behind the analysis. In addition, individuals with specific ideas on the end result often want to see their desired reports regardless of what we say. I thus recommend building the report, explain why it doesn’t answer their question, and then reveal the better analysis. It shows that we acknowledged their need and understand the context of the problem.
  • Can I explain the goal of the analysis in my own words? Repeat the analysis goal in our own words and validate with the stakeholder(s) – this ensures that there is agreement on the goal. (e.g. “The goal of the analysis is to assess whether cars primarily driven on the highway have a longer service life than cars primarily driven in urban centers. Is this accurate?”)
  • Do I understand the motivations behind the goal? Understanding why the analysis goal is relevant to the team or organization will provide a sense of direction when we start identifying analyses to perform. It also helps us validate any assumptions we may have about an analysis’s motives. (e.g. For a transport company, they may need to know if cars primarily driven on highways have longer service lives to see if there’s an opportunity to incentivize their drivers to take the highway more often than local routes. There may thus be opportunities to also analyze why drivers currently like to take local vs. highway roads.)
  • What potential actions or decisions will be made based on the results? Why would we spend time on an analysis that doesn’t translate into a decision or action?

What motivations lie behind the analysis?

Of the five points explored above, understanding motivations can be particularly challenging. To help, let’s remind ourselves of a tool we’ve used before: The 5-why method for root cause analysis. This method can be leveraged to understand Why an analysis makes sense to tackle. Questions such as “Why is _____ of interest” or “Why does your team focus on _____” will help kickstart the process.

2. Who exactly cares?

what is your role?

Stakeholders previously helped to explain the analysis goal. For the analysis results to be meaningful and used in decision-making, these same stakeholders need to participate in the analysis process as well. It’s therefore critical that responsibilities are agreed upon with stakeholders before an analysis begins. Let’s explore some common  stakeholder responsibilities (an individual may certainly wear multiple hats):

  • Decision-taker(s): These are individuals that need the insight to drive a decision or assess a situation. Among decision-takers, I’ve found it helpful to identify one individual that also serves as an advocate for this analysis: A person that will take part in reviewing all progress. This ensures that the analysis has continuous buy-in from its stakeholders and remains a priority throughout its duration.
  • Data warehouse developer(s): These are individuals that have deep knowledge of the data warehouse. Among other duties, they can help us access the relevant data points and track new data points.
  • Subject matter experts(s): These can be individuals that have contexts around the data that will help us make sense of questions that may come up when performing the analysis.
  • Observer(s): These are individuals that are curious about the analysis for reasons unknown. Perhaps they want to become decision-makers based on results, perhaps they are curious as to how an analysis is carried out at the organization, or perhaps they are simply looking for investigation. Independent of motive, these are individuals that the analysis team will need to update when major milestones are met.

Having these stakeholders participate in the analysis process ensures that everyone is on the same page throughout the exercise. In turn, they buy into the analysis and understand its nuance and caveats before final results are presented.

When stakeholders fail to participate in the analysis process, they may doubt results presented in the end, losing trust in what the data has to say. This must be avoided at all cost.

3. What analyses will help answer our questions?


Next, it’s time to envision (not yet perform) analyses that will help answer our analytical questions. This translates into an analysis plan, avoiding the risk of analyzing blindly.

A good way to start envisioning what analyses to perform is to ask: “If I had access to any dataset, what analyses would I want to perform to answer this question?”

Assuming that we have access to any dataset makes us more creative. In the context of data analysis, our creativity can often be limited by data not being available, or data not being in a format that we need. Yet chances are that once the ideal analysis is identified, a way to work-around existing constraints will also be found: e.g. by tracking the missing data, or finding a similar dataset stored in the required format. Even if there are no work-arounds, it is still valuable to acknowledge that there are important analyses we couldn’t perform due to ______.

Next, let’s review some characteristics of a good analysis:

  • Relevant: The analysis needs to directly relate to the goal. Every datapoint that does not answer the main question(s) or provide additional context become distractions. Distractions do not help stakeholders with their decisions, they should be avoided.
  • Trustworthy: Both methods and datasets used in the analysis need to be trustworthy. There should be no doubt as to whether the data is accurately recorded and properly formatted, while the methods used are relevant to the analysis goal. This means that reasons and explanations are available to support every decision surrounding the analysis. Decision-takers will appreciate the diligence, but most importantly, trust that they can rely on the analysis for their decision.
  • To the point: At least one of the reports needs to answer the question directly. It should be as black and white as possible, revealing a clear insight that helps decision-takers come to a conclusion. Even if the conclusion is that we need to perform more analyses, that report needs to unequivocally and quickly show why that’s the case.


  • Communicates a story: To effectively communicate an insight, analyses need to be exposed in the form of a story. To this effect, I highly recommend this book on Storytelling with Data to explore the basics of of data communication. I also recommend adopting the following flow to the story:
    1. Communicate the recommendation first: I usually start with the final recommendation and reveal at least one data report that clearly shows why I’m making this recommendation (see “To the point” note above). This ensures that people do not wait to discover the final insight that the analysis achieved. In addition, it also prevents conversations from sidetracking before the final insight has been shared.
    2. Explore caveats and supporting arguments next: If there are other reports that provide additional contexts to the recommendation, explore them next. I recommend starting with reports that illustrate caveats or go against the recommendation to address concerns and skepticism right away. Then we can proceed with analyses that support the recommendation to show how they outweigh the negative arguments.
    3. Close by re-iterate the recommendation: Finally, re-iterate initial recommendations by coming back to the main analysis, and allow the audience to raise questions.

As a final tip, I recommend to review results and rehearse the story with a colleague before the final presentation. This helps to anticipate questions and catch mistakes before they affect the analysis’s trustworthiness.

Other viewpoints on properties of a good metric:

So what’s the plan?

The outcome of the 3 steps approach to initiate analysis projects can be best summarized in the analysis canvas explored below.

Analysis Canvas
Analysis context

  • Goal: What is the main question that the analysis needs to answer?
  • Motivation(s): Why is the analysis goal and core question relevant?
  • Action(s) to drive: What are the decisions and/or actions that the analysis will empower?
Planned analyses (measures, metrics, reports…)

  • List of analyses to build
Stakeholders and participants

  • Decision-taker(s): Who needs this analysis to help take a decision?
  • Helper(s): Who can help answer questions with regard to the analysis goal and context?
  • Observer(s): Who are simply interested in the analysis with no stake in its results?
  • Analyst(s): Who will be performing the analysis?

I personally only start performing analyses after core stakeholders, especially decision-makers, review and agree to the analysis canvas. This ensures that there is an agreement from the get-go with regard to the analysis goal, individual responsibilities, potential actions to take, and analyses to build.

In my experience, starting to analyze data without agreement on these points can lead to future conflicts and missed expectations. There’s no time to waste on any of that.

Data analysis / data science / statistics resources

Finally, as promised, allow me to share some resources on analysis methods:

Recommended exercise

Let’s pick an analysis that we want to perform and fill out an analysis canvas. What’s our goal? Why is that important? What actions do we plan to take based on the results? What are relevant analyses? Who else needs to be involved?

Subscribe on the right for new insights every week!

start⬆Mngr handbook pt. 5: How to keep processes lean

start⬆Mngr handbook pt. 5: How to keep processes lean

First, a personal story.

In the early life of our B2B start-up company, we had less than a hundred clients and were able to have close relationships with most of them. This translated into regular conversations with our customers, during which we’d get a lot of special requests for our software and services. It was easy to get a sense of what our customers wanted. And since we were still young and unsure of the specific direction we want to take with the product, we often catered to our customers’ needs. We followed through on almost all customer requests.

Slowly with time, and as our customer base grew, our tailored approach to servicing customers showed signs of weakness. Our teams worked 12 hour days just to keep up with all requests, and our product was being pulled in a dozen of different directions. Worst of all, our customers started holding us accountable for delays in service requests that we took on as courtesy (these weren’t technical support requests, but rather actions that customers could do by themselves).

It was clear that our approach wasn’t scalable. We couldn’t continue on without hiring dozens more team members. This would have set our margins way back. So we did what every startup in that need to scale does: We created processes. We began to standardize responses to customer requests, and setting clear expectations around what we do and what we don’t.

Everything worked well at first. Having processes helped us save time and improve the way we respond to common requests. In turn, it allowed us to focus more energy and time on customer education, creating more self-sufficient users.

Yet a few months after we started creating processes, it overwhelmed us. Our team documented preferred solutions and responses to all situations imaginable, including edge cases. Our operations manual was over 30 pages long. You know something’s wrong when people have to spend 15 minutes looking for the standard response for requests that take 5 minutes to resolve, or skip the standard process entirely because it was too much of a pain to find. Yes, we went overboard with standardization.

With time and experience, we were able to find a balance. We standardized responses to common requests, but more importantly, provided a general philosophy and rule of thumb for the rest. This gave flexibility and control to our team members, who could respond accordingly, acknowledging the context of the situation.

For example “Protect service margins” was one of the rule of thumbs that helped our account managers decide whether to pursue a time-demanding project, while “Prioritize high value clients” was another guideline they’d have to account for when dealing with customers with high value contracts. Based on these, there was no standard response to most edge cases, but simply guidelines to help team members take an independent decision.

The result was that we achieved consistency in our general approach to customer requests, without being boggled down in the details. For common requests, everyone responded similarly. For edge cases, our team members had the flexibility to do what was right in their perspective, based on general guidelines. More importantly, we were able to start providing standard service level agreements (SLA) to our customers, setting clear and transparent expectations.

I’ve learned that processes are good as long as it doesn’t slow our team down. In part five, we’ll explore how to manage common issues around process creation and process changes, including:

  • When to change a process;
  • Changing processes too often;
  • Handling edge cases.

Should I break the process?


As a company matures, it is bound to adopt more processes to guide operations rather than rely on one-time decisions from individuals. This is how an organization gains operational efficiencies as it grows. We will not be reviewing process improvement techniques in this blog post (explored in part 4), but rather discuss when to break a process and when not to.

The need to break a process usually starts with a special request or edge case that an existing process doesn’t allow or didn’t consider.

For example, a high value customer asks for a refund at a major retailer without a receipt, past the 30 day refund deadline. If we follow the refund process, we may disappoint and lose a high value customer. So should we break the process?

One thing to recognize is that every edge case is an opportunity to assess whether the business environment is shifting and identify new market trends. When there is evidence that customer expectations are shifting, responding quickly and effectively can yield a big competitive advantage.

Consider news readers that shifted their source of information from newspapers to online articles. Publishers that acknowledged the market change were able to adapt and avoid irrelevance, while those that didn’t went under or had near death experiences.

To evaluate how to best respond to an edge case request, let’s adopt an analytical approach to answer the following questions:

Who is affected by the event and how? Knowing who is impacted will allow us to seek and consider their opinion on how to respond and why. Stakeholders can be customers, partners, or internal teams.

Is this truly an edge case or the new trend? Statistically speaking, an edge case or outlier event only occurs in rare instances. The frequency at which an outlier occurs should also not increase substantially over time.

On the other hand, a trend should experience rapid change in the ratio of occurrences over time.

To perform an accurate analysis on an event’s occurrence, I recommend segmenting the data by different population groups, categories of events, and other relevant variables.


➡ If the event is an edge case: The question becomes whether the edge case is worth breaking a process for.

  • If the edge case doesn’t merit a break in process: Say no, explain why, and move on. This option is best used when the benefits of upholding the process outweighs the benefits of allowing an edge case to occur. Questions that can help us assess the situation include:
    • What’s the implication of breaking this process?
    • What’s the precedent that we set?
    • Does it set the precedent that we want? e.g. Is offering a refund to a customer aligned with our company strategy? It could be, if the strategy is to provide outstanding service, but it could also not be, if we are a low-cost provider.
  • If the edge case is worth breaking the process for, the benefits of breaking the process needs to outweigh the benefits of upholding the process. Note that repetitively breaking a process will slowly erode the process, so if we find ourself repetitively breaking a process for the same reasons, we need to re-assess whether the event is a new trend.

➡ If the event is a market trend: The organization needs to decide how and when to respond at the soonest opportunity. Not acknowledging a market trend puts the company at risk of being irrelevant.

  • Does this new trend require re-designing the entire process? This is usually the case if the new trend is rapidly changing market expectations, or if the existing process is quickly becoming irrelevant. There is no time to lose.
  • Or can the current process be amended and maintained for now? This approach can be taken if the existing process is still relevant, and there is no clear evidence that the new trend is rapidly changing market expectations. This allows us to wait and observe whether the trend grows, then prepare for an eventual process change when the time is right.

Let’s remember that every edge case is an opportunity to observe a potential shift in market needs. Sharing this insight with team members and having a data tracking system in place will ensure that no opportunity is missed.

Are you leading a startup team? Subscribe below to join our community!

Recommended exercise

Let’s pick a special request that was recently received and evaluate whether it is a new trend or an edge case.

Subscribe on the right for new insights every week!

start⬆Mngr handbook pt. 4: Intro to innovation & quality improvement

start⬆Mngr handbook pt. 4: Intro to innovation & quality improvement

First, a personal story.

Like most ambitious companies, our team is constantly looking to improve our performance. We’re never OK with the status quo. If sales conversion were at 90%, we’d want to take it to 100%. And as a start-up, there are so many things we can improve…

This meant that in the early days, before we had adult supervision and a clear company strategy, we changed processes a lot, switched focus weekly, and experimented with many different product features. On the customer success side, we’d setup retention email campaigns to keep churn rate down in one month, and  we’d leave that behind and work on up-selling customers the next month to boost revenue. Two quite different goals. On the product side, we’d get excited about an idea that a customer wants, spend a couple sprints developing it, but then never touch it or improve it again. This speed of change is not uncommon at early stage start-up companies.

…most successful innovation projects started with a problem definition stage before jumping to problem solving

On the good side, we were never bored. We always had something new and exciting to do. Yet on the downside, we had little consistency in our approach to improve the company’s performance, going in all directions and doing everything at once. Team members would be left wondering what our long-term goals were, and what set our product apart from the competition. We tried to be everything for everyone, without the resources necessary to do so.

This led to process changes and product features that didn’t improve our bottom line. We’d waste time and resources on non-coordinated initiatives that failed to convert more customers, did not attract more prospects, and didn’t retain users. Worst of all, we’d execute and move on from all these projects without documenting our learnings, so we’d repeat some of our mistakes.

To help correct for this lack of direction, I spent much time exploring how other companies managed innovation projects: From hospitals to grocery stores, from tech start-ups to auto-makers. To my surprise, I found a consistent theme: Almost all innovation projects were carried out in a systematic way, following scientific processes that relied on data and experimentation. More importantly, most successful innovation projects started with a problem definition stage before jumping to problem solving (very hard concept to grasp for engineers).

In this blog post, I’m going to explore how to properly challenge the status quo and innovate systematically. We will discuss a system to help us lead innovation and quality improvement (QI) projects in order to:

  • Increase effectiveness of a process or product;
  • Solve the root cause of a problem rather than the symptoms; and
  • Boost creativity in problem solving.

For a quick introduction to innovation and quality improvement, I highly recommend the following TED style video by Professor Russell Ackoff.

The purpose of quality improvement projects is to change the way a problem is currently solved for the better. Better can be defined as doing something right, increasing effectiveness / efficiency, or lowering cost / margin for error. Since the market continuously changes, and our competitors never stop evolving, innovation projects are necessary for organizations to stay relevant.

Now let’s explore the basic steps of carrying out an innovation or QI project in an agile environment:

quality improvement process

This process ensures that we solve the right problem, test different solutions, and validate results before scaling. It avoids jumping to solutions that solve the wrong problem and wasting resources (realize that finding solutions is the fourth step, not the first). Let’s explore this in detail.

I. What’s the problem?

As a first step, let’s find supporting evidence to the problem, understand why it is occurring, and whether it’s relevant to the company/team mission.

Does the problem really exist? Is there evidence?


Innovation projects tend to arise from frustrations and desires to improve existing systems or processes. Before jumping to solving what we believe is a problem, it’s critical to gather evidence in the form of quantitative or qualitative observations to prove that a problem actually exists. Through this step, I’ve often found that the actual problem is quite different than our initial perception.

Evidence can take the form of data reports, analyses, interviews, or surveys to name a few examples. With recent innovations around analytics, there’s no excuse to have at least one piece of statistical evidence.

For example, one may be frustrated at the slow speed at which team members answer and complete customer service calls. Evidence to support the fact that team members are working slower than possible can come from:

  • Listening in and interviewing call agents to understand if there are opportunities for further improvements on the call process.
  • Evaluating the average time it takes a group of fully trained agents to complete a call; and the average number of daily calls one agent can take.
  • Assessing whether the number of calls an optimal team can take in a day is higher/lower than the current volume.
  • Assessing the reasons customers call to receive help

With evidence, a more complete picture of the problem(s) will emerge. Again, we’re very likely to discover that initial assumptions on the problem are wrong, or that they are only a small part of the actual problem. That’s great. That’s why we gather evidence.

What’s the root cause?

root of the problem

Once all the necessary evidence has been gathered, a root cause analysis can be performed using the 5 why’s method. This ensures that the QI project focuses on addressing the source of the problem rather than its symptoms and side effects.

In our example, we may find through root cause analysis that the actual problem is that the agents are receiving too many calls due to business growth. This could result from the fact that the number of agents has remained unchanged, while the number of customers and calls has grown. Data could also show that agent’s response time and call duration have not varied over history. So the problem may not be that agents are too slow.

Ensuring that our problem is accurately defined is crucial. Otherwise, our solution will be useless. Yet more often than not, we are too eager, impatient, and jump right to identifying solutions. We enjoy solving things, coming up with ideas. Unfortunately, a good idea to an misdefined problem is not as effective as a bad idea to a well-defined problem. The result is wasted time and resources that may not bring the desired innovation and quality improvement.

This widespread behavior is likely from undergoing 15+ years as students where problems are defined for us, and all that is expected is for us to solve them. We get rewarded to solve problems, not defining them. Unintentionally, schools have failed to teach us how to pinpoint problems.

A good idea to an misdefined problem is not as effective as a bad idea to a well-defined problem

I personally have greatly benefitted from reading “Are Your Lights On?” in an attempt to get better at problem definition. I highly recommend it to everyone that solves problems, especially engineers.

What’s not part of problem?

Every project should have a defined scope. This specifies the part of the problem that we’re aiming to solve (Do we want to solve climate change, or do we want to reduce the amount of CO2 released by our fleet of vehicles?). It is critical to set a clear scope to our problem, as the 5 Whys process has a tendency to yield potentially irrelevant problems that we may not want to tackle just yet. We need to resist the urge to take on every problem we discover and focus on the problem that is most important, relevant, and that we can effectively make an impact on. If the 5 Whys reveals multiple large problems, the QI project can be broken down into phases, focusing on the most pressing problems first. There is more details on prioritization later on in this blog.

Is it relevant to the team goal and company strategy?


Next, compare the problem to the team’s goal and the company’s strategy: If they are aligned, the project will push the team and company toward its ultimate goal, but if they don’t align, the project will waste precious resources.

In our example, assuming that everyone agrees that “having too many inbound customer service calls that potentially don’t need agent help to resolve” is the problem, we will need to evaluate whether the behavior is desired or not in relation to the company strategy and team goal.

If the company strategy is to offer best in-class human support, then the problem identified may be irrelevant, and a potential business case should be made to hire additional agents to help with the lack of bandwidth. Yet if the company strategy is to empower customers to self-serve wherever possible and maximize the ratio of customers to agent, then this may be a project worth pursuing.

OUTCOME: At this stage, we’ve gathered evidence that validates the problem, a root cause analysis has been performed to identify the problem’s source, and we know whether the problem is relevant to the organization. There is thus enough preliminary information to decide whether this is a problem that the organization wants to pursue.

II. Is this a priority?


Most organizations are bound to have multiple innovation and QI projects running at once, yet limited resources. We thus need to prioritize. Here are some questions that can help us do that:

  • What’s the potential impact / value of this project?
  • What if we didn’t do it?
  • What if we didn’t do it now, but later?
  • What’s the cost? human, material, time, …
  • What’s the ROI? [Value / Cost]

Based on our answers to the questions above, we’ll be able to compare and rank projects by priority.

It’s important to realize that ultimately, a project’s priority is reflected by how much resources we allocate, so we need to ensure that each project has the appropriate allocation of time, people, and other resources. Generally speaking, important projects deserve more resources.

What about low priority projects? Again asking “what’s the impact if we didn’t pursue it?” will help us decide whether to:

  • Cancel the project and never revisit it; or
  • Re-assess its priority later when resources are freed.

When it comes to prioritization, choosing what not to do is more important than choosing what to do. This ensures that top priorities get the right amount of attention and resources, and that plans are realistic. This applies especially to ambitious teams that tend to take on too much. Let’s thus recognize that doing everything is not successful prioritization. It runs the risk of juggling too many balls, and consequently, dropping all balls. Our startup companies have limited resources, so let’s choose how we spend our time wisely.

OUTCOME: Our project is now prioritized against other initiatives, which gives a clear idea of when to pursue it.

III. What do I expect?


Now’s the time to envision our desired end result and answer: What do we hope to achieve?

Of the three categories of goals (individual goals, functional team goals, project goals), projects need the clearest goals and expectations at the start. For example, before building a house, a clear blueprint needs to be drafted to communicate to all stakeholders what is expected in the end. The same applies to innovation and QI projects. Setting expectations before work begins ensures that all stakeholders  can agree or debate the desired outcome before it is implemented. Being specific in outlining expectations is key, so I recommend adopting a SMART approach.

Note that this is not yet the time to envision solutions or think of how to achieve the desired expectations. Doing so would be like starting to drive toward California before figuring out that we should actually be going to Florida. 

Based on our example case of a company wanting to decrease the number of inbound calls that can be resolved with self-service, the expectations for the project can be to:

  • Decrease the percentage of self-serviceable requests addressed on calls from X% to Y% in three months.
  • Lower customer call wait time to less than 5 minutes for 90% of all calls by X date.
  • Maintain Net Promoter Score at X and above beginning on Month/Day/Year. 

When it comes to measuring our goals, there are two types of metrics that we can leverage: progress metrics and outcome metrics.

  • An outcome metric assesses whether the desired outcome was achieved. e.g. In our example, a call’s wait time is an outcome metric, necessary to check whether 90% of all calls are answered within 5 minutes.
  • A progress metric tracks the impact of specific solutions, which in turn may contribute toward the desired outcome. e.g. In order to achieve the desired expectation around response time, one change or solution may be to have all calls completed or resolved within 10 minutes to ensure a high level of bandwidth availability. To that effect, the percentage of calls that are resolved within 10 minutes is a progress metric, which may in turn impact the desired outcome of answering calls within 5 minutes.

OUTCOME: A clear set of expectations has now been identified, including, measures that will help gauge success objectively.

IV. What are potential solutions?

multiple solutions

To explore potential solutions, we’ll first need to identify relevant stakeholders that can help imagine solutions, and then use divergent thinking to dream of all possible solutions.

Who should participate?

Having the right people on the project will maximize the potential of finding successful solutions.

In my experience, it can be a good idea to have people that are frustrated by the current process, that may not be top achievers, to participate in innovation projects. This is because top achievers work so well in the current process that they may not want to change. It may be hard for them to think outside the box. In other words, we need to find people that feel and understand the pain of the current problem to participate.

I also recommend the use of RACI to identify key players that need to be involved:

  • The product owner(s) / sponsor(s) / stakeholder(s): Who needs this project?
  • The scrum master(s) / project manager(s): Who’s managing progress of this project?
  • The team member(s): Who’s helping execute on this?
  • The subject matter expert(s): Who has special knowledge or skills that we need to consult? Who are the ones that live this process? Customers? Agents?

Without a clear solution or detailed project plan just yet, it is normal to involve additional players later on. Right now, let’s focus on involving the core people that are impacted by this problem.

Exploring solutions


Now comes the fun part. It’s time to identify solutions.

I will not discuss in too much detail processes by which teams and individuals solve problems – this demands deep knowledge of a specific industry, and special skills that I probably do not have. I do however recommend familiarizing ourselves with the concepts of Idealized Design and divergent thinking as frameworks to help think of solutions and answer the following questions:

  1. What’s the ideal solution? (If we don’t know what we want in an ideal world, how will we know what we want under constraints?)
  2. What’s preventing us from getting there today? (What constraints exist?)
  3. What’s the first step that we can take toward that solution? (Work backwards from the ideal solution to what is possible today under constraints. There may be multiple steps to eventually achieve the ideal solution, but what’s the first step that we can take? What’s the second?)

Another valuable resource that has helped me with problem solving is The Art of Problem Solving

Once a series of potential solutions have been scoped out, I recommend for the project manager to work with relevant players to:

  1. Describe the solutions in detail including:
    • What it is;
    • What impact is expected (both positive and potentially negative);
    • What resources are necessary;
    • Potential risks
  2. Rank solutions by a set of criteria relevant to the problem and the organization
  3. Seek agreement with stakeholders on which solutions to test
  4. Design experiments that can prove the effectiveness of the solutions chosen. This can take the form of a scaled-down version of the full solution, a fake back-end where the solution is launched without the full infrastructure or resources necessary to support it, or even vaporware if one is testing for market need.

The reason that I recommend testing solutions before changing processes is to minimize risk. Should a solution not produce the expected results, only limited time and resources would have been sacrificed.

Once the list of solutions to test are chosen, the project manager will draft project plans including a timeline with clear deadlines and deliverables. This ensures that all necessary tasks are outlined for accurate implementation.

OUTCOME: We now have a list of solutions to test, including a detailed project plan.

V. Does the solution work?

plan vs reality

Managing progress

To ensure that the project runs as planned, the project manager will be responsible to manage and report on progress. Questions that the project manager needs to ask include:

  1. Are we on path to the next milestone(s)?
  2. What challenges are we facing?
  3. Do adjustments have to be made to the project plan based on latest progress?
  4. Are we discovering new insights as work is done on this? Should the end solution be adapted now that we know more?

Many project management methods exist out there to help answer the above questions. In the context of start-ups that need quick validation and delivery of solutions, I recommend adopting an agile approach to project management.

Reviewing test results and identifying next steps

After experiments around solutions are done, it’ll be time to assess results.  Did we meet our SMART goals?

Specifically, all stakeholders and players need to:

  • Compare final results to initial expectations;
  • Understand where things went wrong, why, and how we can prevent that in the future;
  • Understand where things went well, why, and how we can consistently achieve this in the future.

It is especially important to review results of both progress metrics, that assess how specific initiatives and solutions performed, and outcome metrics, that assess whether the desired outcome was achieved. The ideal scenario is one where both progress and outcome metrics changed as expected, but there can certainly be scenarios where both were not impacted, or where the progress metric changed as expected yet failed to impact the outcome.

Insights gathered at the review meeting will help us decide whether to:

  • Cancel a solution due to its ineffectiveness; or
  • Iterate a solution and further experiment to see if additional improvements can be achieved before scaling its implementation; or
  • Scale a solution to the entire organization / process.

OUTCOME: By the end of this QI process, there is evidence to support the effectiveness of different solutions, and decisions are ready to be made as to whether to scale their implementation.

VI. We solved it. Are we done?

We’re never done. It’s human nature to never be satisfied. Once we’re on top of a peak, we will naturally shift focus onto the next peak to conquer. If we became market leaders in one segment, we’d shift focus to widen our lead or conquer other segments. We have the same mindset in our personal lives: The moment that I find parking in a downtown area where parking is scarce, my focus naturally shifts to whether I could have found parking closer to wherever I was going.

Fact is that most problems that we’re solving today are the same ones that our ancestors were solving hundreds of years ago. Love, communication, food, shelter,… Each generation solves it differently, using technologies available at the time. We used to communicate with smoke signals, and now we have emails and Twitter. We used to farm our own food, and now we have food delivered via apps. We used to listen to neighborhood announcements for news, and now we have email newsletters (so many of them). These fundamental problems will never ever disappear, and we will continuously innovate to solve them differently.

Whether our company will be leading these innovations and disruptions is another story. In the “Innovator’s Dilemma,” Clayton Christensen makes the argument that some of the best companies risk becoming irrelevant because they are too well managed. Sounds ironic? I highly recommend reading his book.

How do I project manage?

Considering that project management skills are essential to the successful execution of innovation projects, I recommend reading up on the subject should anyone be unfamiliar:

Recommended exercise

The next time that a problem comes up, let’s take a moment to investigate the problem, and accurately define it, before starting to solve it.

Subscribe on the right for new insights every week!

start⬆Mngr handbook pt. 3: Leadership and coaching go hand in hand

start⬆Mngr handbook pt. 3: Leadership and coaching go hand in hand

First, a personal story.

Taylor (fake name) joined my team after spending years as a technology consultant with a big tech company. As a team member with experience working on large projects, I let the Taylor lead an important innovation project on top of Taylor’s day-to-day duties. My assumption was that Taylor had some experience with project management, so could hit the ground running. Therefore, I simply set the goal for the project, clarified what we needed as deliverables, and let Taylor run with it.

After a few weeks, I heard no news of the project, so I actively inquired about the status with Taylor. He responded: “Yup, everything’s fine and I’m on top of it.” Another few weeks passed and I started to notice that milestones were missed and we were running behind schedule. I checked in with Taylor again, and we discussed what was happening. Turns out, our initial timeline was too aggressive and we had other urgent fires to fight, so the project was de-prioritized. “OK…” I said, feeling somewhat disappointed that I had to reach out to hear this. I expected this type of news to come to me. However, I let it go. My thought was that Taylor simply has a different project management style than me and had things under control.

It was unreasonable on my part to expect Taylor to be able to lead the project independently

The good news is that the project was eventually completed. The bad news is that it was completed weeks past the initial deadline, and the end result did not meet our initial expectations. Needless to say, I was not very happy with the way Taylor managed the whole project – not so much that it failed to meet initial expectations and timelines, but that I had no clue on what was happening throughout the process. What kind of project management was that?

During a one-on-one with Taylor, I brought up my disappointment with the way the project was managed, and asked why I was kept out of the loop. To my surprise, I learned that Taylor had no idea that I needed to be briefed. He assumed that as project lead, nobody else needed to be bothered with status updates. This baffled me. I was the project sponsor, an important stakeholder, and yet this project manager didn’t think that I needed to be briefed on progress. You can imagine how upset I was.

At this point, I couldn’t help but ask Taylor: “What projects have you managed where the stakeholder didn’t care about status updates?”

Taylor said: “I’m not sure. This is the first time I’ve led an entire project. In the past, I’ve only helped to coordinate the change management side of projects.”

How foolish I felt. Here I was, thinking that Taylor was able to lead a project, having had experience project managing large IT projects. Yet my assumption was wrong. It was unreasonable on my part to expect Taylor to be able to lead the project independently without any assistance. It was even more unreasonable for me to expect the project to be managed a certain way without ever communicating these expectations first.

So what did I learn? Never to make assumptions about a person’s abilities. If we have assumptions, we need to assess and validate them. The alternative is unreasonable to both the team member and ourselves: The team member ends up with unreasonable expectations that they can never meet, and we are guaranteed to be disappointed. The reality is that most team members need some support and coaching before they can run on their own. In other words, to be effective leaders, we need to be effective coaches.

So let’s make sure our team members have what it takes to succeed and meet our expectations. In part three, we’ll explore critical leadership concepts that will help us:

  • Coach team members;
  • Delegate and share responsibility; and
  • Ensure that team members meet our expectations.

What are some great reads on coaching?

Why is coaching so important at startups?

At start-up companies, leaders can’t just set a vision and delegate. With limited resources, we often work with ambitious, extremely smart, yet inexperienced team members that don’t always have the  skills necessary to carry out their tasks. Young team members tend to not have the project management, communication, or even technical skills necessary to succeed in their roles. That’s where we fill the gap and help them grow.

At one end of the spectrum, team members need to learn something completely new from scratch, and at the other end of the spectrum, team members can be so proficient that we only need to set a goal and delegate a responsibility entirely. Reality is that most team members will be somewhere in between these two extremes with regard to a certain skill.

As leaders, I believe that it’s our duty to help individuals grow toward mastery, setting the expectation that we want them to one day take ownership of certain responsibilities entirely. To achieve this, we need to coach.

At its core, a good coach first analyzes the current abilities of a team member to gauge what type of leadership the individual needs with a specific task or skill (e.g. direction, coaching, support, or delegation). Once we know what the individual needs, we will adopt the relevant approach, communicate our intentions and expectations to the team member, and work together to advance toward delegation.

The rest of this blog will expose tips and insights that will help us throughout this process.

How do I coach?

We’re going to take a page from the Putting the one minute manager to work to remind ourselves of how to train team members on new skills:

  1. Tell (what to do)
  2. Show (how to do)
  3. LET the person TRY
  4. Observe performance
  5. Praise progress or Redirect

As practical advice, reprimands should not be given until a person has proven that they can successfully achieve the desired task. Reprimands are reserved for situations where an individual failed to achieve something they are capable of. When teaching a new skill, we need to focus on coaching and praising what they’ve done right. Reprimanding a team member before they experience success is unreasonable and will de-motivate the team member in the process.

What if I don’t have the knowledge to coach a specific skill?


As leaders, we are responsible for setting a vision. This responsibility however does not always translate into knowing how to achieve the vision, nor into the ability to mentor team members on how to achieve the vision.

The one-minute manager system assumes that leaders have the skills to train an individual, to provide direction, coaching, and support. Yet that’s not always the case in real life.

For example, a Chief Financial Officer may have a developer as direct report to help build software applications that facilitate financial forecasts and reporting. Yet it’s unreasonable to expect the CFO to be able to train or mentor the developer and help grow their technical skill set.

In such scenarios, when we are not the best to train a direct report, external help needs to be leveraged: There may be someone from another team or someone from outside the company that is better positioned to coach. Should there be a lack of mentors at the organization, an individual can also rely on books and educational courses to learn independently. However, nothing replaces an experienced human mentor.

Independent of how training is performed, it’s important to set clear expectations with team members as to whether the direct manager or another person will be mentoring them. A team member may also need multiple mentors should they require different skill sets.

If an organization lacks mentors for junior team members, there is only one choice: Hire more experienced individuals. This is especially important when training and coaching new managers, whom we depend on to set and communicate expectations, in addition to keeping goals aligned between teams. In an ideal scenario, there should be at least one management mentor for one or two first-time managers, and one technical mentor for every three or four junior individual contributor. Yet this ratio is rarely met at early stage start-ups: They usually want to save on salary cost and hire smart yet inexperienced individuals straight from school. That’s a mistake.

Having too many junior managers means that the organization learns and grows by trial and error. This behavior lengthens the time required to identify a clear company strategy, develop effective and efficient processes, and slows the pace of growth. For most start-ups, there is limited time to achieve critical goals, so there needs to be a healthy ratio of experienced mentors to first-time managers.

In my experience, the most effective mentors have worked at different organizations or industries that have faced similar challenges. This enhances their ability to help junior managers gain new perspectives, think outside the box, and at the very basic level, teach the overall role of a leader.

If hiring experienced managers is a luxury that our start-up can afford (yay!), there is one additional caveat to consider: Not all experience is the same.

Let’s assume that we’re a 50 people start-up with $2M annual revenue, wanting to grow to 200 people and $20M annual revenue, and we’re looking for a new sales leader to help us get there. The logical solution is to find sales leaders working at similar companies that have achieved $20M in annual revenue. However, we need to acknowledge that not all leaders in those positions will have the relevant experience to help us.

For example, a sales leader at the ~20M annual revenue company may have started their career when their company had already achieved ~15M in annual revenue. This indicatesthey have the experience of working in an organization that we want to eventually become, but maybe not the experience to help us get there. They achieved success with a support system of a company that’s doing $15M a year, not with a system that’s currently doing $2M a year. They may be completely lost working with a smaller budget, team, and different culture.

So when choosing an experienced leader, the ideal scenario is to find someone that is not only in a position that we want to achieve, but that has also worked to grow their organization from a position similar to our position today. This means that the individual has already made the mistakes that we foresee making, and has gained relevant insights on how to tackle these challenges better.

What do I delegate?


It’s a good idea to regularly assess if there are responsibilities that we can delegate and transfer/share ownership on. This ensures that team members get new growth opportunities and that we keep an optimized workflow. Here’s a simple exercise that has helped me identify what to delegate:

  1. List all the responsibility that I currently have, and all the items on the to-do list and backlog.
  2. Next, ask myself “What unique value do I add to each task?”

If I truly add a unique value to a given task or responsibility, then I keep it. If we are not sure, asking some additional questions can help:

  • Am I the best person to perform this task or responsibility? If we are not the most skilled individual to perform this, or if someone else can dedicate more energy to achieving it better, we should work toward delegating it.
  • Am I positioned to maximize the impact of this task or can someone else have the same or even greater impact? Let’s compare two tasks: Give a lesson on time management to all team members; and advising one specific team member on time management. In the context of maximizing impact, giving a lesson to the group impacts a much greater number of individuals than advising one specific person, so the lesson is more important to focus on. The question then becomes whether we are best positioned to do that, or if someone else can do the job better and/or impact an even greater number of people.
  • Am I complaining that I never get to perform a certain responsibility because I’m always bogged down by another one? Then it’s time to assess which responsibility has a higher priority, whether they are both valuable to the team mission, and who is the best person to carry either of them out. Assuming that both responsibilities are critical to the team’s mission, work toward delegating away one or both responsibilities should another individual be better positioned to execute. Continuously not having the time to perform a responsibility is often a strong indication that there is an opportunity to delegate.
  • Am I constantly catching up on day-to-day work and not strategically planning the next steps for the team? As leaders, our core responsibilities is to plan for the future, to think of more effective and efficient ways to achieve our team mission and company goals. To that effect, it’s important to regularly allocate time for strategic planning. If we don’t have the time to do that, there is likely an opportunity to delegate away some of our day-to-day, non-planning work.
  • Do I enjoy doing it? Do I enjoy a task so much that my day would become too miserable should I delegate it?

It’s normal to feel anxious delegating certain tasks we hold dear, thinking that others may not know what to do right away. That’s normal. That’s why a leader needs to start with a directive approach, and work toward coaching and supporting team members. A leader also needs to expect team members to make stretch mistakes when doing things for the first time. It’s a sign of progress.

Who do I delegate to?

A contractor is on a mission to build a house. He assigns floor work to a carpenter and sink installation work to a plumber. Logical, right?

Similar to the foreman, it is a good idea to delegate work to individuals based on their expertise, skills, in addition to their interests and personal goals.

Delegate thoughtfully and team members will reward their leader with trust and loyalty. Delegate blindly and team members will hate their jobs. To help assess what to delegate to whom, here are some questions I ask:

  • What motivates the team member?
  • What is that individual’s strength and weaknesses?
  • Does the task match the person’s interest and strengths?
  • Does that person have the appropriate resources? Including time and tools.

To help team members grow, it’s a good idea to continuously experiment and expand the scope of responsibilities to delegate. This allows team members to prove themselves little by little, and taste success along the way. A thoughtful leader will first delegate something that a team member will  surely succeed in, then move toward bigger responsibilities where they need more time to learn and master.

Of course, there will be times when we need to delegate a task that nobody is interested in. For example, we may require a data scientist to perform a data entry task. In those circumstances, it helps to communicate why the task is important – this gives the individual purpose, even if it doesn’t add to the individual’s long-term goals and motivations. Of course, doing this repeatedly runs the risk of diminishing an individual’s overall interest for their work.

Recommended reading

Who am I?

To help adopt the principles of the One-Minute Manager system, let’s take a step back and look at ourselves in the mirror. The more self-aware we are, the more effective we will be at identifying the appropriate approach to adopt when interacting with team members. To help get started on the journey to self-awareness, allow me to share a couple personality tests below:

How does self-awareness make us better leaders? It starts from leveraging one’s strengths to add a unique value to the team, and more importantly, acknowledging one’s weaknesses to not let them get in the way of doing a good job. For example:

  • A manager with a commanding personality may enjoy delegating and be an effective macro-manager, but they will need to make sure to not forget coaching and supporting new players before they can be expected to run on their own.
  • A introverted manager may need to make an extra effort to connect socially with their team (e.g. have lunch with the team), and commit time to observe their team members’ behavior and praise or reprimand accordingly.
  • A flexible manager will need to learn to be authoritative and strict when delivering specific, non-arguable reprimands.

How do others lead?

I’ve assembled below some additional resources on management and leadership. It’s a good idea to tie back any learnings from these resources to a management system like OMM. This helps us understand why OMM tactics work, and also allows us to build skills and knowledge on top of its basic foundation.

Recommended exercise

Let’s ask ourselves: “Have I been disappointed by the performance of a team member lately? If so, have they had the necessary coaching to actually succeed? Were they ready to take on that challenge independently?”

Subscribe on the right for new insights every week!

start⬆Mngr handbook pt. 2: How to set clear expectations and motivate the team

start⬆Mngr handbook pt. 2: How to set clear expectations and motivate the team

First, a personal story…

On an ordinary afternoon, an A-player, superstar, technical genius on the team (let’s call her Casey), sent me an impromptu same-day meeting invite. I’ve always been suspicious of meetings without pretext. My guess was that Casey needed my help with something urgent, or wanted to communicate something special. In either case, it’s my philosophy was to deal with such situations sooner rather than later, so I simply walked over to the Casey’s desk and asked if they wanted to sync up right away.  She agreed.

Right after we settled into a meeting room, Casey told me that they had taken up a job at another organization.

This wasn’t a total surprise, as Casey had asked for a raise a few weeks earlier, which I declined (we have a company policy to discuss compensation annually, ensuring consistency for all team members). I went ahead and congratulated Casey on their career move, and out of curiosity, asked if they would have stayed on if the desired salary increase was given. Casey answered: “Maybe, but it would only have delayed my departure. I’m kind of glad I didn’t get it.”

I realized that I had failed to set clear expectations with the individual

That response puzzled me. Casey wasn’t leaving just because of pay (my initial assumption), but rather because they were unhappy with their job. How could this be? I had a trusting relationship with Casey, held regular one-on-one meetings, and had an ongoing professional development conversation, where we’d discuss her interests and try to find project opportunities that aligned with those. Aside from the salary issue, everything else seemed fine.

Why was this outstanding team member unhappy?

I got part of the answer by further chatting with Casey and reading her exit interview: Among smaller frustrations, Casey had no clear sense of what was expected, what success meant, and in turn, always felt unaccomplished. Interesting… I thought.

The question then begs… How could someone so successful, that I always praised feel that way? At every meeting, I only had good things to say: “I’m really happy with your performance”, “You’re rocking it”, “It’s a pleasure to be working with you.”

For weeks, I was trying to figure out how Casey could have felt unsuccessful. I then got another piece of the puzzle while randomly chatting with a colleague, a friend of Casey’s at the office:

“Casey was unhappy because there was always unfinished work at the end of the day, which she would continue at home, often disrupting her family life. She didn’t know when it was OK to stop. At the same time, Casey never really knew how well she were performing. Every time that you’d say “good job,” it added to the confusion and nuance: Casey simply didn’t understand what she had done that was so good.”

At the time, I didn’t really know what to make of this insight. But skipping ahead a few weeks, after discussing this with my leadership coach, I realized that I had failed to set clear expectations with the individual, failed to design a personal growth plan, and failed to be specific in my praising. The team member was going above and beyond relative to my expectations, but I failed to ever communicate what these expectations were. I’m not even sure if I truly had any expectations beyond working hard and doing their best. This left Casey constantly guessing about whether she was successful. And as most top performer in such a situation, Casey simply did more and more, better and better, without a clear goal. Over time, this likely drained her.

Upon further reflection, I realized that over years of formal education and examination, society has trained many of us, especially STEM students, to expect leaders to set clear goals and define success for us. We gauge our performance and areas to improve from report cards. We’ve rarely had to define success and set expectations by ourselves. So when we land a job where performance isn’t as clearly communicated as in a report card,  we feel lost. High performers that strive to beat expectations and earn A+ marks may not know how to interpret nuanced feedback, or gauge their performance independently. This is especially true for people straight out of school, and for jobs at start-ups where the definitions of success isn’t always clearly defined, and changes often over time.

It was my job as a leader to set personal expectations and goals for team members, and to help them continue their development. Even a simple expectation around timeline for projects or tasks would have helped the person understand what success looks like. Leaving people to independently figure out their success criteria may be asking too much if the individual has never done it. It’s a skill that needs to be learned. In short, I failed as a leader to set clear goals.

So let’s explore how to help team members define success and avoid confusion.

In part two, we’re going to discuss the basics of leadership. We’ll introduce a management system to help us maintain consistency in our interactions with team members, and explore important resources to help us:

  • Communicate clear expectations to team members;
  • Help team members meet expectations;
  • Track team member progress; and
  • Share constructive feedback.

What are some great reads on leadership?

The following two books provide a solid introduction on how to properly set expectations. I managed people for two years before being exposed these concepts, and certainly regret not having had this knowledge on day one. It’d have save my team and myself a lot of frustrations. They each take 45min to read, so we really have no excuse to skip them.

  • The One Minute Manager: The one minute manager (OMM) is a great basic management system that I recommend adopting. Having  a system in place helps us be consistent in our interactions. I’ve found the following concepts particularly handy:
    • Agreeing on expectations and goals early
    • Praising and reinforcing desired behavior and actions with specificity
    • Reprimanding if individual failed to achieve a desired behavior they have successfully achieved previously with specificity
  • Putting the One Minute Manager to Work: This one helps us implement the concepts explored in the OMM. While not as mind-blowing, I’m of the belief that success comes down to execution. And this book helps execute. What I personally found useful include:
    • 5 steps for training a learner to become a good performer
    • PRICE system

Beyond this point, I will assume that all readers have acknowledged the concepts introduced in the above readings.

How do I implement a management system?

The table below shows an example of how we can use the OMM’s PRICE system to plan and set goals.

In the context of management, the most used categories of goals includeproject goals (e.g. design a new feature / build a house), team or organizational goals (e.g. hit sales target, keep retention at x%), and individual performance goals (e.g. ability to query in SQL, ability to manage time independently). All three types of goals can benefit from the PRICE system as a way to agree on the specifics and keep track of our progress.

PRICE System Step Pinpoint + Record Involve Coach + Evaluate
Details of … Project goal OR Team goal OR Individual goal What are your expectations? Why?
What is the measure of success / performance?
What is your plan on sharing these expectations with the team member? What will you be looking to praise? When/how will you dedicate time / find time to praise? What will you be looking to reprimand and avoid? When will you dedicate time to reprimand?
EXAMPLE TEAM GOAL: Sales team goal Hit $50,000 in new monthly revenue to maintain growth at 25% over past quarter.

This translates into: 20 new leads per week per agent; $15,000 new revenue per week per agent.

Expose goal at beginning of month; showcase progress via email report weekly

Specifically, report on “% to goal completion” weekly and monthly, segmented by agent name.

Identify team members that are on their way to hit or surpass their goals.

Specifically, praise individuals that hit 70% of weekly goals by Wednesday, and those that surpass their weekly goals.

Personally speak with team members that fail to meet goals on consecutive weeks.

Specifically, look for lazy team members, and those that are holding less calls than others.

How do I set clear goals?

To ensure that there is clarity on expectations, I recommend adopting a SMART approach when setting goals. Being specific as to what we want to achieve helps to evaluate whether we’re making progress or actually achieved it.

What is the different between result vs. progress oriented goals?

Result oriented goals are achievements that one can hang on the wall: e.g. A series A investment into a company, a championship trophy, 5 years experience working at ______, etc.

Progress oriented goals are activities that we do while trying to achieve the result oriented goals: e.g. Improving the sales process at a company, training every morning to prepare for championships, taking a course to learn how to do a job or task better, etc.

In the context of setting goals, it is important to set both result oriented goals, as well as progress oriented goals. Whereas result oriented goals provide vision, progress oriented goals show team members a path to achieving the vision and feel successful along the way.

Assuming that a company’s end goal is to go IPO or hit $100M in annual revenue, it will likely take years to achieve its goal. So the journey needs to be paved with progress oriented goals that help team members feel advancement, see a path to success, and focus on learning relevant skills.

There are also many more opportunities to celebrate progress than there are opportunities to celebrate results, so teams that focus on progress are much more motivated. And when end goals are missed (which happens at the best of organizations), teams that focus on progress and have a growth mindset tend to reflect and make the necessary changes to try again, while teams that only focus on end results have a tendency to simply feel unsuccessful and beat down.

Other readings on goal setting I’ve found helpful:

How do I share constructive feedback?


As part of our job in helping people advance their professional development, we’ll come across situations where we wished an individual could have done better on XYZ. It may not always be easy to give such feedback, nor be accurately heard. Yet it’s our duty to actively give feedback, positive or negative. I’m therefore going to share a framework that can help achieve this without getting personal.

We explored in part one a communication framework to help assess whether a manager’s assumptions about a team member’s feelings are accurate. The same framework can be used to share feedback with an individual. Allow me to illustrate:

  1. First expose observations: As a starting point, we need to communicate specific actions, facts and events observed that led us to feel how we feel. These are non-negotiable and non-arguable elements. (e.g. I see that you’ve started participating and sharing your thoughts during brainstorming sessions on…)
  2. Next expose how you interpret these facts, your feelings: We will share how we interpreted these observations, and provide an opinion on whether the events were good or bad based on the context. (e.g. I’m seeing that as a sign that you’re really becoming comfortable sharing your thoughts and ideas with the team. Do you feel that way as well? )
  3. Give feedback on how to improve and grow: Finally, based on the events and interpretations shared, this is where we provide specific feedback to help an individual improve, call out something that we don’t want to see again, or call out something that we want to see more of. (e.g. I’m really happy that you’re putting the effort to frame your thoughts and sharing them with the team. I’d love for you to keep doing this. Please continue preparing your thoughts and allowing yourself to speak up at team meetings. Your ideas are very much appreciated.)

Special note on praising and giving positive feedback

happy face

Praising needs to start happening early in a person’s learning, especially when they get it right for the first time. It rewards good behavior, keeps them motivated, and guides an individual toward the ultimate target. When praising, it’s good practice to be specific in what a team member did well.

  • Specific praise: “Thank you for helping that client explore all potential options.”
  • Unspecific praise: “Good job with that client”

Relating back to results vs. progress goals, let’s also acknowledge that we need to praise both: Team members need to feel good about making progress and achieving results. If we only praise progress, it may undermine the need for team members to achieve results. And only praising results may lead to an unrewarding and even frustrating path to the end result, especially if it’s a long project, or if the end goals are still unclear.

Recommended reading:

Special note on reprimanding and giving negative feedback

 sad face

Reprimanding should only start after an individual has succeeded on a given expectation, and knows what “good” behavior looks like. It’s intended to reinforce good behavior once they’ve been able to achieve it.

Reprimanding before an individual has had a chance to succeed demotivates them and sets unreasonable expectations. How can we expect someone to get it right before they know how to get it right? It’s like expecting a person that has never skated in their life to win gold medal at the olympics for speed skating. Unreasonable. There is a process that we need to follow to properly guide team members toward success. We’ll explore how to coach and train individuals in part three of this handbook.

After a person has experienced success, a reprimand re-enforces the view that the goal continues to be important, that they have achieved it before, and that they can do better.

Similar to praising, reprimanding should also be specific:

  • Specific reprimand: “I saw that you dismissed a client’s idea before they had a chance to entirely communicate it. I’m disappointed that you failed to actively listen. You’re capable of achieving this as I’ve seen it before, so what happened?”
  • Unspecific reprimand: “I’m disappointed with what happened with that client.”

Recommended reading:

How do I make sure I’m heard?

be heard

While trust serves as a solid foundation to leadership, communication is our main tool. A leader that can’t effectively communicate their vision, their thoughts, or their decisions brings no value to the team: They don’t help set a destination, nor facilitate a solution to get there. As leaders, we must therefore learn to communicate effectively. Here are some outstanding resources on communication strategies to help us be heard:

Since most presentations today rely on digital slides or powerpoint, here are some good articles on how to avoid boring an audience:

If there’s one thing to recognize when giving a presentation, it’s that the audience can read much faster than the speaker can talk. With that in mind, I recommend to avoid putting into slides content that we plan to voice. Instead, slides should be used to complement what we have to say and emphasize a point: e.g. pictures, diagrams, or quotes that one wants to emphasize. This ensures that the audience is focused on what we have to say.

How do I make sure I’m understood?

Recommended reading: A case of misunderstandings

Saying something is not difficult. Saying it in a way that communicates the message accurately and that everyone understands is difficult. Too often, what we say is interpreted differently by different team members.

To be an effective communicator, we need to simplify and clarify.

Simplify the message

One method to simplify a message is to write it down and to strikethrough every element that doesn’t add value to the core takeaway. Any content that doesn’t directly help communicate the main message distracts the audience.

It’s a good idea to test one’s speech with a colleague to see if they remember the main takeaway that we intend to communicate. A simple message should be easily remembered and repeated by others.

Clarify the message

Beyond a simple message, a clear message ensures that the audience interprets the speaker’s words the way they are meant. This is accomplished by:

    1. Asking a member of the audience to repeat what we said;
    2. Providing relevant examples or analogies to illustrate the concept;
    3. Showing case studies to put things in context;
    4. Answering questions to clarify any confusions.

As best-practice, it is recommended to always communicate why: At the beginning of any message, simply describe why we’re here, why are we talking about this, why this is important, etc. This ensures that everyone is on the same page as to our goal.

How do I make the time to lead?

time agenda

To put the OMM management system (or any management system) into practice, we need to make the time to observe behavior, review work, prepare feedback, etc. More importantly, we need to recognize that this is part of our job, our time commitment.

Yet finding and dedicating time to managerial duties can be a challenge for all managers, especially new managers that may still be used to prioritizing individual work.

One solution is to schedule and block time for these tasks on the calendar, and respect it (this latter part is hard). Another tip is to be specific in describing managerial tasks to accomplish, helping to set clear scope to a task.

  • Specific task: Observe when a team member achieves _____ and praise.
  • Unspecific task: Observe team member behavior.

It’s important to realize that managerial work take more time to accomplish, so there is often no immediate reward. Individuals transitioning into leadership roles from non-managerial roles may find it particularly difficult to not feel instantaneous gratification everyday. To help with this change, a new manager can breakdown milestones into smaller tasks to feel constant progress. And to feel rewarded, I encourage everyone to celebrate every small accomplishment (e.g. give yourself a cookie every time you finish writing a chapter of the team’s quarterly report).

Recommended exercise

Let’s take some time to ask each team member: “Do you know what the success criteria are in your role?”

Subscribe on the right for new insights every week!