The Best Things I Ever Did Were Accidents

or “There Is No Breadcrumb Trail”

Back in 2004, freshly graduated from university, I didn’t have the foggiest idea how to launch my career. I possessed no realistic vision of how to achieve success, but I sure as hell had a fantasy of the result: me at the helm of a modest sized company with a few dozen employees, revenues of a few million a year, living in wealth and luxury whilst not being too pretentious.

My plan to achieve this blurred vision was straightforward:
Stage 1 = learn to code and get a degree
Stage 2 = ?
Stage 3 = profit

With Stage 1 complete I was about to set off into the world of work, kitted out with bags of ambition, a satchel of high hopes, and a bumbag of naivety.

To start I needed a job – any job, just so long as it was in IT. I knew for a fact that once I’d gotten a bit of experience under my belt (and more vitally on my CV) life would get easier, but getting that first position – a foothold on the employment ladder – was to be the most excruciatingly painful part of my working life so far.

After a fuck-ton of unsuccessful interviews I eventually found myself faced with an offer of a good salary and an easy 15 minute commute to a nearby tin can factory. I never intended to get into the manufacturing industry, but it was a job, and that’s all that mattered. I accepted the offer and felt resplendent with my very first job title: Analyst Programmer.

My “Analyst Programmer” role immediately morphed into a systems administration one, as a result my career had stalled before it had barely started. A little over a year later, on the day I decided to look for another job, I received a letter from my university’s alumni association. As luck would have it the letter contained a job description; the university was working in partnership with a local food factory that was looking for a young and ambitious software engineer to take on a two year project. It felt perfect; I needed a challenging position to get my career back on track.

After two extremely involving interviews (in the first I had to give a presentation of how I’d architect a shopfloor production management system, in the second I was interviewed by six people at 7pm on a dark winter’s evening) I was offered the job at the food factory. My modicum of experience in the manufacturing industry (apparently rather rare amongst IT people), had helped to swing it. From Systems Administrator (nee Analyst Programmer) I became Systems Development Manager, in an IT department of one: me.

Spin forward in time, and as the two year project approached its end I was at an impasse. My job remit had given me much responsibility and had taken a Herculean effort to complete, and during those two gruelling but enjoyable years my sense of ambition had been revived, since festering at my first job. Going back to a regular nine-to-five didn’t appeal. I attended several interviews but nothing clicked; the jobs didn’t inspire me, thus I was lacklustre and was offered none of the permanent roles I applied for.

Ultimately I accepted a two month contract coding gig, perfect for earning some money while I figured out what to do with my life. The world of contracting was new to me, this being only my third job, and I was surprised and delighted by the substantial remuneration, given that I was still a green 24 year old. After a couple of weeks I began to think: “Contracting might not be just a stopgap, maybe this is the dream?”

This contract job was at my old university, and now having this education sector experience on my CV helped me get another contract position: a 6 month stint across town at the county’s other university. This second contract came to an end in November 2008, and as the credit crunch tightened its grip the IT job market tanked, both permanent and contract. Especially contract.

By January 2009 the job scene was still desolate, and only one of the few interviews I’d had was for contract work. I consider this interview to be the worst I’ve ever had. The first half of it – the talky bit – went great, but things turned bad in the second half – the coding test bit. The interviewer asked me to produce a tiny Winform application that interfaced with SQL Server, demonstrating the basic SQL CRUD operations. The crux was that it had to be done sans internet; there was to be no point of reference. I’ve always been one of those coders who commits no specific functional syntax to memory – I prefer to free up my “Head RAM” for more important logical task crunching.

Thus I was, in short, pretty fucked. I failed the coding test with flying colours – after being left on my own I spent ten minutes considering my options, then called the invigilator back in to explain that I couldn’t do it, and I got up and left with not a single line of code written. I drove home miserable and clogged with self-doubt.

With no work on the table or horizon I panicked, but the fear soon subsided, to be replaced with an urge to act. My prior contracting work had allowed me to gouge a hefty chunk out of my mortgage, so my outgoings were relatively modest. I created a budget spreadsheet, chronicling my typical monthly expenditure, so I could plan my actions. I cancelled my Sky subscription and downgraded my mobile phone contract to the barest minimum. I sold all my DVDs and CDs, and about half my books – ultimately I was to trawl through all my possessions, wheedling out things that could be hawked on Ebay to generate cash on which to live.

