After three and a half years, I recently left Vow for a new startup in a related area. More to come on this later.
I worked with some wonderful people over the last three years and feel I grew a lot. It was the perfect education in so many respects: equal parts interesting, challenging, and enjoyable. I came out of university knowing I liked startups, engineering, and science, but I had never considered manufacturing. I joined Vow because the problem was intriguing, and during a tour of the factory I recall feeling a distinct sense of FOMO not knowing how it all worked.
It was pretty ridiculous at times. We were creating a new product and a new category with no regulatory precedent and no incumbent to copy, and we were vertically integrated to the point that it felt like working inside an R&D lab, an equipment vendor, a food company, and a factory at the same time.
This is mostly a note to self: what I learnt, what worked, and what I got wrong.
Contents
Learning from really competent people
The best people I worked with pointed themselves at the outcome the business needed and took the most direct route to it. They did not get too bogged down in technical problems, defend what their team was “supposed to own”, or adhere too strictly to their titles. These people were just maniacally focused on outcomes.
Early on I kind of thought the way they worked was annoying. They were agents of chaos, disturbing the peace in the name of progress. As I spent more time thinking about what really mattered, I often saw that these people were right alongside it.
Over time I got better at doing this. It required me to be more willing to look stupid, lean outside of my lane, essentially forget my title, and ask the question that felt like the elephant in the room. This is a careful balance to strike, particularly as a leader, given that sometimes your role requires you to ensure you are extending your influence beyond yourself. You are not just focusing on the outcome, but ensuring others are focused on the outcome.
Reflecting, I realised that early on I spent too long on local optimisation. It took me a while to look beyond software and ask what the company needed most. I had assumed someone else was responsible for the bigger picture, and would pull me into the problems that mattered most. This underestimated how hard it is for company leadership to direct 80 people in an efficient way. Ensuring everyone is contributing to the best of their ability is difficult without perfect insight into their capabilities. No one was going to be as good as I was at knowing which problem I could help with.
The clearest example was an internal workflow system I helped build and was a strong advocate for. The core premise was making manual factory work more repeatable and increasing integrated data capture. But the factory’s actual problem was that the bioreactors kept getting contaminated and there was no obvious reason why. I told myself better workflow tracking would let us compare human actions across contamination events to find “deviations”. Then we would have the smoking gun.
The more direct path would have been to automate the bioreactors more aggressively, spend time going through every single automated step with a fine-tooth comb to find the reason for the contamination, and help the team already on that problem move faster. I should have learnt the process, automation, and controls I was missing and moved on to the bottleneck, instead of building on top of it and assuming someone else would fix it.
Alternatively, I could have spent 30 minutes finding an expert who could tell us from experience how to clean bioreactors, and that we were not paying enough attention to flow rates or temperatures. I could have found three experts, sent them an email, and gotten them on site. This was straightforward and I had every skill needed to do it, but it was not obvious when all I was worried about was supporting different step types on a workflow system.
That changed how I think about my job. Not “am I delivering what I said I would deliver?”, but “am I working as directly as I can on the most important thing?”, regardless of the org chart, my title, or what I worked on last week. Oftentimes this means debating with my leaders, finding my own priorities, and advocating for them. All of this is easy to say in principle, but in practice it takes time to build this skill of self-evaluation and acting with agency and urgency on critical problems.
The best people also called out inconvenient truths. They would say the uncomfortable things: “This seems inconsistent”, “Why are we doing this?”, “This does not really matter.” The trepidation the rest of us feel about ruffling feathers did not seem to register, because they were fixed on the thing that mattered. I got better at holding my ground in those moments. You sort of need to become more comfortable just sitting with the discomfort and disagreement of contentious issues. Everyone wants to move on, because saying that the status quo is not sustainable is uncomfortable. But at these times you have to stop listening to the social part of your brain that is telling you to go along to get along.
Sometimes this meant identifying when the people in the room did not have the right level of detail to solve a problem. If you keep drilling down - “why, why, why” - for some issue or problem, oftentimes you get to a point in the room where the lowest level of justification is “I do not actually know why this is a problem, but X person said it was.” Or: “I am not actually sure, I just assumed we cannot do this.” Unravelling this way is particularly effective at cutting through organisational red tape. It often does not make sense when you drill all the way down.
Team building and structure
Over time we reduced the number of unique teams and co-located people who needed each other regardless of title. For a while we ran a handover process where a project passed through four or five teams on its way to “Production”, across two functions. It almost never worked, got stuck all the time, and felt very much like a remnant from traditional biopharma, where cell culture came from.
We were behaving more maturely than we had earned, and teams stayed blocked on each other over whose priorities came first. What worked was setting a cross-functional goal, aligning everyone on it in public, and clearing every other priority until it was done. There was a period when the whole engineering and operations team was focused on a single COGS target. It was the most effective the team ever was.
For engineering projects, we had a similar issue where projects would start with the mechanical/process team and only later would software/automation be pulled in to “automate” the large piece of machinery that was arriving quite soon. This came to a head on a factory-wide fluid distribution system, which was initially scoped to a super-efficient mechanical design but required a complex software implementation the team did not have the capacity to build. So we had to restart the project and go back to the design phase with software much more tightly in the loop.
From then on we had a weekly “Critical Design Review” session, which was a cross-functional design engineering meeting with the stated purpose of ensuring any new engineering got as many eyes on it as soon as possible. This substantially improved our cohesion as a team and the quality of engineering.
Software was something else that was challenging to get right. There was no playbook for how to structure software teams in a biomanufacturing startup. At one point we had three software teams with three leaders, in a company of 80 people with maybe 40 internal users. In hindsight, it was too fragmented for the stage we were at: a structure built around who was on the team rather than working backwards from our goals.
It is hard to see when you are in it. Each team has a rationale, each leader a roadmap, each piece of work a justification. Our software stack matched our org structure, more organised by teams than what we actually needed as a company. Coordination costs rose and we delivered less than we could have. Only after we reduced these teams largely into one team that was more tightly integrated with the mechanical/process engineering team did we really make rapid progress.
My main takeaway from this area is that functionally organised teams that are overly rigid generally slow things down, and fighting the urge for increasing levels of specialisation for as long as possible likely makes sense. It is also a reminder that no org structure is neutral, and even safe choices can have a detrimental effect on progress. I learnt to love a saying from one of my colleagues: the org structure did not matter that much as long as it changed frequently.
Critical path and speed
Vow was extremely focused on speed as an organising principle. How quickly could we move, and how frequently could we iterate? I think above all else this is the main reason we were able to make so much progress. Progress tracks the number of real attempts you take per unit of time, and how good you are at ensuring you learn something new every time.
The best habit at Vow was asking why something could not happen today instead of tomorrow, and not accepting any delay as inevitable. As soon as a delay was flagged, you would see this immediate fixation on how to remove it, parallel path it, or avoid the requirement altogether. It was room-wide discomfort until the delay was ameliorated. The team was also very good at contingency-based planning, where multiple options were pursued in parallel, focusing on which pathways helped us learn fastest rather than suffering from analysis paralysis to choose the perfect option.
Someone once flew to Iceland to collect supplies because shipping and customs would have taken too long and it was on the critical path. We sent people out to key suppliers, at home and overseas, to check quality and speed things up. We always had bioreactors running in contingency in case there was a contamination at a larger scale.
We also did everything we could to reduce the cost of iteration. If any element of the iteration loop was expensive or time-consuming, we would in-house it, work aggressively to delete it, or find an alternative supplier. This is one of the main reasons we ended up with an in-house process control framework using Python. Our engineers could already write Python, and getting the bioreactors to work would involve a huge number of iterations.
Speed of iteration also protects you from what might seem like unsolvable problems. A problem feels existential when you only get one shot at it. If you can try ten things quickly, it becomes much easier to stay calm. So you are less worried about thinking through every potential obstacle ahead of time.
All of this requires having a clear goal of where you are going, then defining the critical path. This was something new for me and feels like a defining characteristic of a hardware-oriented business. Despite even our best efforts, you cannot pivot on a dime and endlessly change your mind. You cannot rebuild your bioreactor in two sprints. Some things just take clock time, and so you need to pick an end state of the world that you want to achieve and work backwards from there to define the critical path.
This feels quite different from the software-origin lean startup methodology of getting something live and then iterating. In software, there is more scope for exploration and less directional conviction required ahead of time. A leader’s job at a place like Vow is to set a vision that is commercially and technically coherent, define what has to be true for the business to work, and then create the conditions to execute against it fast. They should constantly be agonising over that long-term direction, and the speed of execution. Everything else is secondary. Weak leadership means avoiding the difficult question of where we are going because it is hard, and hoping that if enough teams try enough things the answer will surface.
Keep it simple stupid
Over my time at Vow, we considered doing a lot of complicated things to speed things up. There was always a desire for a better data feedback loop that could eventually be used to generate “predictions” of where we needed to go: which experiments we should do next, which control parameters to try next, which media formulation to try next. We also tried other complicated things like lab automation with robotic arms, metabolic modelling for media inputs, complex analytics to help find deviations, etc. The list goes on. Some were good in theory, and a few might pay off with enough scale and clean data. Most were too hard or too far from the bottleneck to help at the time.
What worked was almost always simpler. Better supply chains for expensive inputs. A strong internal engineering team so we could bring key hardware and automation in-house. Getting instruments to upload cell counts and metabolite readings automatically, then plotting them against time so trends were visible from anywhere and comparable across runs. Better UIs for visualising data and automation. The most valuable software we wrote was basic: scripts that moved instrument data to the right place, dashboards, Grafana telemetry, logging that let us understand a failure after the fact. None of it was impressive the way a simulation is. It closed the loop between the physical process and the people trying to improve it.
Over time I became nervous as soon as I started hearing anything that sounded too complex. Did we really need this? Were we underestimating the resources required to do this complicated thing? Did this really matter?
I also became addicted to deleting any kind of requirement that just did not matter at this stage. I remember at one stage we had this great internal framework for writing control structures using YAML. The dream was to have an in-app chat window where operators could request changes to the control structure, or ask questions, and AI would make the changes instead of an engineer. In theory, it would massively reduce the communication hurdles between process engineers and those who wrote code.
But it kept being blocked by the complexity of doing in-memory updates to the code from a browser. So instead we just made the YAML importable/exportable and used Cursor to change it with a prompt. In our most recent bioreactor, process engineers wrote most of the control logic using Claude, which meant we could commission our bioreactor in one month instead of six.
There are so many opportunities like this that make us go much faster by deleting complexity, requirements, or anything that is not needed right now. Over time I celebrated the code we did not write, and projects not undertaken, as much as the ones we did.
Nothing beats the real deal
Vow was different in how it approached process scale-up. The traditional biomanufacturing industry typically designs something at small scale, then translates it up. Then it has to deal with “scale-up” issues. Over time, we just defaulted to running at process scale as soon as possible. It teaches you so much more per unit time, and gets you to your end goal sooner. Yes, this costs more money, but if you can optimise your supply chain for the cost of iteration the difference is marginal. At one point I remember thinking it was generally easier for us to run our 20 kL bioreactor than our 2 L bioreactor because we had just so aggressively optimised for scale.
The overall lesson aligns with everything else I have learnt from Vow. Once you get something working at scale, you are only a few cleanup steps from your end goal. So just shoot for the end goal. Skip the intermediate steps. If it does not work, iterate quickly until it does.
Usually it is not much harder than getting it working at a smaller scale, and you do not spend any time on side quests needed to get your small-scale process working. The lesson also applies to software, where digital twins were consistently advertised to our software team as a means to develop working software more rapidly, but it was almost always quicker to just test on production equipment with reasonable safeguards to keep the team and equipment safe.
As a related learning, it would be easy to think of Vow as a science company, when in reality it is an engineering company built on science. Science gave us the building blocks and told us it would be possible, but most of the work was engineering, with directed science along the way. The best experiments were not elegant or groundbreaking, but rather quickly answered questions we needed to make progress or improve the system.
Finding product-market fit
Product-market fit was a challenging problem. The most dangerous thing for us was that there were so many reasonable, concrete reasons why we could not definitively answer the question of whether we were on track to find PMF.
George, our CEO, put it well: there were so many obvious obstacles to product-market fit that it was hard to tell whether we had an execution problem, a product problem, a marketing problem, or a category problem. The product was not approved for sale, which made real consumer testing difficult. It was hard to produce consistently, so even internal testing was scarce. Until the cost structure improved, selling at a sane price was a cash pit. And we had to build sales and marketing muscles for a category that did not exist.
All of these were legitimate blockers to evaluating whether we were tracking towards product-market fit. Being an organisation full of optimists, combined with not being able to pivot on a dime, meant we had to forge ahead with a high degree of uncertainty. Whilst hindsight is 20/20, if I were doing this again I might push on this more. Maybe we would have made some slightly different choices that meant we could achieve PMF sooner. I also probably would have focused more on “supposing we sort out X, Y, and Z, will customers love our product?”, rather than assuming it would be an easy sell.
For what it is worth, Vow is now approved in two markets and selling across multiple categories. It was just a hard ride to get there, and how you define PMF is a how-long-is-a-piece-of-string question anyway.
What I am taking with me is a renewed conviction that you should fight tooth and nail for data about whether you are trending towards PMF, and then act on it.
Taking big swings
Vow took a few proper big swings to get where it has, and it is important to recognise that sometimes it is necessary to take risks to make progress. If everything was low-risk and easy, some other organisation would have already done it.
One of the biggest risks we took as a business was to in-house our entire bioreactor design and control system. It is hard to see how Vow could have achieved what it did if it were not for that decision. This meant risking a substantial amount of money and a huge amount of the team’s time doing something we had very little experience with, but trusting that our approach of first-principles design and rapid iteration would get us there. This was already built on top of a bet that our factory would be run on our own software stack instead of traditional PLCs. It is easy to think this is just innovation, but it is risk-taking that ended up paying off.
The other major risk that made Vow possible was deciding to become a manufacturer in the first place. Originally the vision was to use contract manufacturing, but the team found this to be too slow and difficult. So the capital was put down, and spent in a very efficient way, to build a 2 kL line ourselves. If the team had relied on contract manufacturers there is zero chance we would be where we are today.
There are more instances of this, but the main lesson I take away is that sometimes you do need to make a big bet, and no amount of analysis will settle your nerves in the moment.
Taking innovators seriously
Over time, I had more responsibility and also had a say in where we went. Early on, I found it quite easy to accept the far-flung visions of innovators on my team. I thought to myself: if this works out, that is great, I learn something and we move forward. If it does not, I also learn something. Either way I am still the newbie here and I do not have enough context to judge this anyway.
As time went on though, I had to weigh the balance of committing resources - either myself, my team, or other teams - against the risk of failure for innovative ideas. In these moments I had to learn to take innovators more seriously, and sometimes turn off my alarm bells that this seemed unlikely to succeed. This is somewhat different from the above comments on KISS, because usually these ideas were not KISS-able and would have a large impact.
An example that stays with me is when a senior engineer kept arguing that the LLM models would keep improving and we should shape our software effort around that. Do not pour time into anything a better model would make trivial in three months, or that the model companies would ship as a feature. Spend it instead on what would leave us better positioned when the models improved: cleaner code, better documentation, more observable systems, less implicit context trapped in people’s heads. Obvious now, foreign at the time. When the models did get better, that work was what made us ready for agentic engineering.
Another engineer wanted to build an AI agent inside Slack, well before that was a normal thing to want. I was still stuck on older approaches to thinking about software, and thought a non-deterministic agent in our Slack would be chaos. I just could not see around the corner in the same way he could, that this was happening, and we as people would adjust to the non-determinism. It was not an engineering responsibility to hide it away.
Both of these instances taught me the value of having innovative people on your team and learning to trust them when you are not sure that you want to. At the very least, take their ideas seriously and try to play out the logical conclusions, even if they grind against your preconceived notions.
Hiring
Geography was more of a pain than I thought it would be. I spent a huge amount of time hiring for software. Sure, some of that is just startup difficulty and lack of brand. Software engineers tend to stick to what they know, but there is also a large geography element to it. Australia does not have a deep pool of software engineers who have worked on hardware outside of microelectronics or med tech. Never mind manufacturing. It certainly made me question our in-house stack more than once.
It would have been useful to pull control engineers out of somewhere like SpaceX, purely because they have seen hardware, controls, manufacturing, and intensity all in the same place. Unfortunately Australia does not have many SpaceX-like companies, so that requires hiring internationally, which is time-consuming and risky, or scouring all of Australia for the right engineers who could adapt. This usually meant that hiring a software engineer meant a six-month ramp-up time before they understood just how different the expectations and requirements are.
All of this is to say, talent is so critical, and finding the right talent will be a bottleneck for any advanced manufacturing companies in Australia for the foreseeable future.
Another observation: for the best people, it did not really matter what role they were being hired for. They would probably be fine shifting into 80% of the roles the company needed in the next two years. They would usually not be from biomanufacturing in the first place. They would have some set of transferable skills, strong first-principles intuition, and a high level of adaptability.
So sometimes agonising over the JD is only worthwhile insofar as it gets those people interested, rather than helping you find the best technical fit.
Becoming a people leader
I think the role is much more of a rollercoaster than being an IC. Some weeks are really great, whilst others can be quite stressful. Much of the role is just trying to communicate clearly to people on your team: what your expectations are, whether they are meeting them, and hearing what they say to you. The rest of it is problem solving, because problems that were not solvable by your team end up getting escalated.
I would recommend it purely because I think it has benefitted me outside of work in my ability to communicate, handle conflict, and set clear boundaries. The job itself I personally found to be enjoyable due to the extremely capable people I was leading, and working closely with them. I benefitted more from them challenging me and pushing me to improve than they did from my “management”. The leadership element of being a team lead also stretched me all the time, and forced me to become much better at making decisions under uncertainty, frequently evaluating the impact of new information, and acting with a sense of agency.
The last lesson about people is the hardest to act on. Most people I worked with were exceptional, but startups are intense. Priorities change, structures change, and the company evolves. This means that those who were hired at a particular company stage may no longer fit as well as they did before. Sometimes these people leave on their own, but other times they stay, unwilling to move on. There were a few situations like this over time, and in hindsight I think addressing them earlier would usually have been better.
That being said, Vow generally had great people and a wonderful culture. Everyone was optimistic, kind, intelligent, and extremely hardworking. We had a thorough interview process which was time-consuming but shaped a strong team.
What I’m taking with me
I learnt so much over the last three years, and had the privilege of working with awesome people on extremely engaging work. I am completely hooked by the process of building something in the real world, and the multifaceted optimisation game of manufacturing.
There are so many other lessons I could chat about, but I think these are the ones that will stick with me most.
As I step into my next role, there is so much I am bringing with me from Vow. Most of all I am bringing a sense of belief. If we were able to do what we did at Vow, so much is possible and in reach with a bit of hustle and effort. That is not to say it will be easy, but it is certainly possible, and I already know the sense of fulfilment when you make it happen.
It is not surprising that I can think of at least four companies started by Vow alumni. Whether that is just our hiring process or a sign that Vow is a pretty effective startup training ground, I am not sure, but I am betting it is a good deal of the latter.
I could go on, but let’s wrap it up here. Hopefully I can write a similar post in three years when <insert company> achieves at least 50% of what Vow did.