The S-curve




This reflection came from one of the questions that I had to address in our team's Q&A, the question was:"What areas do you wish we could be more effective as a team?" The thought that I had was mostly from my experience running incubation projects (projects that spans from early research proof of concept to a relatively mature and reproducible state): the S-curve in innovation.

An S-curve has 3 segments: a slow start followed by a rapid growth, then finally hit plateau. This curve not only applies to the broader macro environment of innovation, but also the micro environment like our team. We should be more aware of this pattern, and apply different operating principles in the 3 different phases on the curve. I'm listing a few DOs and DON'Ts for each phase that I thought was useful to me.


THE SLOW START

This is the exploration phase of a project, things seem to move slower since there are both known unknown and unknown unknowns.

DOs

Rapid prototyping and answering as many questions as quickly as possible: Have high tolerance to tech debt during this phase in order to give time to answer critical questions from the first principle.

Be resistant and persistent: Since this is the beginning of a project, it's natural that people express skepticism. Don't let those doubts get in your way, if you have strong belief in the technical path.

DON'Ts

Commit big engineering capacity upfront: It's a typical failure pattern that teams might want to do something big, therefore they commit sizable engineering capacity from the beginning. However without understanding the fundamentals and proven line of sight, committing more capacity into scaling or serious engineering will only lead to accelerating the wrong thing. During this phase, usually a committed 10xer focused on exploration moves faster than 10x engineers collaborating.


THE RAPID GROWTH

This is when the project starts to shine, people see the value of the project therefore either want to become a customer or be part of the project.

DOs

Commit the right resource to accelerate: In contrast to the exploration phase, now one or more of the early explorers of the project does know all the fundamentals, therefore adding more resources to the project will naturally multiply the outcome.

Pay off the tech debt, pick all the low hanging fruits: Since the project will start to serve or collaborate with many more people, the biggest bang on the buck would be clearing up all the known issues. Tech debts don't cause much damage when you only have 1 or 2 initial 10xers working on the project, but if not paid off, they will soon create exponential overhead to future collaboration.

DON'Ts

Say yes to everyone: Yes the project is successful so far and many people are reaching out to our team for collaboration, all feels like a big impact knocking on the door. However, saying yes to all the requests also means that the team needs to spread thin, and will inevitably lead to not being able to focus on the most impactful use cases. Misses the biggest impact during a phase of rapid growth is the very definition of failure.


THE PLATEAU

This is the phase that your project goes into a stable mode, it's generating consistent impact like passive income but at the same time, any work that we do seems incremental and won't create that significant impact any more.

DOs

Reserve capacity to explore the next curve: It's obvious that once you understand the limitations of the current generation of technology, you would want to jump on to the next generation that breaks all the limitations. The tricky bit is the current project is still very much running and "profiting". During this phase, it's critical for teams to start reserving dedicated capacity to start the exploration of "the next big thing". Otherwise, the project will die a slow death.

Franchise and tech transfer: From an R&D organization's point of view This is one of the best ways to let the project continue at the same time ramp down our own team's capacity. Actively look for partner teams who would like to take on our technology to scale and productionize, and transition our team from the owner to a customer will create a win-win situation and help us to free up the capacity for the next exploration.

DON'Ts

Be too obsessed with the current project: An individual can be obsessed with the project and wants to carry the project all the way through, but our team can't. We need to always be conscious about the limitations of the project and be ready to move on.

The above pretty much sums up my thoughts on the question "What areas do you wish we could be more effective as a team?". 



Location: Redmond, WA, USA

Comments

Post a Comment

Popular posts from this blog

Risk vs. Uncertainty

Image
It's the planning season, "Risk" is one of the most discussed topics during this time. But when we say "Risk" we might mean different things. Therefore I took some time to reflect on the two most common confusions that we might have when talking about "Risk", that is Risk vs Uncertainty. I took a lot of inspiration from this note and I'm sharing some of my own thoughts and realization that might be useful. What is risk? Risks are bad things that can negatively impact the outcome, so we don't want them to happen. Risks are certain, therefore usually measurable / quantifiable. Given the nature of its certainty, we can usually mitigate them using tools like insurance, contingency and parallel paths etc. In the context of R&D, dealing with risks ultimately leads to solving a trade-off problem: you put in more effort, spend more money, extend the timeline or compromise the feature set, etc. An intuitive example : You are on the roof of a 20 flo...
Read more »

Feedback Loop

Image
Over the past few weeks, I've been reading "Thinking in Systems" by Donella Meadows . One of the mental models that I've reflected on is about feedback loops and how it is relevant to our work.  The concept of a feedback loop in systems is fairly simple, as in the attached photo: you do something, measure the outcome, analyze what leads to the outcome, correct the mistakes, then repeat the action. The biggest problem to deal with is system delay: when there's a significant delay between the first action, the first measurement, and the updated action, oscillation happens. We either commit too little action or too much, which both lead to undesirable results. An analogy and a concrete example can help to understand this. Analogy : Imagine you are taking a shower and you want the perfect temperature for the water. But your hot-cold water mixer is quite far away from the showerhead. What's going to happen is that there will be a few seconds' delay after you tu...
Read more »

Three tools to help think clearly

Image
Part of our job at a research lab is to clarify an ambiguous area and create a clear path to navigate it. To do this effectively, we need to dedicate significant time to think. I've found Mental Models , or tools for thinking, to be extremely useful during this process. I'd like to share three that I use quite often, in the hopes that others might also find them beneficial. Thought Exercise While there are numerous well-known exercises, the one I've found most useful involves hypothetical scenarios, or "what ifs". The basic idea is that you construct a hypothetical scenario which differs from the current reality. Then, you explore the problem within this alternative reality. Here are a few examples: What if I could discard the current system and rebuild it from scratch? What would I do differently? What if I could, hypothetically speaking, "fire" the entire current team, regain the headcount, and rehire one by one? Who would I want on the new team? What...
Read more »