Decent work was still hard to come by, so I filled my time with dribbles of paying jobs: installing a replacement keyboard in a laptop, building a little Winforms/Access database system, making various Sage Accounts reports, mowing the lawns (and picking up the accompanying dog shit) of my brother’s rental properties – if it paid then I did it. After months of living off scraps and eroding my savings, in September 2009 a friend’s company asked if I’d build a custom ERP system for them, a project which made my eyes sparkle. The eventual invoice was the best part of £10,000, and I finally accepted that the self-employed life was truly for me, despite its ups and downs.

But pure self-employment wasn’t where I stayed; at the beginning of 2010 I rejoined the food factory. The deal was that if I worked for them for a year – developing new add-ons for my previous systems – the directors would fund a venture to launch a new startup; building factory management software, something in which I was now extremely experienced. But the path of true startup love doesn’t run smooth; progress has been slow (“It takes years to become an overnight success,” is one of my go-to business proverbs, and this probably means we’re not actually a “startup” in the nominally correct sense of the word).

Thus I have had ample need and opportunity to embark on other ventures with which to line my pockets. During the past four and a half years I have launched other businesses, developed other products, beavered on other side-projects, and even found time to re-establish my contract consulting. All of these things run side-by-side, albeit a little clumsily. The ultimate plan is to build several of them to a stage where they can be backgrounded to earn money on autopilot, or flipped and forgotten about. That’s my plan anyway – whether it’ll come to pass is anyone’s guess.

Eleven years later, “Stage 2” of my career vision remains an enigma. I wasn’t one of those fortunate people who instinctively knew their calling in life from a young age, to aim every fibre of their being at it from the very start – I’ve just bumbled along and tried to keep my head above water, and despite making it all up as I go along I seem to be doing OK. Am I wealthy enough to never have to work again, as per my dreams? No. But if I chose to live off my accumulations I could survive for at least 5 years without having to lift a finger. But that’s not me.

I’d love to give this piece of writing an underlying battle cry, to finish it with some pearls of wisdom to bestow, but fuck it: don’t listen to my advice. I’m just another chancer, another wantrepreneur stumbling along in my own little way, trying to carve out a slice of something resembling success, which I can’t even imagine, and don’t think I’ll know when I see it.

Wanting to learn from others’ mistakes is fine, and it’s important to not get lost in trying to learn from others’ successes. Time is better spent doing, discovering, unearthing and sculpting knowledge, chopping your own path, learning your own lessons, making your own mistakes, and making your own good advice. Most of all, I’m glad I embraced the things I never intended to do, because, in the fullness of time, all my accidents were somehow done on purpose, and led me to where I am now.

Ultimately: I’m where I am today because I didn’t try to get here.

A Big Cog in a Small Machine

Or a big fish in a little pond. If your business grew to an unimaginable size, would you be happy?

I work for myself because I have an authority problem.

I have a problem with other people in authority. I have a problem being a part of someone else’s dream. I intend to never work directly for anyone else again, because I’d sooner be a big cog in a small machine than the other way round. Repeat clients are fine and dandy, but when building things for them starts to feel like a job I know our working relationship needs to be adjusted, or it will surely be doomed. This is all just context.

My most pressing side-project is a fledgling e-learning system that’s been in the works since June 2012. It was my friend Leon’s idea, his baby. He roped me in during the neonatal stages, needing someone to turn his Excel spreadsheet prototype into a web application. I became the technical cofounder.

Now, after almost three year and a couple of minor pivots, we’re approaching a release date. We aim to go live on 1st April 2015, and I’m nowhere near ready; still plenty of slog work to do. I’ve got some busy weekends ahead of me.

