As someone working in software development and engineering for over a decade, I know the emotional cycles of building apps and services using code.
Something needs to be built or fixed
You think about how to build it and sketch out a plan
You open up a code editor, get the app or service running locally
You start making changes
Your changes instantly update the app
If it works as expected, youâre done! Instant dopamine kick.
If it doesnât, go back to 4 and repeat until it works.
Iâm oversimplifying, of course, and there are always plenty of ups and downs along the way. But the key takeaway here is that the feedback loop is usually tight and that you generally have something concrete to show for your efforts quickly. And if you donât, then you can (and should) restructure what youâre working on and how youâre working so that you do.Â
Since becoming a fractional CTO working closely with startup founders and effectively becoming a solopreneur myself, itâs been a real journey to both understand and experience what starting and running a business feels like. Itâs pretty radically different from my experience as an engineer.
Marc Andreessen famously said that as a founder, âyou only ever experience two emotions: euphoria and terror.â Iâve only been doing this a few months at this stage, and Iâm not going to fully equate a solo consultancy business to running a startup, but this quote resonates strongly with my experience so far. The highs are awesome and the lows are brutal, and on tough days thereâs little to nothing to show for the work youâve done.
I can build something like my website and get a little kick, but that is quickly subsumed by the realisation that if no-one seeâs it itâs been a complete waste of time. Iâm not getting paid regardless of what I produce. As an engineer, certainly earlier in my career, I could often be shielded from this reality. There was usually a product manager, or a founder, doing all the âbusiness stuffâ - I was just there to build the thing. No one used it? Frustrating, but thatâs their problem, not mine. I built something, and Iâm getting paid.
Except of course it is my problem, especially if I still want my company to be profitable and successful and keep paying my salary long into the future. But, especially at larger companies, understanding my contribution to the wider business performance was opaque at best, and the chances are I would have moved on to a different role or company by the time the impact would have been felt, if indeed it could be attributed to me at all. Now, money in my bank account rests solely on my shoulders and the decisions I make. Itâs a step shift, and scary at times, but enormously invigorating too.
This is part of the reason I love working with early stage startups, and why itâs so exciting and challenging working as an engineer in these environments. Tossing the can over the fence and saying âhey, I just build stuff, the business side is your problemâ simply doesnât (or shouldnât) cut it. The engineer of the future is without a doubt an evolution of the Product Engineer, someone who cares and thinks deeply about whatâs being built and why as much as how to build it. They need to understand how to sell things, most of all themselves, in a future where rote coding skills will become commoditised by AI but and individuals personality and the fresh perspective they bring to solving problems will be more valuable and valued than ever. The engineer of the future will need to be closer to the business, and thus the euphoria and terror that founders experience, if they want to be successful. (Plenty, but not all, technical founders fall into this category already).
In case this all sounds like one way traffic, I think itâs also important for founders and those on the business side to appreciate the value of engineerâs contribution. If you are a software focused business, engineers role should be as the cultivators of the optionality of your software, and thus the long term value of your company.
They are not just there to build the next feature today, they are also there to make sure that itâs still easy to build new features tomorrow and the day after. There will always be a healthy tension between net present value (typically pursued by the business) and the optionality of the software (cultivated by the engineers). A deeper appreciation and understanding of this by founders will not only help smooth fraught conversations with their engineers, it will also make their companies more valuable and profitable in the long term.Â