The Happily Unexpected Consequences of Engineering School

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.

Hiring for Startups: 10 Clear Markers For a Great Fit

Building a strong team is one of the most important directives of a founder. There are many facets to this, but the most obvious and beneficial one is hiring the right people. 

We’ve recently made some new hires at Personera, and the process made me aware of a couple of key “go/no-go” markers that show themselves again and again. So what are some of the strikingly common as well as more nuanced factors when deciding if a candidate is a good fit?

This is my litmus test:

Positive Markers (“Go”)

  1. Smart and motivated: This is needs to be determined right at the starting gate. Any good team member is going to need to be smart because of the fast pace of a learning that takes place in a startup, and their motivation level will influence their ability to persist through the oftentimes tough three to six month beginning period to see what comes next, not to mention giving them an important sense of pride in their work.
  2. Extremely keen to join company: This is more important that people think. When a candidate is genuinely excited about a company’s product, or people, or both, that passion leads to much a better fit and sense of stickability with the startup over time.
  3. Has something to prove: The best startup team members always have a deep desire to prove something (either to themselves or to others), build something amazing, or leave a special mark on the world. They want to stand out from the crowd and escape business as usual. Over time, this defining characteristic is often the difference between a good outcome versus a great outcome when choosing a new team member.
  4. Likes working in small teams: Small teams allow for open and fast communication, lots of independence and responsibility (i.e. no handholding), and no office politics. The candidate should light up at the mention of that!
  5. Handles stress well: Startups can become very stressful at times. I’m not an advocate of keeping things insane all the time (or else people will go insane), but from time to time teams need to work weekends, weeknights, and deal with highly stressed out managers or (worse) customers. This can easily push somebody who has an anxious personality over the edge, so I think it’s important to bring people into a startup who are of a generally calm demeanor and don’t allow undue stress to shut down their nervous systems, so to speak.

Negative Markers (“No-go”)

  1. Focuses on shiny qualifications: There’s nothing worse than an interview where a candidate who wants to talk more about their degrees, course qualifications, and previous titles than what they actually do, or have accomplished with their work. This can also be a telling clue as to where their sense of professional pride stems from, and while not necessarily a bad thing for the person, this is definitely not a good thing for the startup.
  2. Debates contract minutiae: When a candidate wants to get into detail about contractual stipulations around things like office hours, leave, overtime (seriously?) and performance management policy (etc), I see red flags going up all over the place. Startup attorneys often write up employment contracts to favor that favor the company in the event of a labour dispute. If the candidate is truly ready to join the company, they will probably realize that (a) none of those things are likely to be managed and tracked to the letter of the contract anyway, (b) they will work as hard as they need to be a valuable member of the team and pursue the vision, and (c) a startup is not a big corporation. 
  3. No private projects to speak of: A candidate who has no side “pet” projects (past or present) to discuss is a concern, because that may show a certain lack of curiosity and personal passion in the candidate’s work. This mentality is needed for team members to think of innovative ideas to contribute to their area of the business, as opposed to just doing the work set out before them.
  4. Believes age equals entitlement: I am all about experience, capability, and delivery- and this is completely independent of a person’s age. Age can of course naturally lead to or correlate with these things (for most people maturity and experience takes time to develop), but when age alone is seen to be guarantee of seniority or entitlement, it’s cause for instant disqualification in my book.
  5. Existing staff feel uneasy: The social IQ of a team far exceeds that of the CEO or manager in charge. When a team member (or members) feels a little uneasy about bringing a new candidate on board, it’s best to take their concerns very seriously and reconsider the decision to hire. More often than not, the team will be right. This can very hard to do in situations where the hiring manager likes the candidate, and the person really wants to join the company. Hiring isn’t always easy.

I hope that this list of markers helps you to hire better. And remember, even with the best of checklists, there’s just no substitute for trusting your gut. 

Good luck and good team building!

When Effectiveness Trumps Efficiency

In my last blog post, I discussed a system for eliminating bottlenecks and making startups more efficient (i.e. doing more faster) across every area of the organization. I did not at all delve into the concept of “effectiveness”, as contrasted with that of “efficiency”.

To me, efficiency is all about how you go about getting things done, whereas effectiveness deals with a entirely different subject: what it is that you choose to do.

When I was in high school, I had an exceptional Physics tutor who would constantly tell his students to “work smart, not hard” and “be effective” with our learning methods. He showed us alternative methods of studying and problem solving that were dramatically faster than the popular methods being taught in most schools, as a result his students consistently outperformed others.