Three weeks ago, on the night of Wednesday the 14th at a coffee shop in Nottingham, Leon introduced me to Jonathan. Jonathan is new to me, and we’re vetting him to see if he’ll make the ideal third cog in our small machine. He’s a maths teacher and YouTuber, adept at producing polished and professional instructional videos that look like they weren’t just hacked together at a moment’s notice. Leon, for all his abilities, isn’t a details guy – he drags projects forward by weight of charisma, and isn’t afraid to throw money at something when his own capacities fall short. Our second meeting with Jonathan is tonight, and whilst we haven’t come to a decision yet I expect that he will join Leon and me as shareholders as we push to get this thing off the ground. Jonathan possesses the three things that I was specifically looking for: (1) he’s good at what he does, (2) he’s ambitious, but (3) his temperament is closer to mine than Leon’s. That last one was an important feature for me; I need all the help I can get when wrangling Leon’s focus. I need someone who isn’t easily distracted.

Over the years I’ve grown used to Leon’s ways. His ability to pitch ideas and recruit acolytes to his cause has to be seen to be believed. He possesses a nucleus of eager energy akin to a force of nature, and because it isn’t an act – it’s just him – he can’t help but use these skills to full affect. In turn, when in his presence my subconscious automatically adjusts my own enthusiasm levels, compensating for the overload in the room, and thus I become more cautious, more naysaying. In my head I instantly halve the number of any target subscribers/revenues/profits/growth percentages he quotes at me, not because I don’t believe they can be achieved, but because I’ve been bitten by other people’s excited estimates before, thus I now refuse to let myself join in anyone else’s excitement. I’m constantly primed for a horrible fall.

On the Wednesday, towards the end of our two-and-a-half hour discussion, the clock edging towards 9.00 p.m., Leon fervently stated his expectations:

I’m certain that, by the end of our first year, we can have 10,000 sign-ups, at £100 per time for a 12 month subscription, giving us a £1 million revenue.

In my head I halved this to 5000 sign-ups. I then halved this again to 2500. I then halved it again.

Call me dispassionate, but I set my sights much lower. If we get one thousand sign-ups I’ll be over the bloody moon; that’s my target, for the first year – ten times that seems ravenous. If we do reach that number I’ll happily admit that I doubted its achievability all along.

Toying with the notion – if the business did turn £1 million within its first year we’d have to expand operations. The three of us would need to bring on staff immediately, to produce improved video content, to translate learning materials into multiple languages, to write website copy, to manage social media interaction, to evolve the web application…so from the topic of Leon’s ambitious targets the discussion turned to our longer term aspirations for the enterprise. If, against the power of my pessimism, it’s a roaring success, how would each of us expect our roles to morph as the business grew? Leon, as The Big Boss, would still be at the helm. It was his idea, and whilst he may lack overall business acumen I’ll take his hustle any day of the week. If Leon is the marketing cofounder, and I am the technical one, then Jonathan is the content guy, and if we’re to grow successfully then we’ll need him managing the creation of videos and documents that can prise open the enormous foreign markets that both him and Leon have an eye on. Leon plans on having a business ultimately worth £100s of millions…if we execute things right. I told him that I’d happily sell up if we reached a £10 million valuation.

What I didn’t tell him was that I’d actually accept a disposal at much less than that value. On the current face of it, pre-launch with precisely zero paying users, I’d accept a future valuation of £1 million. I say this because, to me, the enterprise isn’t mine. Pre-Jonathan, nominally I have a 40% stake, Leon the other 60%. This business is both Leon’s and mine – his core concept having been developed and brought to life by me – but I still feel that I’m just a cog in his machine. This is fine right now, drifting along as the big cog in the small machine, but if, and it’s a big if, it becomes what we hope it might, will I want to be the big cog in a big machine?

I don’t know if I’m built for big business, even if it is mine.

How Not to Build Phone Apps: A Post-Mortem

The lessons learned from an Android app development side-project

It was an unintended consequence, but publishing my previous article on the trials and tribulations of developing mobile phone apps has curiously resulted in a spate of job offers. It turns out that a little honest contrition over a failed endeavour is brilliant at establishing credibility on a subject.

The previous article was the backstory, and this follow-up is the post-mortem; what did we learn? What could we have done differently, and what strategies and tactics can we take away from our disorganised attempts at phone app development?

Capitalise: Quickly

I hate having to recommend that people must work fast to succeed. Whilst I have a reputation for blitzing rapidly through pieces of work I do like to take my time over certain key tasks, unafraid of allowing some mulling time to let my subconscious do its background thing and solve some problems while I daydream. Unfortunately, in our little skeleton crew at Twelve Gauge Software, time was always of the essence.

