After several months off, I’m back. This article was originally written for the inaugural edition of my Alma Mater’s engineering student magazine. Enjoy.
The Happily Unexpected Consequences of Engineering School
I have always held a deep, energetic passion for technology. When I went to study a double major engineering degree at UCT [University of Cape Town], I was excited. What would I learn? Who would I get to work with? How will I use these skills in my career one day? These are common questions for any young student. In my case, after leaving university I quickly crossed over into a path of entrepreneurship, where I would I get a crash course in sales, marketing, fundraising, HR and several other areas that I was never taught much about in university. After enough people asked (and continue to ask) me, “Do you regret what you studied?” I pondered this carefully and decided that my answer was a resounding “No”. I have realized that while giving me explicit skills in a couple of technical areas, my experience studying engineering also equipped me with a number of implicit skills that I didn’t even know I had until long after I graduated. It was as though I was building a hidden toolbox of assets over those four years, and in the years since, I have seen that hidden toolbox continue to help me along. You might be wondering what I mean exactly. In this letter I have shared just a few stories that may illustrate my point.
Thinking back to my engineering classes at university, I can recall various courses where the final deliverable had to be a working demo or functional prototype of some sort. I remember building an alarm prototype for Embedded Systems, writing a predictive text program for Computer Science, and even whipping components together on a breadboard to do interesting things with 555 timers in Introduction to Electrical Engineering. The specific assignment isn’t what mattered- what mattered is that they forced us to build stuff and make it work.
As we all now know, there is a marked difference between theory and practice. Sometimes, things don’t always work out the way the manual stated they would, and we need to do a little trial and error. At other times, we need to create a hack or workaround and pray that it holds up under testing until we have time to develop a more fundamental solution. Things don’t always proceed as planned or on schedule, but deadlines are deadlines. And it has to work, or you could fail. This sounds a lot like a real world product development cycle. In startups, tiny teams are forced to create working products in a short space of time, and it’s hardly ever as clean and straightforward as one reads about in business literature. Fortunately, all of those thoughtful planning sessions and hair pulling fault-finding missions during practical assignments offer a solid foundation for us. Engineering grads are rarely frightened by the challenge of creating something new.
In my first year of studies, my classmates and I quickly became swamped with work. Tests, projects, assignments, and the dreadful tutorials piled up. Tutorials were particularly hated, because we had to submit them or risk being disqualified from the course, but their marks didn’t count toward the course grade. At that time, I was living in a university residence, and a clever group of around eight to ten disgruntled like-minded students decided that something had to give. (I cannot confirm if I was one of this group because the story to follow is a little incriminating). Battered by mounting work volumes and not enough time to get everything done well and still enjoy university life, these students developed a novel solution to overcoming tut submissions. Every week, the group nominated an individual who’s job it was to do the tutorial for a particular subject. The night before the morning submission, the group would band together in a res room, as though a clandestine political party meeting were taking place. The person who did the tut would then have to rapidly take the group through the exercise, explaining how he reached his answers and the methods used, and members would have a chance to pose any questions. Once all were satisfied, the original pages of the tutorial solution would be distributed among the different members, who would then creatively copy (e.g. swap variable names etc.) the entire document in rapid assembly line fashion. Seeing the group effectively distribute different pages among each other and cross check each other’s work in a lightening total time of under an hour was a remarkable sight. In the morning, a postman from the group was nominated to submit everyone’s tuts while the others attended their lectures or decided to sleep in.
Now, I must admit that this was probably (definitely) breaking the university’s rules. And while rule breaking isn’t something that I expressly recommend, it’s something that entrepreneurs often need to do. (Besides, it’s easier to beg for forgiveness than ask for permission anyway, but I digress). While that group of students were possibly “harming their education” by not doing all of their homework solo, they were actually learning hugely valuable lessons in adaptable team work, managing overload, and operating in the margins where those who follow all of the rules wouldn’t care to tread. People strong in these traits are golden to startups. I’m not surprised that many of the people from that group in first year went on to pursue highly entrepreneurial careers.
My next story happened much more recently, around two weeks ago. I was in a casual meeting at a coffee shop with a successful Internet entrepreneur and über-geek, and we were discussing a little business. All of a sudden towards the end of the conversation, the following exchange took place.
"So, I assume that as a business guy, you haven’t ever written a line of code in your life" he said.
"No. Actually I have been a techie since I was a kid; I was a programmer for several years and studied Electrical and Computer Engineering at university" I replied.
"Oh, that’s cool. I was just checking. So if I asked about using a CDN to speed up load times you’d know what I was talking about."
"Yes, we could have a nice debate about the merits of AWS plus CloudFront versus an optimized local box to increase app speed…"
Recognition flashed across his face, a wry smile developed in the corner of his mouth, and we continued to wrap up the business at hand. This type of conversation has happened over and over again in my career as a technology entrepreneur. Even though I don’t work as an engineer anymore, I interact with engineers and technically minded people all the time. And the simple but unfortunate fact of the matter is that if you haven’t earned your chops in a technical faculty before and are unable to stand toe to toe in a technical discussion, they simply won’t extend the same level of camaraderie and mutual respect toward you as they would to one of their own. In my experience, business is mostly a practical skill that can be picked up on the go, while engineering requires deep understanding and conceptual frameworks that are less easy to learn “on the job”. So even though I’m not an engineer anymore and I have crossed over to the business side of the outfit, I am still lucky to be considered as an insider and team player by the technical folks, and that matters massively. To best work with or lead people, it’s essential to understand them.
Casting my mind back to graduation day all those years ago, I distinctly remember feeling elated- but this was an equal mix between a sense of achievement, and a genuine sense of survival. I’m sure you know what I mean. When looking at that result after a difficult test or exam, sometimes the first thought that comes to mind is not “Look at my incredible mark!” but rather “Wow, I didn’t fail!” Studying engineering is hard. But then again, business is no picnic either, and it’s good to be tough. The outcomes are worth it. And as I am continuing to learn in a career of entrepreneurship, engineering students tend to develop some unexpected but highly useful tools that pay dividends for a long time to come.