This simple truth applies to just about any endeavour- from learning a language, to losing weight, to running a startup. 

With resources usually being scarce in a fast growing startup company, one of the greatest risks that they face is doing the wrong things very well, without knowing that those activities are adding little value to the company.

Becoming effective requires a combination of trial and error, learning from others’ experiences, and most of all critical, often stomach wrenching thinking on the part of the individual or team involved.

Once a month, it would be useful for the founders and team to go through this Q&A exercise aimed at seeking greater effectiveness:

A. Elimination

  1. What activities can we stop doing immediately that will have little impact on our company goals?
  2. Do we need to change expectations of any customers, or fire any customers that are taking advantage of us?
  3. Is everybody working on something critical? If not, why not?
  4. Are we paying for any services that we don’t need?

B. Initiation

  1. Do we need to invest in any new software to help our business?
  2. Should we hire a new team member to fulfill a specific role?
  3. Are we missing a value-adding activity that our peers are doing? What?
  4. Does anybody need to go for training to learn a new skill that will be beneficial?

Every time, try to table a set of action items, starting with at least one, with a definitive deadline to implementation. Performing this exercise would be like taking a consultant’s view of your own organization. And who better to improve a company than those most familiar with it?

Often, improvement stems from reexamining our basic assumptions and turning them inside out to see what we end up with. It’s a well known fact that effective people (and teams) are highly capable of achieving greater results with fewer resources.

As I mentioned earlier on, this way of thinking applies as much to one’s personal life as it does to business. Periodically, we all need to stop and ask ourselves, “Why am I doing this?”.

Martial arts legend Bruce Lee epitomized a person seeking to be effective in everything he did. (His entire martial arts philosophy of Jeet Kun Do was premised on a fluid style that borrowed whatever worked from other disciplines and discarded the rest). Here are two of my favourite quote of his to drive the point home:

"It’s not the daily increase but daily decrease. Hack away at the unessential."


"Defeat is a state of mind. No one is ever defeated until defeat has been accepted as reality. To me, defeat in anything is merely temporary, and its punishment is but an urge for me to greater effort to achieve my goal. Defeat simply tells me that something is wrong in my doing; it is a path leading to success and truth."

Eliminating Bottlenecks to Increase Startup Efficiency

The greatest challenge that every startup must face is the constant pressure of managing limited resources. Regardless of whether that resource is people, money or time, there is usually a known, fixed limit as to what is going to be available to achieve the next set of goals. 

For early stage startups, inability to surmount this challenge can mean the end of the company; in later stage and even successful startups, sub-optimal resource management will waste time, frustrate staff and customers, and hurt profitability.

The founders of the well known startup accelerator TechStars released a book in 2010 titled “Do More Faster”, which essentially sums up the operating mandate of every small startup in existence. So, with this in mind, a question I have often asked myself is: “How?”

The answer is not to work harder- are we not all working incredibly hard already? If I am able to process 50 emails in 15 minutes, then spending 30 minutes processing email will only get me through 100. I might be doing “more”, but I am not actually doing more with less and fulfilling my goal of “do more faster”. This simple logic applies to just about any startup activity, be that working with customers, releasing products, managing admin, etc. 

While some of the answers to this fundamental question might feel intuitive to many entrepreneurs and managers, I have had the best results by applying a logical framework to help me try to solve the problem. In search of answers, I dusted off a book that I read in university and decided to try and apply the principles in my own company. (Side note: I’m constantly reminded by that old saying, the value of a book is not in what the author chose to put into the pages, it’s what you chose to take from the pages and put into your life). The name of the book is “The Goal”, written by Eliyahu M. Goldratt, who is a legend within engineering management and supply chain circles worldwide. It’s a brilliantly written business book structured as a fictional novel, and I highly recommend it to just about everybody.

The premise of the book is very simple, and its method for improving an organization can summarized by the following questions:

1. What is the goal?

2. What is the single greatest bottleneck right now in the process of achieving that goal?

