A lifetime in software and nothing to say?
“I’ve Seen Things You People Wouldn’t Believe. Attack Ships On Fire Off The Shoulder Of Orion. I Watched C-Beams Glitter In The Dark Near The Tannhauser Gate. All Those Moments Will Be Lost In Time, Like Tears In Rain.” - Replicant Roy Batty, Blade Runner
My life was spent glued to computer screens, witnessing their resolution improve from 256×192 pixels back in 1984 on my Sinclair ZX Spectrum 48k to 3024×1964 on my Retina MacBook Pro today, while my eyesight inexorably declined.
30 years. More than 60000 hours developing software and leading teams of software developers. My epitaph could read “main(){main();}” to reference how I ceaselessly revisited the same topics, until the final segfault, you know, the one that’s beyond any reboot.
My professional legacy is all virtual, intangible: some bits squatting the Internet and a few scattered memories in the minds of my old teammates. I have no need to read philosophy books to be reminded that human life is inconsequential - mine is a prime example of this.
I wonder - is there anything valuable that I have learned during my entire career that I can share with others? Any original thought that is worth capturing in writing? Anything at all - that isn’t merely part of the endless cycle of regurgitation of human wisdom?
Answering this question has become urgent: on November 8th I’ll step up to speak to an audience of hundreds of peers attending a well-regarded conference. I must resist my natural urge to dive into books and cook up (at the last minute, of course) slides full of bland warmed up best practices. Countless business book authors have done this for ages and modern LLMs can spew coherent platitudes in seconds. Come on Serge, you must have something better to offer!
Sadly, I’m unlike Buckminster Fuller, whose Dymaxion Chronofile life-log reached 80 meters worth of paper - I have been inconsistent in my journaling and will have to rely on my (hazy) recollections to shape the content of my presentation.
Does the experience of a practitioner with three decades of toil contain more insights than that of a younger but smarter and more deliberate professional? What makes my perspective unique and valuable? Let’s try to reminisce and concurrently build up my confidence level…
I had the good fortune of being a senior employee at two tech startups that went public (IPO, not SPAC), in 1996 and 2016, in the UK and US respectively.
I had the equally enlightening, albeit more painful, opportunity to experience three bankruptcies. 100% of my own ventures as a co-founder flopped.
Repeated boom-bust market cycles have hewed me: I joined the economy during the early 1990s recession, prospered during the exhilarating dot com bubble years and then survived its crash in 2000, attempted to raise funding on 9/11, took a 30% pay-cut during the financial crisis in 2007-2008, only to ride the ensuing QE-fuelled tech bubble, hitting the jackpot during the COVID roller-coaster months, before seeing some of my savings vanish in the FTX debacle as the crypto nuclear Winter set in. I’ve turned into a stoic and do not fret about variables that I cannot control.
I worked at startups of all sizes, < 10 employees, 10-100, 100-200, 1000-2000 and 2000-5000 people, leading teams of 1 to 120 developers that built software that achieved from < $10k to over $100M in annual revenue.
I had my fair share of “wartime engineering”, rushing to find product market fit before our runway evaporates, as well as all-too-short “peacetime development” periods when we could gradually improve products, pay off tech debt and scale up the tech organisation.
My overall experience spans the telecom, consumer identity and access management, fintech and climate tech industries, though with a heavy B2B bias.
In my engineering career I have been an individual contributor, a manager, a senior manager, a senior director, a VP and a CTO - somehow skipping the director of engineering step.
Culture-wise, I have been dropped into toxic nests of vipers, joined bands of bros without a mission, witnessed developer-worshipping quasi-cults changing the world, guided teams painfully transforming from a “cool and chill” to a high performance culture.
I have managed talented teams in six different countries, the UK, Mexico, Colombia, Estonia, Germany, and Mauritius for startups from the UK, US and Mexico. I engaged with brutally direct Israeli colleagues, politically correct Californian workmates, workaholic Ukrainian developers, reserved Estonians, effusive Latin teams, etc. I feel like a walking, at times wonderfully confused, Culture Map!
My teams and I have built backend software that runs on-premises and in the cloud, executing mission critical workloads with 99.999% availability, routinely processing hundreds of transactions per second. On our way to operational excellence we’ve had to overcome hellish production incidents and vicious DDoS attacks - often caused by bugs in our own customer’s code!
I have recycled reams of paper and donated countless books describing once popular tools, techniques and methodologies that are now niche or extinct: CASE tools, expert systems in Prolog, software project management using PRINCE or RUP, SOAP APIs implementations, UIs developed in Smalltalk, etc. Conversely, I have come to value the enduring wisdom of all-time classics like the Pragmatic Programmer, as well as works by Patrick M. Lencioni and Gene Kim & Jez Humble, among others.
I could go on and on. It seems I can pick good materials for a talk from my career. Nevertheless, there’s a risk of fragmentation, incoherence and lack of clear breadcrumb trail to follow. I can already picture my confused and bored audience anxiously eyeing the exit door and smelling the cookies waiting for them outside!
I need a compelling thread, one that will be memorable and resonate strongly with the engineering leaders listening to me, providing genuine insights they could leverage in their day-to-day work.
I must be careful not to fall into the trap of over-generalisation and cargo-culting so-called best practices, applying them blindly to the wrong context. Thankfully, decades of software development practice have revealed effective frameworks to increase the likelihood of success for product development work classified as complicated or complex in Cynefin.
My hypothesis for this talk is that there’s a meta-framework that software engineering leaders can apply to intelligently avoid some of the pitfalls of the evolutionary journey from an early stage startup to a growing scale-up.
The diagram below has been copied from Martin Fowler’s excellent Web site and lists some of the initiatives that a company might be focusing on throughout its growth as it transitions from startup to scale-up.
Self-evidently, technology is always a key part of a tech startup’s success and CTOs play an instrumental role in steering this function from one phase of growth to another.
Many common scaling bottlenecks stem from issues deeply rooted in the tech org. Consultancy Thoughtworks has documented a dozen of those bottlenecks, outlined below:
Accumulation of tech debt; experiments and shortcuts are core components
Cost of serving traffic is too high
Current organization structure doesn’t support current scale
Cannot find the next product evolution to delight existing and new customers
Complicated internal team and partner dependencies
Legacy technology from integration partners or acquired companies
Overcomplicated distributed architecture (microservices)
Built without resilience and observability in mind
Developer productivity has dropped as organization grows
Inability to find talent; Hard to attract and no efficient process to onboard and upskill new team members
Building out extensive rules based system, instead of leveraging ML/AI
Additionally, according to 2011 report from Startup Genome, up to 70% of high-growth startups scale prematurely and many fail as a result. Based on a more limited data set over a longer time-period, my own empirical findings suggest that
Not achieving product market fit is business risk #1. All three startups I co-founded failed because of that reason, in conjunction with the next issue.
The most common error of smart engineers is over-optimising something that simply shouldn’t exist (a nugget of wisdom courtesy of Elon Musk), thus slowing down the learning rate of their company and sinking its ROI.
Too frequently, developers are far removed from the market and do not walk in the customer shoes, increasing the risk they’ll devote themselves to white elephant projects.
Weak product leadership is the norm, their lack of customer insights and subject matter expertise contribute to engineers building the wrong thing, resulting in waste taking the form of an ever-expanding inventory of seldom used features.
To make matters worst, feature teams dominated by Product almost always turn into soul-crushing feature factories characterised by spiralling tech debt.
Trust is undermined, especially between Product and Engineering, compounding those problems. There’s widespread fear to share constructive feedback.
Tribal behaviour impedes systems thinking, promoting overly localised solutions that do not address true business problems.
A lack of end-to-end ownership by developers, from design to production, creates a myriad of handovers that waste time and break virtuous feedback loops.
Consequently, cycle time gets too slow and progress sluggish, giving the competition an opportunity to catch up.
Delayed hiring and weak knowledge sharing turn a few “Brent” team members in Engineering into potent capacity constraints and bus-factor risks.
Short-sighted use of contractors with zero skin in the game contribute to the mounting tech debt amassed by the feature factory.
Meanwhile, everyone is so busy on Business As Usual (BAU) tasks in their own silos that dependencies creep in as the code-base becomes more complex, further stalling delivery.
I realise I could keep on adding to this list but the main point is clear: these problems stand in the way of delivering “Good Software”, a concept I define below, which is critical to a tech business’ success.
“Good Software” efficiently addresses users' core needs and is delivered in a timely manner, achieving a robust return on investment (ROI). Sustained growth and user satisfaction is realised through continuous evolution, meeting the changing market demands and user needs, while the software remains reliable and secure.
Wrapping up this post, an initial outline for my upcoming presentation has emerged, building upon my breadth and depth of experience with tech startups as well as pre-existing frameworks from recognised thought leaders:
Introduce myself, to establish my credentials - why should anyone trust me?
Clarify that the presentation takes into account the Cynefin framework and applies to complicated and complex domains.
Use maps, such as the startup growth phases from Martin Fowler, and maybe Wardley maps, to illustrate the arduous journey of a CTO and the pitfalls that are awaiting her at every step.
Cluster together those scaling problems into categories like culture, people, architecture, etc. and match them to stages in the map.
Identify battle-tested mitigations that can be implemented preemptively to avoid falling into these scalability traps. Keep the list short, covering only the top 1 to 3 risks in each category.
Sprinkle the slides with references of seminal books that attendees could peruse.
While this is a reasonable skeleton for my talk, it is quite dry and probably not memorable. My audience will fall asleep and miss their cookies. This is unacceptable, I need to make my narrative more visual.
Anyone who works with me will tell you that I love metaphors. I can immediately think of two analogies that could make my content more engaging:
Relate it to a video game character, ideally from a vintage title of the 1980’s. The character would collect tools, spells and weapons to successfully overcome all dangers and successfully complete the quest (let’s call this, Series C).
Given my current line of employment, use gardening or farming as a metaphor, with the main character being a small team of astro-farmers stocking up on hay for a tough winter on Mars, or getting rid of weeds threatening their lovely and vital tomato plants. The “team on Mars” twist to the story will reinforce the complex, never-done-before, nature of most software development endeavours.
In both cases, I could use image generating AI to produce those visuals. Nevertheless, the cherry on the cake would be to invent a new type of startup scalability map that any tech leader could use.
This is food for future thoughts. The clock is now ticking!
Note: I hope you have enjoyed this post. I would be incredibly grateful for any feedback - let me know if you feel I’m going in the right direction - or if I should just let the audience eat all the cookies :)