In the previous article I labelled our endeavours a failure, and this was a misnomer; it was a mistake for me to describe things in that manner. We’ve had around 30,000 installs of Indoor Cycling Coach, of which a third are active; a retention yield that is massively above the mean average (the typical yield is more like 10%). The failure was not that we built something that didn’t work and no one liked – we succeeded on both those counts. Our main snag was that we failed to capitalise on our initial success, with hindsight we should have had what I’ll call a “roll on” plan, that would have come into play after our “roll out” of version 1 had been completed. Everything we ever did was pure improvisation, and because of this we never anticipated the popularity of Indoor Cycling Coach, and never considered planning further ahead than the initial version that we were in the midst of building. We’d have been happy to grab a few hundred active users, but when you reach 10,000 your userbase begins to have some weight, and this can work both for and against you. If we’d planned for the eventuality of actually being popular we could have put advance work into the Premium version (that we still haven’t gotten round to releasing), but instead we stagnated, floundered and flapped about, bouncing from one crisis to the next. For example, if I’d thought about the possibility of us releasing a Premium version then I could have started algorithm design on the new workout routines whilst Danno and Dean were finishing off the Lite version. The effort put into this preliminary work wouldn’t have paid off until maybe six to nine months later, but when the time came around to actually begin proper development work on V2 we’d have been ahead of the game, and the burden much more manageable. I didn’t make the best use of my downtime.

Hype: Synchronise it

Pre-release publicity is great, especially when it’s free like ours was – but unfortunately our BBC media coverage could hardly be called “pre-release” as it came almost twelve months prior to the launch of the product. If you’ve read the previous article then you’ll know that the timing of the BBC exposure wasn’t our own fault, but regardless of this I didn’t manage the resulting interest from the TV coverage with any great panache. Whilst I did get to add many emails to our mailing list I don’t like to think about how many people slipped through the cracks: how many made a cursory search for the app, found nothing, then didn’t go to the lengths of finding out who the developers were and contacting us directly? It’s a safe guess that the people who did get in touch were the minority.

The solution is to have a proper mailing list setup and ready to rock, long before you do anything else. Having the facility for users to sign-up to a mailing list is vital, and I dropped the ball on this. We didn’t have a mailing list until the very first email arrived from an interested prospect, wanting to know where the app was. Even after this we didn’t actually have a “proper” mailing list, as for some unfathomable reason it never occurred to me to create a quick MailChimp account to house the emails we were collecting; instead I manually housed them in Excel. Beyond the storage convenience of using a managed service we also missed out on a more useful and obvious feature; the ability to insert an automated user sign-up form in your website. I only added emails to my list when people contacted and asked to be kept in the loop, but a simple subscription form (like the one I’ve had for ages on my own fucking website) would have built our subscriber list without the hassle. Obvious: yes – but in the heat of the moment it never occurred to us, our heads cluttered with the burden of product development: the thirty or so names on our mailing list hardly seemed worth worrying about.

Anticipating future interest – and thus setting up a mailing list subscription page on our website in advance before we hit deep water – would have saved so much time and stress later, and we could have fired off regular emails to our growing list of subscribers, to keep the fire of interest fed over our lengthy run-up to release. I fear interest in the app peaked way too soon, and thus a shepherded mailing list would have allowed us to regulate our fans’ curiosity, to discharge it at the correct moment. A sense of timing is very useful.

Maintaining momentum: Fits and starts

Progress atrophy is one of a skeleton crew’s biggest threats. If your DBA goes on holiday for a month and she’s the only one capable of doing anything with the database then you can bet your arse that as soon as their plane takes off you’ll realise that all your blocking tasks are database related. All you can do is twiddle your thumbs and wait till they get back. Whilst this specific example didn’t happen with us we certainly had moments where we needed a teammate to complete his bits of work before we could start ours.