There is a lot more here than meets the eye (which is why you should read the book), but I will try to deconstruct this a little further with a simple startup Q&A example. 

  • Q (mentor): What is the goal?
  • A (manager): I can’t get through all my customer inquiries. Every day, the questions from various customers are just piling up, and the time spent on email is preventing me from doing more work. I need to figure out how to answer these questions faster.
  • Q (mentor): Is the goal really to answer more email? What does that accomplish- what is the end goal?
  • A (manager): The goal is to answer customers’ questions as quickly as possible, and make them happy.
  • Q (mentor): Then that is your goal. What is the main thing holding this process up right now? What is the bottleneck?
  • A (manager): I get too much email to respond to. I suppose I am the bottleneck- I don’t have enough time…
  • Q (mentor): How can you open up this bottleneck? Can anything at all be done?
  • A (manager): I’m not sure. There are so many daily emails and only I know how to answer them. 
  • Q (mentor): But can anything be done to open up the bottleneck, even a little bit?
  • A (manager): I suppose that I could start recording common things that customers ask for, and then write publish a FAQ that new customers can check before emailing me. This would free up some time.
  • Q (mentor): Boom! So what are you waiting for?

This simple, clear style of investigative dialogue can be applied to any challenge where one needs to deal with limited resources. Note that it is essential to address core issue being faced, and not to try to get tied up on the “hamster wheel” of addressing superficial symptoms or byproducts it causes (aka “damage control”). Another crucial aspect of the method is to remember to ask the “right now” part of the question, as bottlenecks in a system are constantly changing, so clearing bottlenecks and “doing more faster” is a really a process of ongoing improvement. With yesterday’s bottleneck eliminated, tomorrow will just present a new one (but hopefully by then things are moving a more smoothly). And, remember, only try to address one bottleneck at a time.

Goldratt coined his method as the “Theory of Constraints" (TOC), defining a constraint as "Anything that limits a system from achieving more of its goal".

This seemingly simple theory has had incredibly successful application to manufacturing and process oriented environments for almost 30 years. It can be pretty powerful when applied to startups too.

The application of TOC in our startup has been simple, structured, and effective.

Here is our method.

1. Define the System

A startup is just a system, comprised of different parts. (In business school they prefer to talk about the company value chain, but I digress). Define the different functional parts that matter most to the organization, i.e. where most of the resources (people, time) are being consumed. 

Some example areas are: Sales & Marketing (getting new customers), Account Management (delighting existing customers), Operations (managing daily work and necessary customer activities), Software Development (building and deploying product), and Financial Management (managing accounts, debtors and creditors).

Every startup is different, so list the areas that matter to your organization. I suggest putting this into a spreadsheet as different column headings. Underneath that, define the singular goal of every one of those functions.

2. Identify the Bottlenecks

For each company function, take the time to analyze and identify where the greatest bottleneck exists right now. If the constraint ends up being a person’s time, try to dig deeper to figure out what tasks are chewing up a disproportionate amount their time.

Some examples of bottlenecks from our past experience are:

  • Sales & Marketing: Repeating the same sales messages to prospects in writing or verbally due to lack of effective collateral.
  • Account Management: Repetitive, high volume email to a variety of business and technical questions.
  • Operations: Poor visibility on what everybody is doing forces management to ask too many questions and interrupt staff often, who become unclear on daily priorities.
  • Software Development: Implementing a new customer installation involves many time consuming steps on our side.
  • Financial Management: One person in charge of all payments and collections but does not have time to stay on top of it.

I suggest adding a dedicated Bottleneck row to the spreadsheet, so that a note can be made under each function column.

3. Identify the Solutions

Once the bottlenecks for each major area are identified, try to figure out practical steps that can be taken to eliminate, or free up the bottleneck. Following on from the example above, here are some of the past solutions listed to those problems:

  • Sales & Marketing: Develop marketing collateral material to leave with prospects after a sales meeting.
  • Account Management: Capture common questions and publish a detailed, easy to use FAQ for customers. Better yet, create a customer service portal with how-to guides, videos, and all manner of help resources.
  • Operations: Implement a system or tool that makes everybody’s work tasks and priorities transparent to the entire team.
  • Software Development: Focus the next wave of software development on automating deployment of the existing platform (as opposed to adding new features).
  • Financial Management: Have a different staff member help the individual keep track of creditors and debtors; and bug them when something needs to be done.

Solutions can be added to the spreadsheet as an additional row below the Bottlenecks row.

4. Review Progress

As with all initiatives, for this to work there needs to be a consistent process of review in order to maintain accountability and momentum.

I recommend that the senior management team of a company do this jointly every two weeks. During review sessions, managers should commit to when they expect the solution to a particular bottleneck to be completed, and this can be noted for subsequent review.

Over time, old bottlenecks will be deleted off the spreadsheet and replaced with new ones that arise. These meetings tend to be very rewarding, because after a while the progress achieved by following this process becomes obvious to all involved.

