Dumb stuff I did early in my career

Mistakes are an even bigger waste if you don't learn from them.

Photo by Pawel Janiak on Unsplash

In the 90s, early in my career, I worked for an entrepreneur who loved side projects. He'd built a successful games company and branched out into various directions, including web publishing tools, 3D video and 3D motion capture. But with these successes were also a lot of duds and lived on longer than they should have, sometimes putting a financial strain on his core business. It's easy to be a detractor and find reasons not to try something, so I respect people willing to try things and fail.

All of these projects were fun to be involved with. Even though many could be classified as hare-brained (a quick etymology check to ensure I am not accidentally deploying an offensive term - no, it refers to hares maybe because they are skittish or because, unlike rabbits, are foolhardy and don't burrow underground). Anyway, I didn't know any better and enjoyed helping make them happen. Still, upon reflection, these were fruitless diversions for which the seeds of their failure could have been detected with a bit of forethought and testing assumptions as we went.

One such diversion was an idea they had about picking some web content and compressing it into an executable package that could be emailed to someone else who could then open it and view that content. The technical challenges of this were very appealing, so we were keen to overcome these and make it happen. Could we compress the size down to be a small enough attachment in an era where many still relied on modems for internet access?

Early in the web growth, we began working on this - pre-year 2000. The tech for compressing and decompressing a bundle of files was something we had from our core business. Right from the beginning, one fatal flaw was an idea based on sending executables via email! The internet was fast, realising this was one of the most common ways to transmit viruses. The messaging about 'beware of email attachments' was already increasing.

This was an idea that was inspired by an imagined need and a lot about what was possible with the technology available.

This post is about about dumb mistakes I made. The idea for the project was not mine, so whilst these parts were likely a mistake, they were not my mistake. My teammates and I had challenged the entrepreneur on some assumptions that seemed (and ultimately proved to be) flawed before eventually dutifully setting out to build the tool he had dreamed of.

The mistake that I was responsible for, and from which I learnt the most significant career lesson, was of a similar nature. Given that the whole project was an untested idea, the critical part was to test and see if real people would actually use it. The distractions I contributed also delayed testing out whether people would use the app's core functionality. If I was truly skeptical of the untested assumptions of the entrepreneur, then testing these is where my focus should have been.

I didn't, though; I had my own untested, risky assumptions I wasted time on.

During the construction, I got hung up on implementing a few features. Firstly, I was significantly influenced by popular apps at the time, such as WinAmp. WinAmp had a very stylised UI that broke from the Windows UI conventions. By comparison to most apps, it looked very cool. I decided this approach was a must for our app, given that it needed to be consumer-friendly and widely adopted (but I think we were more keen to work out how to do it technically).

The other was adding web-grabbing features. We wanted to be able to pull web content from online and help people send this to others. Presumably, the benefit of this feature over sending someone a link was that the webpage you grabbed was the same as when you saw it, where a link might point to content that kept changing. Hindsight would suggest taking a screenshot would be adequate 90% of the time. This is a good example of Jobs-to-be-done theory in practice - multiple adjacent alternatives are better options. If you'd like to know more about this idea I suggest reading 'Competing Against Luck' by Clayton Christensen.

The engineers quickly had a single-threaded web capture which would read a page and all of its referenced files. I didn't think it was fast enough, so I wanted a multi-threaded implementation. Again, we haven't even tested the base app with users, so this extra functionality would only make sense should our underlying assumption be true: people would willingly send executable email attachments to each other frequently. Fortunately, the engineers eventually talked me out of it, but not before venturing substantially down that path and wasting time.

I also thought there was potentially lots of content such a web capture mechanism would grab, so I started designing an interface that would show the progress of what was getting sucked down and open up the opportunity to select what wouldn't be included in the package. It was over-the-top for a supposedly consumer-friendly app and likely detracted from that.

Ironically, even after wasting some time on these features, the requests from my boss kept coming thick and fast. Requests for templates for things like birthday cards and other things we could build out of web content. Add UI wizards so these can be populated with custom content. Of course, to make that work, we had to add a template engine and so on. The app kept getting bigger. The potential uses we imagined for it kept growing. And it still hadn't been used by a single user outside our team.

It got to a point where this crazy app desperately needed to be tested with real-world usage. This was a point of contention with my boss as they had many more ideas for functionality. I was starting to see the error of my ways, and the app appeared to me as a big bundle of untested risks.

We had some decently trafficked sites from some other moderately successful products. We hatched a plan to use that traffic to advertise this tool aggressively. We pitched it to the boss.

He said no.

We did it anyway.

The one thing we did that wasn't a mistake.

The initial telling-off I got was quickly rescinded once it was revealed that there were 2500 downloads in under an hour. He started to get excited.

That was short-lived. Within a few weeks, it was evident from the app's usage that this was a collection of functionality that didn't solve any problem that people who installed it had.

We soon wrapped up on that side project and waited for the next one.

I don't feel bad about my mistakes - in the whole scheme of things, they are relatively minor with this folly of a project. I was young, and in the 90s, almost all software development was based on these sorts of gut decisions. I am proud that I eventually recognised them and learnt from them.

In the following years, such experiences led me towards agile software development, 'lean startup' methods, outcome-thinking, strategy and beyond. I am not ashamed of my mistakes; I wear them with pride. I am most proud of the introspection which led me to seek and try different ways and find a better path forward.

What mistakes have you made during your career? Which ones were formative to who you are today? Please share your experiences in the comments.

If you liked this post, please let me know by hitting the ❤ - it means a lot as a writer to get feedback.