Launch Tomorrow

Landing Pages for your Lean Startup

  • Free Tools
  • About
  • Members
  • Corporate Innovation
  • Blog

How to pivot your business during lockdown

April 24, 2020 by Luke Szyrmer Leave a Comment

Recently I’ve been revisiting the launch and pivot process in my research, in an effort to help founders and innovators change strategic direction in their business. Here is an old piece I wrote that should give you concrete metrics to track your progress. These were specifically chosen to be relevant, independently of what budget is available (and thus hopefully make it more relevant nowadays.

VCs and startup investors often say they’re looking for hustle in early stage founders. But that feels vague. And honestly, on its own, it’s not particularly useful feedback. More of a sophisticated way to end a pitching session they don’t want to be hearing.

Until now.

There are a few leading indicators you can use to keep yourself accountable, and to make sure you actually are hustling (and you’re not falling for your own PR).

The following four operating metrics say a lot about an early stage startup’s chance for success.

1. Number of pitches

A critical leading indicator metric of early stage success is how many pitches are you making each day (even if you aren’t trying to sell)? By “pitch”, I mean any attempt at asking someone for something, even if it’s just information. For example, this could mean approaching prospects for customer discovery or customer development interviews.

If you are making them, then you are learning more about your audience and iterating towards something that is likelier to work. Also, you are converting some people, which means that you can then continue to build on that as time goes on. This includes:

  • both outbound pitches, whether for sales or for customer interviews,
  • inbound marketing, such as free content you create which you need to put in front of your target audience.
  • advertising (impressions)

With inbound, unless if you already have an audience, usually requires some form of gatekeeper pitching or payment. You to pitch media owners, journalists, editors to get coverage. Or you create content and just pay for advertising.
And then pay attention to any response you get.

At some point after you’ve done this for a while, you’ll know what people want and how to reach them and roughly how to sell them. At that point do it yourself a little bit and then it makes sense to delegate it to a professional salesperson to improve your closing ratios (if you need one).

That’s actually a pretty good metric, because it’s a leading indicator for all learning. And learning is the #1 goal of startup, in order to stop being a startup, and to discover a business model which works.

Notice how I’m not really including the “number of failures” or “failing fast”. That’s repeated so often in tech circles it’s become hollow and meaningless. I think being able to deal with rejection is possibly more important than being able to deal with “failure”, certainly in the tech startup world. Because even in technology the most important decisions that affect your startup or are made by people (customers, prospective co-founders, prospective employees).

To be fair, not every founder is a natural salesperson. But every serious founding team needs to be willing and able to face lots of rejection in order to go after their vision. In fact, the number of rejections a founder is willing to take is a good measure of how strongly they believe in their vision, product, or goal. If you have a goal you believe in, but you’re only willing to be rejected 10 times before you give up on it, you can easily end up being a genius in your own mind but giving up almost immediately once you start doing anything related to marketing.

2. Number of experiments

Another related metric is how many experiments are you running each week? If this is not at least 1, you are not going to get very far. Or other startups who are will run circles around you. Or you are trying to cram too much into one test, not really telling you anything useful.

This is more of a product or operational metric. Basically, the more thorough and organized you are with this, the faster you will learn what you need to know. It never ceases to amaze me, how documenting my own hypothesis and metric before running an experiment is very useful, when interpreting the result. Because it’s so easy to twist the results into what you want them to mean.

Most of the major technical breakthroughs result from lots and lots of experiments. They explore an area or technology with a lot of unknowns, including “unknown unknowns”. That’s why they’re surprising for everyone outside the founding team. Here’s a breakdown of roughly the number of experiment trials required to create a certain type of invention, based on patent filings.

numbers of experiments needed to achieve a breakthrough product

While this looks only at technology, the same principle is true in the case of proving the business model and finding a growth engine. By focussing only on tactics, you end up using exactly the same tactics as everyone else. So if everyone is reading the same 3-4 sources for ideas and trying exactly the same tactics at the same time, the tactics tend to quickly become useless. This the law of shitty clickthroughs happening–one growth hack a time. It’s so difficult and yet so vital to differentiate, if you are using exactly the same tactics as everyone else in your industry. Growth or business level experiments, and lots of them, are the only way to really discover an effective way of growing a startup.

Also, if you aren’t running any experiments, you are only delaying “learning moments”. And if you do ultimately fail for one reason or another, it’s because you’ve delayed so many “learning moments” for so long, that reality comes crashing down on you. And usually this results in the Dunning Kruger effect. You are just clueless, and being confident in what you’re doing only makes it harder to discover you are actually clueless. It’s also a different way of looking at cycle time, which is an important indicator for people like Sam Altman of YCombinator.

3. Back to basics with customer empathy

Many of the pivots required by the crisis require a change of customer type. Or at minimum a focus on a particular niche that currently have a lot going on. Like hospitals. Or Supply chains. Or Agriculture and food.

In that context, do you really understand your audience as well as they do themselves? Do you know their needs? Wants? What they dream about at night? Who they’re influenced by? What questions they have? What media they consume? What they typically do? What obstacles they struggle with?

Do you as the founding team empathize with the customers? Do you gather and systematize data on what they say and how they behave (as an indicator of subconscious needs)? Do you have a system for doing so, like Adrian Howard’s iterative personas and/or a hero canvas?

If you really have this covered, it will help you build something people want. It will help you do channel testing to discover how to reach them cost effectively. It will resolve many types of conflict among your own team, if you agree to formulate a test, and then gather data to prove which approach, option, or decision is right.

Your entire business model depends on it.

Most frequently, either founders aren’t aware of how important this is, or if they are, they only use this if they think it will further their own agenda (for example improving the user experience, regardless of the wider business context).

4. Goal setting and delegation

Probably another really big one is lame goal setting as a founding team, which impacts your ability to ship anything, particularly at the early stages. Knowing what you want to accomplish and giving your team deadlines. This is kind of related to:

  • succumbing to distractions (bight and shiny object syndrome)
  • indefinitely being stuck in learning mode
  • inability to delegate work.

Drifting along indefinitely is not good. And this is often left implicit, avoiding difficult discussions, and ultimately festering and resulting in things like cofounders leaving, etc.

If you really want to build a startup, at some point, you need to finish stuff as well as just learn. Which means you always need target completion dates, or at least timeboxes. In the early stages, these will tend to be very tactical and short term, because you are learning and you don’t want to commit to a “five year plan” if you don’t have any reason to do so, like revenue or traction.

Even if it means have a clear goal of what you want to accomplish in the next 2 week sprint and what that matters, that will help a lot. And also having everyone on your team agree that this is your goal, and how you will track it (so that it is objectively observable).

Admittedly, at first your only goal is to learn. But shifting slowly into execution mode, is inevitable as you start proving parts of your business model.

Most of the internal problems that I see with early stage startup founders boils down to variations of one of these four factors.

Key Takeaways

The 4 key areas to achieve a successful pivot during the lockdown are:

  1. Number of pitches or contact points with new customers
  2. Number of experiments you are running
  3. Revisiting your customer segments and re-establishing empathy
  4. Setting clear goals you and your team can work towards

<< Help Yo' Friends

Filed Under: assumptions, innovation, metrics, release planning, unknown unknowns Tagged With: covid, faster time to market, numbers

What is your biggest question about working remotely?

March 30, 2020 by Luke Szyrmer Leave a Comment

Just to pick up where I left off last week, my daughter and I managed to get back home. And currently we are under quarantine for 2 weeks. Fortunately, without symptoms so far. We're very lucky that so far nothing particularly bad has happened. And slowly the disease is starting to hit people we know or our friends' parents.

Today I wanted to ask about your shift to working remotely, especially if you haven't done much of that so far. I've run remote teams for a few years, so I'm hoping I may be able to help with any questions or concerns you might have.

On my end, I think the biggest new challenge is the childcare one–working in parallel with becoming a full time homeschooler. That means re=prioritizing. On the fly. Overall spending more time with kids is a good thing, but somewhat painful in the short term. For example, it's difficult to pretend business as usual, when a 5 year old pretending she's a mermaid in the background, flapping her plastic tail on the ground.

Just reply to this message with your question/questions or leave a question in the comments on the blog.

<< Help Yo' Friends

Filed Under: assumptions

Why improving requires change

February 18, 2020 by Luke Szyrmer Leave a Comment

This isn’t a how to post, as usual. Just an observation.

Photographer: Armand Khoury | Source: Unsplash

Quite often, an ambition to innovate is paired with an unwillingness to change.

Usually, the latter isn’t conscious. But it blocks you from finishing or shipping anything.

It can be quite subtle. In how people speak or collaborate. In pushing back. In sub-par levels of trust.

It might seem obvious at the face of it. Yet, it’s probably a common issue companies face when trying to become more innovative.

So before trying to convince anyone about a new product, you might be better off trying to introduce a smaller change of some sort, and seeing where the pushback comes from. And where the fault-lines actually lie. Even though it will create a conflict of sorts, it will highlight what you are up against.

Key takeaways

  • An ambition to innovate is often paired with an unwillingness to change.
  • Introduce a small change to test how a culture will deal with a bigger innovation.

<< Help Yo' Friends

Filed Under: assumptions, innovation Tagged With: testing

Why “work time” reduction is futile

February 13, 2020 by Luke Szyrmer Leave a Comment

One of the common anti-patterns which comes from a more traditional project management toolbox is estimating work time. This estimate is later used as a tool to hold employees accountable. To help managers steer the ship, while making sure that utilization stays high. In particular, the measuring stick for good management is that employees are efficient. Over time, employees take less and less time to do a particular type of task.

Call me crazy, but this feels short-sighted to me.

If you are looking improving output and velocity of work (as opposed to employee efficiency) it goes up significantly when you have a solid team dynamic. Where people reach out and help one another, especially if they have different skill sets required to ship a particular feature. This a classic case of conventional management wisdom not tying true causes and effects together.

Ultimately what you care about is finished work. And finished work comes about quickly when a good team dynamic exists, not when individuals are efficient. To be blunt, this comes down to peer pressure dynamics among team members. For a team to work, they need to know what to expect of each other.

This is most obvious in team ball sports.

Any given player needs to pay attention to what everyone else on the court is doing, in order to figure out where to go next. Yes there is a coach on the sidelines, and a captain on the court, but the responsibility rests with the individual.

As the game is playing, could you imagine the coach getting off the bench and running after every player with a stopwatch? Telling them–one after another–to run faster? Anyone who the coach wouldn’t be yelling at would slow down most likely. Because he’s not getting grief from the coach, so why should he care? This might be more acceptable during practices, but even then, it takes away agency from the employee. And emotional skin in the game.

If you start measuring and tracking individual employee output:

  1. You send a pretty clear message that the team doesn’t matter as much as what each employee does
  2. Success and failure rest at the individual level, how much they do relative to what their manager expects of them.
  3. The responsibility for finishing work lays on the manager’s/coach’s shoulders, and more importantly, doesn’t lay on the employee’s.

Maybe that’s acceptable, and you want the extra control, but usually this will reduce your output. Because the motivation lies solely in the relationship between the employee and the manager. A hub-and-spoke dynamic among a group of people. Not a real team.

Speaking for myself, adding elements of control doesn’t feel like it addresses the real issue of people not being self-motivated to work as a real team. It was kind of like buying additional dumbbells or books when wanting to shed a few kilos, like Keith Cunningham points out. It’s helpful to have a one new pair, but buying 100x more dumbbells on its own won’t burn the fat that much faster.

The root of the problem lies elsewhere: a misaligned team dynamic leading to a lack of individual motivation in the form of manager reprisal.

In contrast, if a player consistently gets the ball and fumbles with it or misses shots on goal, the team won’t trust him. That’s much more powerful motivator. They understand the consequences (to others) of dropping the ball on any given task.

Conversely, if there are a few good players who trust they can pass the ball to one another and to move their play forward, then things start to happen. Having a team dynamic where everyone chips in matters. Where people know who they can turn to if needed. So they’re implicitly clear on priorities, as they enforce them from one another.

Or if you do have a star player, at least the team self-organizes around helping that star contribute significantly on the playing field.

How does overemphasizing work time play out quantitatively?

In scenarios requiring serial processing of work to ship something, like for example a software feature, you naturally start to observe bottlenecks. In particular, a lot of partially finished but unreleased work lies in the “wait states”. The amount of time a given piece of work lies in between BA, development, and QA usually exceeds the amount of actual work time spent on it.

Here’s a case study. Same time, same year, same product, same technology stack:

aggregate work time vs. aggregate elapsed time for all stories

This was a team that I ran when developing a new product. And what I’m showing here is pretty common. Few delivery people can overcome their “cringe factor”. To figure out how much flab there is in a delivery process. In this case above, the aggregate elapsed time was over 3x longer than the work time.

Let’s say we achieve a nearly impossible feat: halve the amount of developer work time without reducing the rate at which features were completed. All that would mean is that the purple bar in the stack above would be smaller. But the overall elapsed time wouldn’t budge. The story would just wait longer for QA to be able to look at it.

Or halve the QA time required without reducing quality and rate of bug discovery. That would reduce the size of the gold bar. Which is admittedly a win at the story level. Because the elapsed time to the end of QA would go down.

But then you have the next step out: release elapsed time.

How much time elapses in between when all of the stories are QAed and the release goes out the door? If you don’t have a continuous delivery pipeline, it could be weeks. So it doesn’t matter if QA or dev go 20% faster, because the product won’t end up in the client’s hands until the product is released.

In practice all features are released together anyway. So even this pinkish elapsed time stack would need to be much taller when you count the time to release.

Key Takeaways

  • Increasing control doesn’t help a team be more efficient, if the team members aren’t motivated to collaborate.
  • Peer pressure similar to that in ball sports is a good model for how successful teams work together.
  • Strong-arming team members into finishing their work faster usually won’t impact the “elapsed time” before the features/product goes out to market.

<< Help Yo' Friends

Filed Under: assumptions, release planning, velocity Tagged With: elapsed time, work time

Disproved: Everything matters equally and I can just multi-task

January 29, 2020 by Luke Szyrmer 1 Comment

Usually, priorities come up in the context of time management and operational concerns. But did you know that having unclear priorities can also reduce revenue?

Launch Tomorrow

Landing Pages for your Lean Startup

  • Free Tools
  • About
  • Members
  • Corporate Innovation
  • Blog

How to pivot your business during lockdown

April 24, 2020 by Luke Szyrmer Leave a Comment

Recently I’ve been revisiting the launch and pivot process in my research, in an effort to help founders and innovators change strategic direction in their business. Here is an old piece I wrote that should give you concrete metrics to track your progress. These were specifically chosen to be relevant, independently of what budget is available (and thus hopefully make it more relevant nowadays.

VCs and startup investors often say they’re looking for hustle in early stage founders. But that feels vague. And honestly, on its own, it’s not particularly useful feedback. More of a sophisticated way to end a pitching session they don’t want to be hearing.

Until now.

There are a few leading indicators you can use to keep yourself accountable, and to make sure you actually are hustling (and you’re not falling for your own PR).

The following four operating metrics say a lot about an early stage startup’s chance for success.

1. Number of pitches

A critical leading indicator metric of early stage success is how many pitches are you making each day (even if you aren’t trying to sell)? By “pitch”, I mean any attempt at asking someone for something, even if it’s just information. For example, this could mean approaching prospects for customer discovery or customer development interviews.

If you are making them, then you are learning more about your audience and iterating towards something that is likelier to work. Also, you are converting some people, which means that you can then continue to build on that as time goes on. This includes:

  • both outbound pitches, whether for sales or for customer interviews,
  • inbound marketing, such as free content you create which you need to put in front of your target audience.
  • advertising (impressions)

With inbound, unless if you already have an audience, usually requires some form of gatekeeper pitching or payment. You to pitch media owners, journalists, editors to get coverage. Or you create content and just pay for advertising.
And then pay attention to any response you get.

At some point after you’ve done this for a while, you’ll know what people want and how to reach them and roughly how to sell them. At that point do it yourself a little bit and then it makes sense to delegate it to a professional salesperson to improve your closing ratios (if you need one).

That’s actually a pretty good metric, because it’s a leading indicator for all learning. And learning is the #1 goal of startup, in order to stop being a startup, and to discover a business model which works.

Notice how I’m not really including the “number of failures” or “failing fast”. That’s repeated so often in tech circles it’s become hollow and meaningless. I think being able to deal with rejection is possibly more important than being able to deal with “failure”, certainly in the tech startup world. Because even in technology the most important decisions that affect your startup or are made by people (customers, prospective co-founders, prospective employees).

To be fair, not every founder is a natural salesperson. But every serious founding team needs to be willing and able to face lots of rejection in order to go after their vision. In fact, the number of rejections a founder is willing to take is a good measure of how strongly they believe in their vision, product, or goal. If you have a goal you believe in, but you’re only willing to be rejected 10 times before you give up on it, you can easily end up being a genius in your own mind but giving up almost immediately once you start doing anything related to marketing.

2. Number of experiments

Another related metric is how many experiments are you running each week? If this is not at least 1, you are not going to get very far. Or other startups who are will run circles around you. Or you are trying to cram too much into one test, not really telling you anything useful.

This is more of a product or operational metric. Basically, the more thorough and organized you are with this, the faster you will learn what you need to know. It never ceases to amaze me, how documenting my own hypothesis and metric before running an experiment is very useful, when interpreting the result. Because it’s so easy to twist the results into what you want them to mean.

Most of the major technical breakthroughs result from lots and lots of experiments. They explore an area or technology with a lot of unknowns, including “unknown unknowns”. That’s why they’re surprising for everyone outside the founding team. Here’s a breakdown of roughly the number of experiment trials required to create a certain type of invention, based on patent filings.

numbers of experiments needed to achieve a breakthrough product

While this looks only at technology, the same principle is true in the case of proving the business model and finding a growth engine. By focussing only on tactics, you end up using exactly the same tactics as everyone else. So if everyone is reading the same 3-4 sources for ideas and trying exactly the same tactics at the same time, the tactics tend to quickly become useless. This the law of shitty clickthroughs happening–one growth hack a time. It’s so difficult and yet so vital to differentiate, if you are using exactly the same tactics as everyone else in your industry. Growth or business level experiments, and lots of them, are the only way to really discover an effective way of growing a startup.

Also, if you aren’t running any experiments, you are only delaying “learning moments”. And if you do ultimately fail for one reason or another, it’s because you’ve delayed so many “learning moments” for so long, that reality comes crashing down on you. And usually this results in the Dunning Kruger effect. You are just clueless, and being confident in what you’re doing only makes it harder to discover you are actually clueless. It’s also a different way of looking at cycle time, which is an important indicator for people like Sam Altman of YCombinator.

3. Back to basics with customer empathy

Many of the pivots required by the crisis require a change of customer type. Or at minimum a focus on a particular niche that currently have a lot going on. Like hospitals. Or Supply chains. Or Agriculture and food.

In that context, do you really understand your audience as well as they do themselves? Do you know their needs? Wants? What they dream about at night? Who they’re influenced by? What questions they have? What media they consume? What they typically do? What obstacles they struggle with?

Do you as the founding team empathize with the customers? Do you gather and systematize data on what they say and how they behave (as an indicator of subconscious needs)? Do you have a system for doing so, like Adrian Howard’s iterative personas and/or a hero canvas?

If you really have this covered, it will help you build something people want. It will help you do channel testing to discover how to reach them cost effectively. It will resolve many types of conflict among your own team, if you agree to formulate a test, and then gather data to prove which approach, option, or decision is right.

Your entire business model depends on it.

Most frequently, either founders aren’t aware of how important this is, or if they are, they only use this if they think it will further their own agenda (for example improving the user experience, regardless of the wider business context).

4. Goal setting and delegation

Probably another really big one is lame goal setting as a founding team, which impacts your ability to ship anything, particularly at the early stages. Knowing what you want to accomplish and giving your team deadlines. This is kind of related to:

  • succumbing to distractions (bight and shiny object syndrome)
  • indefinitely being stuck in learning mode
  • inability to delegate work.

Drifting along indefinitely is not good. And this is often left implicit, avoiding difficult discussions, and ultimately festering and resulting in things like cofounders leaving, etc.

If you really want to build a startup, at some point, you need to finish stuff as well as just learn. Which means you always need target completion dates, or at least timeboxes. In the early stages, these will tend to be very tactical and short term, because you are learning and you don’t want to commit to a “five year plan” if you don’t have any reason to do so, like revenue or traction.

Even if it means have a clear goal of what you want to accomplish in the next 2 week sprint and what that matters, that will help a lot. And also having everyone on your team agree that this is your goal, and how you will track it (so that it is objectively observable).

Admittedly, at first your only goal is to learn. But shifting slowly into execution mode, is inevitable as you start proving parts of your business model.

Most of the internal problems that I see with early stage startup founders boils down to variations of one of these four factors.

Key Takeaways

The 4 key areas to achieve a successful pivot during the lockdown are:

  1. Number of pitches or contact points with new customers
  2. Number of experiments you are running
  3. Revisiting your customer segments and re-establishing empathy
  4. Setting clear goals you and your team can work towards

<< Help Yo' Friends

Filed Under: assumptions, innovation, metrics, release planning, unknown unknowns Tagged With: covid, faster time to market, numbers

What is your biggest question about working remotely?

March 30, 2020 by Luke Szyrmer Leave a Comment

Just to pick up where I left off last week, my daughter and I managed to get back home. And currently we are under quarantine for 2 weeks. Fortunately, without symptoms so far. We're very lucky that so far nothing particularly bad has happened. And slowly the disease is starting to hit people we know or our friends' parents.

Today I wanted to ask about your shift to working remotely, especially if you haven't done much of that so far. I've run remote teams for a few years, so I'm hoping I may be able to help with any questions or concerns you might have.

On my end, I think the biggest new challenge is the childcare one–working in parallel with becoming a full time homeschooler. That means re=prioritizing. On the fly. Overall spending more time with kids is a good thing, but somewhat painful in the short term. For example, it's difficult to pretend business as usual, when a 5 year old pretending she's a mermaid in the background, flapping her plastic tail on the ground.

Just reply to this message with your question/questions or leave a question in the comments on the blog.

<< Help Yo' Friends

Filed Under: assumptions

Why improving requires change

February 18, 2020 by Luke Szyrmer Leave a Comment

This isn’t a how to post, as usual. Just an observation.

Photographer: Armand Khoury | Source: Unsplash

Quite often, an ambition to innovate is paired with an unwillingness to change.

Usually, the latter isn’t conscious. But it blocks you from finishing or shipping anything.

It can be quite subtle. In how people speak or collaborate. In pushing back. In sub-par levels of trust.

It might seem obvious at the face of it. Yet, it’s probably a common issue companies face when trying to become more innovative.

So before trying to convince anyone about a new product, you might be better off trying to introduce a smaller change of some sort, and seeing where the pushback comes from. And where the fault-lines actually lie. Even though it will create a conflict of sorts, it will highlight what you are up against.

Key takeaways

  • An ambition to innovate is often paired with an unwillingness to change.
  • Introduce a small change to test how a culture will deal with a bigger innovation.

<< Help Yo' Friends

Filed Under: assumptions, innovation Tagged With: testing

Why “work time” reduction is futile

February 13, 2020 by Luke Szyrmer Leave a Comment

One of the common anti-patterns which comes from a more traditional project management toolbox is estimating work time. This estimate is later used as a tool to hold employees accountable. To help managers steer the ship, while making sure that utilization stays high. In particular, the measuring stick for good management is that employees are efficient. Over time, employees take less and less time to do a particular type of task.

Call me crazy, but this feels short-sighted to me.

If you are looking improving output and velocity of work (as opposed to employee efficiency) it goes up significantly when you have a solid team dynamic. Where people reach out and help one another, especially if they have different skill sets required to ship a particular feature. This a classic case of conventional management wisdom not tying true causes and effects together.

Ultimately what you care about is finished work. And finished work comes about quickly when a good team dynamic exists, not when individuals are efficient. To be blunt, this comes down to peer pressure dynamics among team members. For a team to work, they need to know what to expect of each other.

This is most obvious in team ball sports.

Any given player needs to pay attention to what everyone else on the court is doing, in order to figure out where to go next. Yes there is a coach on the sidelines, and a captain on the court, but the responsibility rests with the individual.

As the game is playing, could you imagine the coach getting off the bench and running after every player with a stopwatch? Telling them–one after another–to run faster? Anyone who the coach wouldn’t be yelling at would slow down most likely. Because he’s not getting grief from the coach, so why should he care? This might be more acceptable during practices, but even then, it takes away agency from the employee. And emotional skin in the game.

If you start measuring and tracking individual employee output:

  1. You send a pretty clear message that the team doesn’t matter as much as what each employee does
  2. Success and failure rest at the individual level, how much they do relative to what their manager expects of them.
  3. The responsibility for finishing work lays on the manager’s/coach’s shoulders, and more importantly, doesn’t lay on the employee’s.

Maybe that’s acceptable, and you want the extra control, but usually this will reduce your output. Because the motivation lies solely in the relationship between the employee and the manager. A hub-and-spoke dynamic among a group of people. Not a real team.

Speaking for myself, adding elements of control doesn’t feel like it addresses the real issue of people not being self-motivated to work as a real team. It was kind of like buying additional dumbbells or books when wanting to shed a few kilos, like Keith Cunningham points out. It’s helpful to have a one new pair, but buying 100x more dumbbells on its own won’t burn the fat that much faster.

The root of the problem lies elsewhere: a misaligned team dynamic leading to a lack of individual motivation in the form of manager reprisal.

In contrast, if a player consistently gets the ball and fumbles with it or misses shots on goal, the team won’t trust him. That’s much more powerful motivator. They understand the consequences (to others) of dropping the ball on any given task.

Conversely, if there are a few good players who trust they can pass the ball to one another and to move their play forward, then things start to happen. Having a team dynamic where everyone chips in matters. Where people know who they can turn to if needed. So they’re implicitly clear on priorities, as they enforce them from one another.

Or if you do have a star player, at least the team self-organizes around helping that star contribute significantly on the playing field.

How does overemphasizing work time play out quantitatively?

In scenarios requiring serial processing of work to ship something, like for example a software feature, you naturally start to observe bottlenecks. In particular, a lot of partially finished but unreleased work lies in the “wait states”. The amount of time a given piece of work lies in between BA, development, and QA usually exceeds the amount of actual work time spent on it.

Here’s a case study. Same time, same year, same product, same technology stack:

aggregate work time vs. aggregate elapsed time for all stories

This was a team that I ran when developing a new product. And what I’m showing here is pretty common. Few delivery people can overcome their “cringe factor”. To figure out how much flab there is in a delivery process. In this case above, the aggregate elapsed time was over 3x longer than the work time.

Let’s say we achieve a nearly impossible feat: halve the amount of developer work time without reducing the rate at which features were completed. All that would mean is that the purple bar in the stack above would be smaller. But the overall elapsed time wouldn’t budge. The story would just wait longer for QA to be able to look at it.

Or halve the QA time required without reducing quality and rate of bug discovery. That would reduce the size of the gold bar. Which is admittedly a win at the story level. Because the elapsed time to the end of QA would go down.

But then you have the next step out: release elapsed time.

How much time elapses in between when all of the stories are QAed and the release goes out the door? If you don’t have a continuous delivery pipeline, it could be weeks. So it doesn’t matter if QA or dev go 20% faster, because the product won’t end up in the client’s hands until the product is released.

In practice all features are released together anyway. So even this pinkish elapsed time stack would need to be much taller when you count the time to release.

Key Takeaways

  • Increasing control doesn’t help a team be more efficient, if the team members aren’t motivated to collaborate.
  • Peer pressure similar to that in ball sports is a good model for how successful teams work together.
  • Strong-arming team members into finishing their work faster usually won’t impact the “elapsed time” before the features/product goes out to market.

<< Help Yo' Friends

Filed Under: assumptions, release planning, velocity Tagged With: elapsed time, work time

Disproved: Everything matters equally and I can just multi-task

January 29, 2020 by Luke Szyrmer 1 Comment

Usually, priorities come up in the context of time management and operational concerns. But did you know that having unclear priorities can also reduce revenue?

source: BAH, HBR

According to “Stop Chasing Too Many Priorities” by Paul Leinwand and Cesare Mainardi in the Harvard Business Review, too many operational priorities correlates with a given company’s ability to outperform its peers in terms of revenue. Having too many “#1 priorities” will reduce revenue potential. It will be harder to communicate the vision to both customers and employees. Also harder to execute.

Multitasking increases cortisol, the stress hormone. For many tasks it produces an effect similar to a drop in IQ.

For example, lately, I’ve been focussing on writing. This is an activity that makes everything else easier for me or unnecessary. This insight comes from the book and podcast The One Thing. Mostly habits really. Habit formation is kind of a baseline for everything else to fall into place. It helps to be very deliberate about what habits you form, and to make sure that they’re aligned with longer term outcomes.

I’ve endured phases of my life where I went pretty deep into personal development topics. Lately, I’m more interested in organizing my own work as well as that of my team. If we aren’t agreed on what must be done, in order to kick start focussing time and other resources, then they likely won’t get the inteded outputs. This is kind of a “captain obvious” truth. Especially when working on new products, if people don’t at least have a clear goal defined, then it’s easy for them to drift.

When scaling up habits to a workgroup level, though, it’s worth pointing out that we’re mostly trying to manage the work, not the workers:

FWIW, here’s 2007 slide, when I began saying: Watch the baton, not the runner. Other people may be earlier. Text box added to help pic.twitter.com/4LoLyn6URi

— Donald Reinertsen (@DReinertsen) January 31, 2017

Having the right habits means having habits like watching the baton. Making sure that, in fact, only one thing is done at a time and it’s the highest priority item. That people are supported sufficiently. That everyone is clear on goals, even if the path to those goals isn’t validated yet.

Multitasking works great in software, where there is no switching cost. Expecting humans to multitask.. bad idea.

<< Help Yo' Friends

Filed Under: assumptions, metrics Tagged With: multitasking, prioritization

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • Next Page »

By Role

  • Startup Founder
  • Software Manager
  • Remote Leader
  • Innovation Executive
  • You Like?

    Search

    Key Topics

  • Faster time to market
  • Early-stage Growth and Marketing
  • Product-Message-Market Fit
  • Experiments and Minimum viable products
  • Metrics
  • About Luke

    Luke Szyrmer is an innovation and remote work expert. He’s the bestselling author of #1 bestseller Launch Tomorrow. He mentors early stage tech founders and innovators in established companies. Read More…

    Topics

    • agile
    • alignment
    • assumptions
    • case study
    • conversion rate
    • delay
    • Estimation
    • experiments
    • extreme product launch
    • find people
    • funding
    • Growth
    • inner game
    • innovation
    • landing page
    • landing page MVP
    • manage risks
    • marketing
    • metrics
    • minimum viable product
    • modelling
    • modularity
    • personal
    • Pitch
    • podcasts
    • priorities
    • proof
    • release planning
    • Risk
    • software
    • startup
    • stories
    • time management
    • tools for founders
    • uncategorized
    • unknown unknowns
    • velocity
    • vizualization

    Tags

    agile funding automated testing bottleneck case study conway's law covid customer development digital taylorism existential risk extreme product launch faster time to market growth headlines identifying needs landing page mvp launch lean lean startup managing priorities market risk minimum viable product modularity numbers options output paypal planning principles prioritization problem to solve process risk product market fit real options split testing startup story systemic test driven development testing time management tool underlier value hypothesis value proposition work time

    Copyright © 2021 · Log in · Privacy policy · Cookie policy