When dealing with the day to day volume of work to manage it’s all too easy to ignore this method for weeks and months, trying to make that metaphorical hamster wheel spin faster and faster. It took me a long time to fully understand what a waste of time that can be. 

To truly address the goal of achieving more with less, or doing more faster, and creating sustainable, long term performance gains I believe that constantly improving processes and eliminating bottlenecks holds the real key to startup efficiency. And that makes sense to the bottom line.

How to Divide Equity Among Partners in a Startup

Every entrepreneur needs to address this question at some point. Figuring out how to best divide equity in a new venture is one of the most critical decisions to take early on, as it has the longest lasting implications.

Fundamentally, equity means ownership. And in any venture, ownership matters. I believe that in my career thus far I’ve managed to get it wrong and get it right, and sometimes end up somewhere in between. This post stems purely from my personal lessons learned, along with some external observations to round out my recommendations.

When dividing equity among co-founders, two key questions must be addressed:

  1. How much equity does each person get?
  2. What happens if somebody doesn’t pull their weight, or abandons the project?

I will delve into each question separately.

How much equity does each person get?

I believe that the amount of equity that each partner receives should directly reflect the size of their contribution to the venture. Contributions (or value add) can be made in three main ways, namely:

  1. Operational skill
  2. Time and energy
  3. Money

Operational skill covers the role played by the particular co-founders. For example, in a tech startup, key roles could be sales and marketing, software development, and product design. Or in a restaurant, there would be a chef and a manager. In many startups, people have to take on multiple roles at the same time.

So to determine the value of the operational skills being added, the partners should assess the intended roles of each party as well as their skill level, and predict the impact that this would have on the venture. For example, a salesperson may be crucial to landing key deals, or a developer may be crucial in building an initial prototype to sell. The size and nature of the value add per person will vary from project to project. This would need to be thrashed out internally until a common view is developed.

A premium (i.e. increased equity stake) should definitely be added for the person fulfilling the role of Project Leader or CEO, and every venture needs a leading CEO character. A startup where this role is not clearly defined and supported by all parties is risking it’s future for a number of reasons to lengthy to get into in this post.

Time and energy refers to the physical time commitment of each co-founder to the project. Often, this is not as easy as “we will all do this full-time”, nice as that may sound. It’s possible that one partner would work on the project after work, or only on weekends, while the other(s) may be doing it full-time. 

The time investment to be made by each partner (as well as when that could change) should be defined up-front, and factored into the equity split. For example, a highly experienced salesperson founder would naturally receive a large equity stake in a business, however, if they are involved on a part-time basis while there is a software developer involved on a full-time basis, the developer’s stake should probably be greater. And vice versa.

Money can be contributed to the venture in two very simple ways. The first is that a co-founder is making a cash investment in the project. When a commitment to invest money is being made, I believe that the co-founder investing the money should propose the terms and valuation that he believes is fair, and the other partners can hammer out the negotiation. To keep everybody honest and the deal feeling fair, all parties should be allowed to invest at that decided valuation at that point in time.

The second way that money can be contributed to a venture is when a co-founder is saving the project cash by working for no salary. This situation should only affect the partner’s stake when they are doing this while working substantial hours (e.g. 18+ hours per week), not for part-time involvement as that contribution can be assessed based on skilled value add only. 

The final area that can affect how co-founders divide equity is the concept of who was there first. This topic always comes up, and it can take on two different forms, specifically:

  1. It was my idea.
  2. I have made progress on my own but need to bring in partners.

People who try to push the “it was my idea” line of reasoning as a means to get a larger stake in a venture need to be avoided. There is very, very little value in an idea on its own. The blood, sweat, tears and ultimate rewards come from execution. If the originator of the idea is bringing special domain knowledge to the project, then their contribution can be assessed under the basis of operational skill, as discussed earlier. Nobody should ever receive a founding equity premium (i.e. a larger stake) on the basis of coming up with an idea first.

On the other hand, if somebody had an idea and tried to start executing on it on their own before deciding to approach partners, that is a different story. In these cases, the co-founders should asses how much progress that partner achieved and where that puts the project in terms of traction and momentum. If the project has indeed progressed beyond ground zero and is out of the starting blocks, then it would be fair that the original founding partner receive some sort of premium for that effort.

Now that we have a decision framework for determining value add by each co-founder and dividing equity in the venture, we need to address the elephant in the room that is often ignored by co-founders starting out: what if a partner is no good, or if a partner quits?

