Why programmers can make great CEOs

The popular (mis) perception of programmers is that they spend all of their time in darkened rooms, working with millions of lines of code, and perhaps aren’t always blessed with great people skills. Yes, I come from a programming background, so I may be a little biased, but that’s plainly nonsense.

Not only are programmers capable of amazing things, creating the building blocks of modern life and business, but they are also comprised of a varied and broad demographic. Many programmers are more than capable of going on to run a business too. Yes, making the journey from programmer to CEO can be scary and in some cases it’s a major transition. But anyone doing so would be in the best company. Bill Gates, Mark Zukerberg, Marissa Mayer and James Dyson have all made the leap having started out as programmers, and you’d have to admit that they have done alright!

From business development to analysing spreadsheets, naming things and solving problems, programmers have many transferable skills that can make them the ideal CEO for a company. These are the most important.

A vision for technology
Founders of a business can be technical – that’s acceptable in business. CEOs may also bring on a co-founder with a technical background; again, there’s not generally a problem with that. But it’s when the CEO themselves has a technical background that people start to question them, and for me, it’s hard to see why that should be the case.

Programmers have a vision of the technology they work with and have helped create, and they have a strong idea of how to drive that forward. Without that vision and drive, or in the hands of someone else, not only can the technology deviate from the path it was on, the business can easily begin to stagnate. Who other than the CEO should be the person driving a business forward in this way?

Storytelling
One of the most important attributes required to become a CEO that programmers may find hardest to adjust to is the ability to tell a good story. Storytelling is of the highest importance in business. Right from the off, surrounding yourself with talented people is vital, and to get the best people you need to convince them, which means spinning a yarn or telling a story.

This will continue as your business develops and grows. Next up might be a bank manager and then if your company is ready to launch, you’ll be meeting press so your storytelling needs to crank up a notch further. If you then reach the stage where you require investment, angel investors especially will fundamentally invest in the person rather than the business, so that person needs to show them passion, understanding and commitment, all of which comes through good storytelling.

This goes on and on. When in the process of securing DataSift’s Series C funding, I’d been told that the key to success is all about the numbers. This is partially true but I’d suggest that bad storytelling can reduce funding by 20% and a good story may increase it by 20%. If you are dealing with a funding round of £20 million, that’s a major difference. As with anything, it’s all about practice. Do it as many times as you need, and learn to convince people with your story-telling.

Programmers can do business
One of the major misconceptions is that programmers don’t ‘do’ business, a myth perpetuated by business programmes on TV like Dragon’s Den and The Apprentice. Business development for example, is an area where programmers initially probably don’t have much exposure to, but it is also an area where they can add real value.

Bringing a high level of technical expertise into such a meeting adds real weight to a pitch. It can play a significant part in convincing people that it’s not just a sales team there to seal the deal, and that you really do know what you’re talking about.

Another aspect of business for programmers to get to grips with, is the use of Excel. By far and away the most common place to put data and probably the most-used tool in many businesses, Excel is not a popular product with programmers as a rule. However, learning to use Excel – it’s very easy – will be invaluable to the programmer turned CEO. People want revenue projections on a business at almost every stage and want to see data represented in a form that is easy to understand. Excel is the way to do this.

The name is…problem solver extraordinaire
Programmers can be highly creative when it comes to naming products and services. They have to name different bits of code all of the time, so consistently and clearly naming elements of a business (internally and externally) should be straightforward. Names that show a clear picture of what a business actually does are crucial and who better to do this than the people that helped build the technology behind it.

Finally, programming is essentially about problem solving. A programmer wants to be challenged with something that has never been done before, is complex and the reward is bringing it to life. To do this requires a keen mind, used to thinking laterally to solve problems. This is not really any different to a business challenge. A CEO needs to think, muse, discuss and identify a way around a problem, and a background in programming gets you used to thinking in this way.

My journey from programmer, to lead programmer, to manager and onwards and upwards to CEO, has at times felt daunting and scary. But I made it, and there is absolutely no reason why other programmers can’t do the same. In fact, I believe they are uniquely suited to doing so.

Why programmers can make great CEOs

What motivates programmers?

Note – I originally wrote this in 2009 – the context (e.g. cost of monitors has changed) but the principle is still the same. 

I will start with a question, if you have a spare £400 in your development budget do you A) Reward your star programmer with a £400 bonus or B) Buy him a 24 Inch 1920×1200 LCD screen?

If you answered ‘A’ then you need to read on. If you answered ‘B’ then you understand what motivates programmers but I suggest you still read on and comment later if you have any ideas beyond what I cover.

One of the things that they never teach non-programmer managers is how to motivate programmers. You may think the programmers are motivated by the same things as the rest of your staff, you are WRONG. Programmers tend to be counted within the higher IQ brackets and are therefore harder typically to second guess.

The average programmer may be projecting an image of superiority but non-programmers miss-read this and think it is aimed at them. It is not. You have to understand that programmers rate themselves against other programmers not against anyone else.

This is important when making any decision about how to reward them. If you purchase some new equipment for your sales staff the likely reaction will be … nothing. If you purchase new equipment for your programming staff they will immediately start analyzing who has got what and by reference who is being rewarded more than others based upon the quality of the equipment. If you think this is not relevant think again.

What this comes down to is that the work environment is generally more important to a programmer than any kind of financial reward (within limits). But managing who gets what within your company is not easy.

You can just take the view (and if you have a big enough budget) that everyone is standardized and that you all get the same equipment. This in practice within a development environment never works because each programmer may require a very specialized setup which breaks the standardization rule and your back to ‘who gets what’.

Hardware Cascade

Programmers outwardly will try and give the impression that they are a loose nit bunch who care nothing for standard business practices and certainly not give any importance to the usual office politics of who is above who. This all goes out the window with new equipment because the hardware is seen as a status symbol within the ‘non-existent’ programmer hierarchy.

So when upgrading machines it is vitally important that you understand the structure of this invisible hierarchy. I typically upgrade at the top of the tree and push machines downwards, this can mean lots of re-installing but most programmers will be very happy to put in extra hours to perform the re-install if the reward is a new machine (or at least a faster machine)

The appeal of solving a problem

Programmers program because they love to solve problems. Remember this rule:

“If you give a programmer a job that does not involve solving something they will become unhappy.”

Solving can mean many things and it is easier (and more important) to understand what classes as a ‘non-solving’ task. Typically asking a programmer to go fix something would be classed as ‘non-solving’ as the solution has already been found and you are asking them to re-solve it by having to look at the code again.

What is important is that you find ways of making ‘non-solving’ tasks into ‘solving’ tasks. A typical example would be the difference between asking one of your programmers to put together a report (e.g. some usage statistics) by hand or assigning him more time so he can ‘solve’ something and produce an automated system that will email you the report every day/week/month. Other typical non-solving situations

  • Writing documentation
  • Creating schedules
  • Writing reports
  • 1st Line Support

All programmers have to perform non-happy-non-solving tasks and some cope better with dealing with a higher ‘non-solving’ ratio of tasks than others. Understanding your programmers and who can cope with what level of ‘non-solving’ is important to keeping an overall smooth operation.

Meetings

Programmers see meetings as wastes of time. Most communication between programmers is done via email or by a quick wander to another desk to clarify something that is beyond the scope of an email. Therefore any time within a meeting room is ‘unhappy time’ and unhappiness increases exponentially with the length of the meeting. So at all costs if you do need to drag your development team into a meeting either include some form of Lego to play with (I am serious) or keep them very short.

What motivates programmers?