Aoife Henry

Applying the Engineering Validation Mindset to Building a Business
… Simulations vs. Stories

I have been an engineer for the latter half of my life. My ‘apprenticeship’ started years before college, from the moment I decided to study coding with nary a carrot or a stick provided by any teacher, and to initiate ‘side-projects’ that undoubtedly caused enough stress to accelerate my aging. I had unwittingly initiated my training in technical skills and project management. 

I loved coding, because it was (at least before the advent of ‘vibe coding’) predictable. You build a computer program, you provide certain inputs, and you expect certain outputs. If you don’t get those outputs, there is a flaw either in the code or in the logic on which it is based, and you, the coder and champion of your code world, can and will find and resolve that flaw. Not only was the process of coding comfortably deterministic, but the process of studying and gaining expertise in it was equally predictable and rewarding. I enjoyed achieving mastery in an area I excelled at.

I certainly did not feel as comfortable with my early dalliances in project management, because it was the antithesis. It was uncertain and there was never a clear pathway forward to unravel the flaws in the system. I pursued it anyway, in the form of fundraising for charities and various pocket-money-making schemes in college, because it felt important that I apply myself to generate value. I needed a purpose to channel my energy into.

Over the course of years worth of homework problem sets, millions of lines of code, and the self-led research I conducted for my PhD, I became more adept at solving problems creatively with the technical skills I was developing. Something wouldn’t work (just another day in engineering). This was the Problem, I would dig into the symptoms of the Problem to find the root cause. I would stare into space and scribble down a few ideas for what might solve the issues. These were potential Solutions. Finally, I would test each solution, and the one that led to the best results would earn the right to be implemented. Some progress is made and the cycle repeats. For the non-engineers out there, hard as it may be to believe, this is the part of work – problem-solving – we generally find fun. Just as I love to code, I enjoy this cycle of relentless and curious experimentation in the name of building something of value. The meetings with people, not so much.

Three weeks ago, I left the role of Engineer to enter the role of Entrepreneur. Conceptually, the processes critical to these professions are not so different. As I described above, the Engineer fixates on the Problem and incrementally and iteratively tests Solutions to solve it. The Entrepreneur – at least one trained in Lean Startup methodology – defines the Problem and builds the Solution in parallel using the same incremental, iterative, and experimental approach. The difference is that the Engineer takes the Problem as a given and gets to work building Solutions, whereas the Entrepreneur knows that this problem definition has to be solved for too, by ‘testing’ on the people they presume suffer from it. 

Engineer, meet people.

This transition is not easy, because testing solutions with people is different from testing solutions in code, because a) people are unpredictable, b) testing on 10 different people may yield 10 different results, but one can only hope that trends will arise, and c) there is no single ‘optimal’ solution, you just have to decipher the trends, make a call on how best to move forward, and get on with it.

But the process is not new either. Ideate what the problem and solution pair is, run a test to validate how right or wrong you are, update your mental musings accordingly, repeat.