Both of these fears regularly become a reality for new ventures! And it far more common among people that have never worked closely together for a meaningful period of time before (which happens more often than not).

This is where the concept of the “golden handcuff” becomes very useful. Co-founders should be “handcuffed” to their ventures, i.e. there should be a strong incentive to keep them fully involved. A good mechanism to manage this process is founder vesting. Basically, vesting means that partners need to earn their equity over a period of time, and stand to lose their equity if they leave the venture. Generally speaking, all vesting structures in new ventures should allow for accelerated vesting if the venture is sold before the partners’ vesting periods are up (i.e. they get to reap the value of selling their entire stake at time of sale).

Vesting structures can be pretty simple or extremely complicated. 

A basic structure could be: 50% vested up-front and 50% vested in total at the end of 4 years, so if the partner left before 4 years they would lose half their stake. 

I believe in taking a more nuanced approach to better manage the risks associated in dealing with co-founders. Here is my proposed vesting structure for a new project, fully explained:

- Vesting period: 36 months (3 years is adequate time for partners to prove their commitment).

- Up-front vesting: 10-25% of total stake (this gives each partner a strong sense of ownership in the beginning, which is important in motivating them to make the venture succeed, and it also recognizes their willingness to seriously commit to a new project).

- Vesting method for remaining equity: 1/36th of partner equity vested every month (this is a fair way to incentivize continued commitment with continued reward, as opposed to an all or nothing approach).

- Probation period before up-front vesting is recognized: 3 months. (The 3 month period provides the co-founders enough time to work together to get a sense of team dynamics, commitment and value being added).

The last point around the “probation period” requires more explanation, as it links back to the question I posed earlier: “What if a partner is no good?”. A partner can be no good for a venture for a number of reasons, such as:

  • They are difficult to work with.
  • They are not putting in the hours/pulling their weight.
  • They are not as skilled as the co-founders initially believed and cannot deliver the productivity and results expected when the project was started.

As in hiring new employees, the operational value and viability of a partner in a startup can be assessed fairly quickly. 

Then why do so many co-founders charge into equity splits and end up with partners holding on to stakes that they (the other partners) are not happy with, you ask? Well, I believe it’s because co-founders are often blinded by the romance and enthusiasm of a new project and see the world through rose tinted lenses, and as such would rather avoid these painful “what if” discussions with their partners.

The inclusion of a probation period takes this significant risk into account. At the end of the 3 month probation period (or sooner), a decision can be made as to whether every co-founder will proceed in their envisioned roles, or if somebody needs to be cut from the team, and not receive any equity at all (except if they have invested cash already, in which case the cash should either be returned or the co-founder should receive the pro-rata amount of equity deserved for the investment to date). Unfortunately, this is a lousy thing for the person that is dropped (if such an event happens), but all founders must take this risk, and it ensures fairness and alignment among the team, placing the best interests of the venture at heart. 

If the co-founders feel that a partner is not living up to expectations, the manner in which I propose that the decision be made is by a simple majority vote. Specifically, if more than say, 50% (exact amount can change depending on number of partners) of the venture’s owners (by equity value, not number) vote a partner out before the end of the probation period, then that person must leave.

I further believe that this system should remain in place even after the probation period has ended, i.e. the majority shareholders should be able to vote a co-founder out of the business, however, that co-founder would be entitled to keep (or sell) their equity vested up to that point. This additional mechanism ensures that co-founders keep pulling their weight and adding the expected amount of value to the venture on an ongoing basis. Remember, without such a clause in place the alternative for the remaining co-founders when faced with a non-performing partner would be to fire them but have them entitled to hold on to all or most of their equity in the venture.

If a partner is forced to exit the venture, the leftover equity, now unassigned, can be dealt with in a variety of ways, such as being earmarked for a new partner or an employee share pool, however the easiest method is for the leftover equity to be split pro-rata among the remaining active partners.

In teams of two where equity is divided 50/50 (a split I don’t often recommend) then voting somebody off the team so to speak does not make any sense. In this scenario, the unhappy party should have enough guts and sense to realize quickly that the partnership isn’t going to work out, and abandon the project completely or restart it on their own.

I realize that this is a sobering view on how to divide equity among co-founders in new ventures, but it is the product of years of experience and many lessons learned. When applied properly, this system would be very fair for all co-founders, leading to better alignment and increasing a venture’s chances of success.

I hope that this post was helpful. As always, I’m interested to hear your thoughts on this topic.