Even a tiny amount of knowledge is fine here, as all you need to do is keep moving forward. A slow trudge is better than nothing, and just keeping the momentum going at a miniscule level is acceptable. Blocking tasks shouldn’t have to be left unattended; they should be chipped away at. Ignore those who say that “a little bit of knowledge is a dangerous thing”; you should have backups, you should have source control, and (back to the example) the DBA can polish or reengineer the shit you produce when she gets back – you can’t irreparably break anything, so why not get stuck in? The aim is to remove the blockages any way you can, or at least chip off enough of them to permit progress for the rest of the team, to keep productivity above zero. This leads me to the next point.

Team Responsibilities: Jacks-of-all-trades versus specialists

Being ignorant of alternatives (though when we first started there weren’t many) we opted for native Java-centric Android development, and only one of the three of us was a Java programmer. We were hobbled from the get-go; locking ourselves into a narrow skill ownership, direct responsibility-based structure that was clearly unsuitable for a tiny startup-esque enterprise. In a three person team you can’t afford to specialise.

I’m not saying that everyone shouldn’t have their own primary role – the job that they perform most often because they are the best at it – but each person should have enough knowledge to be able to do the tasks of everyone else if required, even though this might only be a merely functional level of ability. In hindsight, when the tools became available, we would have been better rebuilding Indoor Cycling Coach from scratch as a hybrid app, as all three of us know JavaScript and HTML. Multi-skilling and the ability to job share is paramount: things would have turned out so very differently if we’d had more skill overlap.

Words and pictures: Group communication and idea collation

For communication, remote brainstorming and idea collation, use whatever technology is easiest to implement and use, even if it lacks fancy complex features. The simplest and fastest thing to use will get used, and the all-singing-all-dancing software that does a million other things will get ignored and neglected.

Don’t waste your time on it. Enforcing a technology on a team is difficult, regardless of the team’s size. If you find that a big “Reply All” group email is working well for you then that’s fine: go with that. Email will always have a place in this world: ignore the naysayers and cult-of-the-newists who build products that tout that they are a “replacement for email” or are sounding the death knell that “email is dead”. SaaS product startups need to cotton onto the fact that email doesn’t need slaying or replacing, it needs powering-up, to be used in new and interesting ways.

I digress. At Twelve Gauge Software we started off using Google Wave for discussion and idea collation, and I was a massive fan of it because it just frigging worked. Typing text in a box and clicking a button, and then it was up there, straight away, no bluff or bluster. At its core Google Wave was little more than a forum CMS with added beef and poncey functionality, but those extras were simple and seamless and didn’t require additional effort from the user. Clearly my love of Google Wave put me in a minority, as it was unceremoniously shut down, and since then I’m yet to find a web-based group brainstorming tool that I like as much. Until I do I will continue to use simple email and chat channels as my comms system of choice for small teams.

The Long Haul: Know what you’re getting into

…and letting yourself in for – the time commitment will be several multiples more than whatever you’re planning for. If we’d have known just how much effort would have to be put into Indoor Cycling Coach would we have started it in the first place? Perhaps not.

The fun and the adventure we had along the way were more important to us than the finished product, but it’s still hard not to be disappointed when there’s no end in sight. During the day-to-day grind (or evening-to-evening grind in our case) you don’t consciously clock how many hours you’re putting into something. It’s only when you’re sat at your laptop trying to make sense of the Google Play developers’ portal – on the afternoon of Christmas Day – that you realise things have gone off-track a little. You must accept that there will probably never be a finish line: new ideas for features to implement will spawn, new platforms to reengineer for will be released (for example the tablet market didn’t really exist much when we started), the bugs will keep on coming, and the work just spools out over the horizon to infinity. If you don’t love the product you’re building then you might be better off waiting for a better idea to come along, something that you won’t mind giving up your free time for.

Conclusion

Anticipation is the key. The overarching theme of my observations is that a bit of preparatory work, in advance of jumping into development and coding, will pay-off massively later on when you haven’t got the time or concentration to spare. One of our initial tasks was a brainstorming evening to come up with suitable app ideas, but as soon as we had decided on a feasible idea we should have had a second brainstorming session; to expose our thoughts on the vision for the app, whether we can guarantee to support it in the long term, or whether we’d get it up-and-running and then flip it to someone else to look after. We had no future vision – we were just making stuff up as we went along. Setting yourself up correctly at the start won’t suddenly make everything easy, but it will make everything easier.