I’m pleased to report that the issues, insights and solutions we explore in the session are striking a chord amongst the start up community here on the East Coast. That tough tech community includes members of The Engine venture ecosystem, which is continuing to consolidate its reputation as an international hub for technology innovation that accelerates both business and societal transformation.

Like many in this part of the world, the budding companies within its portfolio are tackling global climate, sustainability and health challenges with novel applications of AI, biotech, robotics and much more. The fields are varied, but the common denominator is deep, complex technology. And with deep, complex technology comes some very specific problems. In the workshop, we frame those pretty bluntly. A tough tech company will usually start out with an idea that costs way too much, doesn’t yet work properly and can’t actually be manufactured by anybody. More than that, you’re not yet allowed to make it and even if you did, you have no one to sell it to.

We usually kick off each session by debunking a couple of misunderstandings. Many people, for example, assume scale is guaranteed. But in fact, the opposite is more likely to be the case because organisations tend to get more inefficient as they get bigger. We also ask the audience what scale means to them, because it’s something that can be viewed from many angles. A favourite take on that from the team: scale is when you stop asking how and start asking how much!

Start up versus scale out

In fact, the definition we use for the workshop is that scale becomes a thing when your revenue increases faster than your costs – and that might vary depending on your specific business and any particular aspect of the business that you are talking about. Of course, there are different approaches depending on what it is we want to scale. The first one is scale up, where we learn enough about a system to make it cheaper and more robust. Then there’s scale out, where we keep doing what we were doing before but on a much bigger scale. The third one in the workshop spotlight is incremental scale, where we take something to market as soon as possible so we can learn what the scaled systems eventually needs to be.

Is there a ‘best’ approach to your development process?

This sets us up to explore these approaches to scale against the five key burdens in the process – ‘define’, ‘design’, ‘make’, ‘verify and validate’ and ‘support’. It gives our audience important insights into issues such as front or back-loading of effort, likely timing of risk, need for iteration, time to end-product and so on. The most important take-away that I stress here is that there is no ‘best’ approach, but that there is a correct approach for you that considers your unique circumstances. They include crucial aspects such as what your development process is, what your system and product is, what the market looks like and what your competitors are doing. All are hugely influential to future success.

Most system developments don’t follow a single path, but there are examples where one approach tends to be more relevant. In cell biology, for instance, scale-out predominates because of characteristics such as long test cycle time and the fact that there are often more variables than can reasonably be characterised. In industrial processes, scale-up is usually the right approach because new methods might be tested at a small scale, but value only comes to fruition at a large scale. Here, iteration costs are extremely high.

There are interesting hybrids too. In medical device development, the FDA mandates specific iterations of a system during development, so you have some opportunity to increment along the way. This can be used to increase the effectiveness of scale-up. Consumer devices are challenging – you need to scale-up in order to put resources in place to support your product. So here you have to increment quickly after you’ve done your initial scale-up.

All that said, most companies will go through multiple paths, through multiple stages of scale. The lifecycle of an organisation doesn’t follow a single path and as knowledge is built around the technology and the market, so the right approach changes through first, second and third generations of development.

In the next phase of the workshop, we outline how the approaches affect development and how learnings can be applied to the way technologies are engineered. A classic example we refer to is the Model T Ford. Comparing the cost and production volumes for the three preceding generations of car and the Model T itself shows a massive increase in volume and a halving of the cost. This was made possible by a move from an iterative and costly design process into a definite design process. A process using artisan craftsman switched to a definitive design with precise requirements and an ability to make everything more repeatable.

The lesson is that when we go from making one product to making millions, we need to be very specific about the needs of the system, we need to freeze the design and we need to predetermine the success criteria of each design element.

Great technology innovation solutions

The implications of all this for early technology development are clear. Lots of unknowns are expected, so you need to be able to change direction quickly as new information is uncovered. Solutions often come from broad technology approaches to explore what’s possible – and it’s certainly true that great solutions come from teams that regularly collaborate together. This is the iterative approach.

With scaled hardware or process manufacture and operation, however, any unknowns can cause delay and expensive reworking, and changes of direction cannot happen quickly as so much is invested in each activity. Precise control of operations demands deep understanding of the specific aspects of operation, while great solutions come from teams being able to work independently towards a common goal. This is the definite approach.

No development for scale is ever clearcut

In reality, no development is ever really so clearcut. There should be elements of both the above examples in your development, but as the programme progresses towards scale, it needs to become more definitive than iterative. It’s at this point in the workshop that we dive into much more detail of how well defined, planned and executed changes in approach can characterise a successful development plan. Much of it is based on CC’s templated design review process, which takes into account the overlaps and variables I’ve described. We also dip into a couple of further inspiring case studies, share an invaluable scalability checklist and conduct an interactive group activity to bring the learnings to life.

If you’d like to continue the conversation and dig deeper into any aspects of this technology innovation topic, then do please email me. It’ll be great to hear from you. And before I go, here’s some closing bullets to summarise the thrust of the workshop:

• Scale means changing the way you and your development team operates
• Economies of scale don’t just happen – you must plan to reach them
• As you move towards scale, the cost of change increases greatly
• There isn’t a single ‘best’ approach
• Planning out your approach to scale allows you to keep innovating for longer and reach your market potential faster

専門家