The best person to manage a Software Consulting company is an accountant

Most people the software industry will work at several companies throughout their careers. In this chapter I’ll focus on software consulting companies specifically, but before we get to that let’s recap on the types of companies that could be involved in software development.

Many software professionals work in companies that are not strictly software companies, but rather companies that make their money through some other ways while software only serves a means to an end. Many of these companies can be found in the financial services sector such as banks, investment and insurance companies. Other industries that hire software professionals include warehousing, logistics, manufacturing, retail, tourism, aviation and many others. As a software professional working for one of these companies you’re essentially part a cost centre i.e. your work doesn’t directly generate money for the company. As a result, the software professionals in these companies don’t really worry too much about bringing in money.

On the other hand you will have companies that eat, sleep and breathe software for a living because that is their only way of generating an income. As mentioned in previous chapters these types of software companies can be divided into product development and software consulting. Product development focuses on developing products that can be resold as out-of-the-box products to many customers across the globe, while consulting companies offer custom development for their clients. Product companies invest a lot of money, time and effort into R&D (Research & Development) in the hope that they will sell those products at a fixed price, while consulting companies sell their time and expertise for an hourly rate i.e. they’re mostly selling services as opposed to products.

  • How a software consulting company functions: having distinguished between the different types of companies that employ software professionals let us look specifically at software consulting companies. We’ll first start with the problems in these types of companies. What I have seen throughout my own experience and by listening to other people’s experiences is that most software consulting companies do not last very long. Most of them do not even make it to the five year mark. The reason for it is quite simple in that they do not understand the paradigm they operate in. Software consulting companies are like hunters and gatherers i.e. they hunt and gather for a new project, they eat from the project, they hunt and gather again and this cycle continues to eternityThe moment they stop hunting and gathering is the moment the money dries up because they don’t have any sort of automation in place to ensure a passive income. In keeping with this analogy it essentially means that they haven’t matured to the Industrial Age i.e. having machines that make money while the people sleep. Unfortunately what many of these consulting companies don’t realise is that they are vulnerable to external factors that are outside of their control, just like hunters and gatherers that are left exposed to the effects of droughts and seasonal changes. During winter or a draught, there are no more fruits and vegetables to gather and the animals to be hunted are inaccessible or difficult to find. 
  • What keeps a software consulting company afloat: the only way for the hunters and gatherers to survive during winters and droughts is for them apply prudent strategies, which include:
    • Savings: an inexperienced manager of a software consulting company will be tempted to go on a spending spree after acquiring a big project or an investment from an investor. A prudent manager on the other hand will know that the good times are temporary and the work will dry up at some point. He will therefore save as much money as possible during the rainy reason to ensure there’s enough to pay salaries during the droughts.
    • Lean teams: most software consulting companies that I have seen tend to hire people based on project workloads. The bigger the project the more developers they hire. This strategy may serve well during the project but after a few months or a year the project gets completed and the work runs out, at which point they start looking for another big project. Those big projects are typically difficult to find and therefore failing to find the next project the company starts retrenching the staff due to a lack of work that can be given to them. A prudent manager on the other hand will rather keep the team as small as possible to avoid such retrenchments.
    • Hiring jack of all trades: based on common business practices an inexperienced manager of a consulting company will typically try to specialise their work force. If the big project that has been acquired happens to be a web development project the manager will go on to hire developers that specialise in only web development. In most consulting businesses this can often be a mistake because the next project could be a mobile app requiring a different set of skills. With the current staff not being to handle the new project, the manager will once again be forced into retrenching the developers if he cannot find more web development work for them to do. Some might argue that a consulting company should learn to pick their battles thereby specialising in only one type of solution e.g. only do web development or only mobile development. However due to the fact that most consulting companies live from hand to mouth they won’t always have the luxury of being picky with the projects they take on i.e. they normally take what they can get in order to pay the bills. It’s for this reason that in an effort to mitigate risks a prudent manager will tend to hire developers that are jack of all trades. This enables them to reallocate developers to projects as business needs change. In other words, prudent software consulting companies tend to hire developers that are flexible in order to compensate for an inflexible budget.
  • Typical types of people you’ll find running software consulting companies: as you can see it requires a special kind of skillset and aptitude to run a successful software consulting company. Here are the most typical kinds of people I’ve seen running these companies.
    • Technical people: most software consulting companies normally start off with a single talented developer who decides to go at it on his own by becoming an independent contractor. He then lands a huge project and proceeds to hire many developers to help with the work load. As mentioned above, this often ends in disaster for the company since the work will eventually dry up. Although software companies perform technical work, the problem with technical people is that they often only focus on the technical aspects. They typically have great aspirations to build amazing software products, learn all these new technologies and do all the cool things. However, what they fail to understand is that keeping a consulting company afloat is not about the amazing software they’re developing but rather the hours that they’re billing to the customers i.e. the money they’re brining in. Going back to the hunter and gatherer analogy, the technical people are like the chefs in the kitchen preparing the amazing food, while the business owners are the ones hunting and gathering for food to be brought into the kitchen. It doesn’t matter how good of a chef you are if you cannot hunt and gather for more food to be brought in. It’s for this reason that purely technical people will not be able to run successful software consulting companies. The only way for technical people to start their own successful company is by coming up with a recipe or dish that everybody wants and requires very little work with each new sale i.e. to develop a product that scales.
    • Sales people: although sales people are very much required in terms of hunting and gathering, they often don’t make for good managers of software consulting companies. You’ll often find sales people that have found one or more great opportunities for developing custom software i.e. they know someone who knows someone that is looking for a software solution. They then proceed to find an investor, take a loan from the bank, or even cash out their life savings to start a software consulting business by hiring a few developers. The problem with sales people is that they are typically big on vision but short on details i.e. they know what they want but they typically have no idea on what it takes to get it. Because of this they tend to make a million and one mistakes while running a software company. These could include the mismanagement of funds by going on a spending spree, hiring and promoting the wrong developers, overpromising and underdelivering to customers, failing to understand the technical details of the software solutions as well as failing to understand the customers’ business requirements. Most importantly they fail to understand the hunter and gatherer paradigm and thereafter fail at managing cash flow.
    • Accountants: it may seem counter intuitive, but in my experience accountants are the best kinds of people to manage and run a software consulting company. There are a couple of reasons for this:
      • Managing Cash Flow: based on the hunter and gatherer analogy it goes without saying that managing cash flow is crucial to surviving in a business that goes through regular droughts and therefore tends to live from hand to mouth. One of the main responsibilities of an accountant is to manage cash flow, and for many accountants this is something that has been ingrained in their DNA.
      • Practical: accountants tend to be highly practical people that don’t concern themselves too much with airy-fairy ideas, idealistic dreams and philosophical debates. They tend to focus on the task at hand and dealing with reality as it presents itself. This simplistic approach to life makes accountants see things in black and white or in their case as debits and credits (money in vs money out) i.e. we’re either making money or we’re losing money. Although it can be argued as to whether that way of thinking is right or wrong in terms of the big picture, for a hunter gatherer kind of business that survives from hand to mouth, this kind of approach is perfect. Some may argue that accountants are short sighted in that they only care about what happens in this month/quarter without worrying too much about long term goals. However, the truth is that in a software consulting business long term goals and vision are in fact mostly irrelevant  i.e. it’s a hunter and gatherer sort of business that has relatively short cycles of hunting and gathering (i.e. projects) which repeat themselves in perpetuity. 

To be clear, I’m not saying anything about whether the business model of a software consulting business is right or wrong. That is the topic of another discussion. All I’m saying is that given the business model of a typical consulting business, these are some of the things required to keep such a company afloat.

What makes a great sales executive in the tech industry?

We have all been approached by sales people at some point or another. Chances are that you’ve probably also worked with them in a professional capacity. Unfortunately, I don’t think you’ll find a single adult on the planet which hasn’t had a bad experience with a sales person. It could have been a hawker trying to sell you a pirated DVD, telemarketers constantly harassing you, a financial consultant debiting your bank account on an insurance product you haven’t even agreed on, or perhaps a sales executive duping you into buying a product that you don’t actually need. Over the years the sales profession has adopted a bad reputation. As such, I have often wondered what differentiates a good sales person versus a bad one.

In order to try make sense of it, we’ll first go through the typical stereotype of a sales person. We’ll then look at why and how they sales people enter the profession. We’ll then break down the most common types of sales people and also look at the qualities of an ideal sales executive. Lastly I’ll give me take on why I think there’s a gap between the typical sales person and the ideal one.

  • Stereotypical sales person: let’s first look at the qualities and flaws that come to mind when most of us think of a stereotypical sales person.
    • Qualities: chances are that many of your friends have been sales people throughout your life. The simplest reason is that they do in fact have a number of alluring qualities. They can be in incredibly charming, funny and the life of the party. They also tend to be eternal optimists which can be uplifting and inspiring when you’re having a bad day. I guess being an optimist is a prerequisite to surviving in a career where you’re getting rejected several times a day. Due to them regularly dealing with people and managing conflicts, some of them tend to be quite philosophical, which can certainly make them interesting individuals. 
    • Flaws: for many people, encounters with sales people can leave a lot to be desired. They can be pushy, refusing to take no for an answer. They can be disrespectful of people’s boundaries and sometimes even downright rude. They can be dishonest about the value of their products and their prices. Worst of all they can be extremely manipulative, playing with our emotions to trick us into signing on the dotted line. They often use the book “How to Win Friends and Influence People” as their bible, which in my opinion would be more accurately titled “How to become a sociopath by being fake and manipulative”. Their massive egos, gung-ho attitude and reckless nature can also serve as a horrible cocktail for creating toxic work environments. As you get older and more mature you start to feel that in order to maintain your sanity you almost have to become a parent to a teenager in every relationship or interaction you have with a sales person i.e. be firm with your personal boundaries, grow eyes at the back of your head and instil structure and discipline. If you’ve had enough of these bad experiences, it’s enough to make you think that they’re the scum of the earth. However, I don’t think it’s as clear cut as that.
  • People that end up in sales jobs: clearly the stereotypical sales person described above is not an ideal one. In order to understand the gap between the stereotypical sales person and an ideal one we need to first understand how they end up in these professions in the first place.
    • Entrepreneurs: these are your typical hustler types who have always enjoyed coming up with creative ideas and making deals. I can honestly say that these types of people are probably the best you can hope for when hiring sales people. How these people initially end up in sales positions is by virtue of their very nature and aptitude. The problem with these types of people is most of them go on to start their own businesses since they are normally are very independent, have a high tolerance for risk and have greater aspirations than working for a salary and/or commission their entire life.
    • Career changers: these types of people end up doing sales by mistake. They typically go and get some tertiary education and begin working in a specific profession. After some time they realise that it’s not for them. This could be for a number of reasons. Maybe they realise that they don’t have the aptitude for it or perhaps they’re not getting paid enough. It could even be that the job or industry they’ve landed in isn’t what they expected. Going back and studying for another few years to change professions isn’t always a viable option. They therefore start looking for alternatives and quickly come to realise that a sales position is one of the few unqualified jobs that actually pays well.
    • Those with useless educations: these types of people are similar to the career changers in that they also completed some tertiary education. The only difference being that they never actually worked in their field of study. The reason being that they probably completed some useless degree or diploma in a subject that nobody is willing to pay for e.g. art history, philosophy, fashion design etc. Not being able to put their studies to good use, they end up coming to the same conclusion as the career changers i.e. the easiest and most lucrative way of make a living is to start selling something.
    • Shortcut people: these are the lazy kind that go throughout life looking for shortcuts and get-rich-quick schemes. These people have no patience, don’t bother learning any new skills or working hard at anything. They’re in the habit of thinking that their next big score is just around the corner. They never realise that anything worth building will take time and effort. These types of people often only care about the money and are hardly interested in the process of how the money is made. Since becoming a sales person presents the smallest barriers to entry, these kinds of people will naturally gravitate towards the sales profession.
  • Types of sales people: there are all kinds of sales people selling all kinds of different products and services. Depending on what they’re selling they will require varying levels of skills. I therefore don’t think it’s fair to put all sales people in the same basket. Here are some common types:
    • Hawkers: there are the entry level guys that sell oranges and sunglasses at every corner. Being friendly, resilient and having an innate ability to disrespect people’s boundaries is pretty much all the skills this person needs.
    • Sales clerks: these are the people helping in you in the stores, providing information about the products and basically just making your shopping experience a pleasurable one. To be quite honest, I wouldn’t even classify them as real sales people since the majority don’t take part in convincing customers do buy from their store as opposed to other stores.
    • Telemarketers: these are the cold calling types that peddle all kinds of insurance products, cell phone contracts and bank loans. They are the worst kinds of sales people with the worst reputations. Due to the very definition of cold calling, these kind of sales people never have customers calling them, but instead they are the ones approaching unsuspecting strangers. For these sales people it’s all a question of probability i.e. the more people they call the higher the chances of convincing someone to buy something. There are several dynamics at play in this telemarketing game. Firstly, 99% percent of the prospects being called are not interested in the products that the sales people are peddling. This could either be because they don’t see any value in the product or perhaps they already have a similar product. The sales people are therefore searching for that 1% of prospects that would be interested. In order to do achieve this, a single telemarketer can make anywhere between ten to a hundred sales calls a day, repeatedly getting rejected. As you may have already experienced yourself, people can receive several of these sales calls a week. After a prolonged period of receiving these calls, most of us reach the end of our straw and unconsciously become rude to these telemarketers. In return, the telemarketers need to grow a thick skin to survive in this gruelling industry and naturally also become rude and obnoxious over time. Even more concerning, is that these telemarketers realise that nobody wants their products and therefore realise that the only method of closing deals is by becoming aggressive and even downright manipulative. They then come up with all sorts of dishonest schemes that either hide information about their products or exaggerate on what the products can actually do. Often times their artificial personas tend to slip into their personal lives, applying the same kind of tactics with their loved ones and colleagues. Is it therefore any wonder that sales people are stereotyped with all the flaws mentioned above?
    • Sales executive: these are supposed to be the white collar professionals working in the corporate world. In most cases these sales executives are hired to sell much needed products and services. The products that they sell are normally a lot more complex than a cell phone contract. In the technology sector these can include both hardware and software. Sometime they will be out-of-the-box products while other times they can include custom solutions to be designed and developed. As you can image these sales executives are expected to understand and explain how these complex products work. Selling services for custom solutions requires an even higher level of skills since the sales executive is expected to understand the customers’ business requirements as well as make recommendations. Most importantly the relationships with their customers are not finite. Meaning that unlike with telemarketers the relationship with the customer does not end once the deal is closed. Customers in the corporate world look for more than just specific products; they look for long term partnerships with their suppliers. This means that aggressive behaviour and manipulative tactics on the part of a sales executive might help in closing the first deal but will certainly have an adverse effect in maintaining a long term relationship.
    • Account Managers:
      • Overview of the value chain: in order to understand the job of an Account Manager we have to first clarify how they fit into the value chain.  Large corporations that are suppliers and manufacturers often distribute their products via a channel of partners. Channel distribution is typically used to minimise the costs for manufacturers and helps them expand their territories. For example, depending on complexity of their products as well as the demand and size of the market, a hardware manufacturer known as an OEM (Original Equipment Manufacturer) may not find it viable to conduct direct sales to customers across the world. It would require too many stores, sales executives, engineers, accountants and other admin people to run their business. Instead they tend to offer training and support to certified partners also known as VARs (Value Added Resellers). In the software industry those VARs could also be labelled as ISVs (Independent Software Vendors). These VARs then go out selling and implementing the manufacturer’s products. The VARs are normally the ones that hire the sales executives, find the business opportunities, close the deals and implement solutions using the products provided by the manufacturer. Multinational manufacturers then go on to establish subsidiaries in the countries they plan on selling in. The subsidiary is typically owned by the manufacturer. A subsidiary will be made up of a handful of people who’s job it is to support the VARs in that country. The staff are made up of mostly sales people (Account Managers), a few technical pre-sales engineers and perhaps a few finance and admin people. They may sometimes also require a few technicians if they’re not outsourcing the hardware repairs. The manufacturers may in some instances include one or more third-party Distributors in the value chain. The Distributor’s role is to offer warehousing of the stock being brought into the country as well act as a stock buffer to handle the market demand i.e. customers aren’t normally happy with typical 6-8 week ETAs (Expected Time of Arrival) and therefore having a Distributor keeping stock in the country reduces that ETA. VARs normally purchase the products from the distributors but negotiate the prices with the Account Manager working for the manufacturer. Distributors normally agree with the manufacturer on a fixed markup on the products while VARs can set their markup to whatever they feel is plausible in order to close their deal with the end customer.
      • Job of an Account Manager: the sales people known as Account Managers are essentially the heart and soul of the manufacturer’s subsidiaries. They are responsible for managing the relationships with all the VARs and supporting them with whatever they need in order to sell. In most cases, the Account Managers do not ever perform direct sales to the customers, nor do they go out looking for new business. Instead the Sales Executives working for the VARs do most of that work and the Account Managers just offer advice, pricing and sometimes apply for Price Exceptions (a pretentious term for discounts) on behalf of the VARs. The manufacturers can often run marketing campaigns commissioned by either the head office or subsidiary in which case the Account Managers could end up with leads on their desk i.e. people that are interested in their products. Upon receiving these leads it will be up to the Account Manager to decide which VAR they give the lead to. In theory this decision should be based on merit i.e. the most competent VARs should should be given the most challenging leads to increase the chances of success. However, in the real world there are a lot of politics that go into that decision. It could be based on the personal relationship between the Account Manager and the VAR and host of other dubious practices such as being offered bribes by the VAR, nepotism and efforts to create a monopoly of VARs in order to fix prices and avoiding price wars i.e. the Account Managers typically do not want too many VARs as this can lead to them undercutting each other thereby bringing down the prices in the overall market. The moral of the story is that most Account Managers do very little selling and instead spend most of their time playing politics. 
  • Ideal type of sales professional: having mentioned all the different types of sales people, it’s easy to conclude that there’s no point in hiring a hawker or a telemarketer to work in a professional environment since they typically don’t have the skills and aptitude to conduct themselves in a professional manner. Unless your company is a large multinational there’s probably not going to be a need for an Account Manager either. Therefore a typical company with useful products and services should in fact be looking for Sales Executives and ignore all the other types of sales people. So what are the qualities and skills of an ideal sales executive? Here are some that you should be looking for:
    • Self driven: sales executives are not the kinds of people that should be micromanaged. Instead they should only be given sales targets and expected to take initiative in finding new business. Although training is of course required, having a sales executive that needs to perpetually be told what to do and how do it defeats the object of hiring them in the first place.
    • Giver: most people can be classified as either takers or givers. Too often sales executives are focused only on what they can take from a customer instead of thinking about what they can give. The products being sold to the customers should be resolving their problems and generally improving their customers’ lives. Sales executives that ask themselves what they can do for their customers will enjoy repeat business, while takers will ultimately be shunned.
    • Empathy and emotional intelligence: you need someone that is good in in dealing with people. This does not not include being manipulative or aggressive in order to control people, but rather someone that that can manage their own emotions, know what they are feeling, what their emotions mean and how they’re affecting the people around them. A big part of emotional intelligence is also having enough empathy to put yourself in the customer’s shoes so as to understand their requirements.
    • Ego: although empathy plays an important part in relating to the customer’s needs, sales executive also need an equally strong ego to succeed. A sales executive’s self image should be linked to their success. Since they go through so many rejections, their self image will be chipped away continuously. Their ego needs to be strong enough to counter those feelings of rejection in order to persevere. Their ego needs to be continuously pushing them to chase the next deal to help them restore and boost their self image. However, their ego should not be so big that it inhibits their empathy.  There needs to be a fine balance between their ego and empathy because those two personality traits act as opposing forces. In simple terms their ego should be their driving force to keep them going while empathy should serve as the tool required to complete the job.
    • Good with numbers: in the corporate world it’s all about the numbers. It’s therefore incredibly important for sales executives to be able to conduct ROI (Return On Investment) analyses, negotiate prices, compile quotes, report on revenues etc. Having worked alongside sales executives and account managers I’ve often been amazed at their lack of competence when it comes to even simple things such as putting together quotes. As a technical pre-sales engineer at the time part of my job was to compile the BOMs (Build of Materials) but I didn’t have access to the prices the sales executives/account managers’ responsibility was to search for the part numbers on the price list, calculate the markups and plug those prices into the quotes. Unfortunately many of them couldn’t even do that, let alone understand what the products on the BOM/quote were for or why the customers needed them. Ironically I know for a fact that most of these sales executives/account managers were getting paid higher salaries than the technical staff not to mention the massive bonuses and commissions they were getting paid. It therefore goes without saying that being good with numbers is an absolute must for any sales executive because if they cannot calculate prices how are they supposed to make money for the company. Senior sales executives should also worry the profits made in every sale as opposed to just worrying about the revenue. Ironically however, most companies set sales targets that are based on revenues instead of profits. The only reason that I can think of in terms of why a company would do that is to hide the profit margins from the staff. Personally I find it completely irrational as it creates this false illusion of money being made while in fact they might only be breaking even.
    • Technologically adept: regardless of whether sales executives work in the technology sector or not, they will at the very least need some basic IT skills to get their job done i.e. sending emails, using CRM software, putting together spreadsheets etc. When selling technical solutions, it goes without saying that they would need and understanding the products and services that they’re offering. I remember having conversation once with a sales executives where he was proudly bragging to me that it doesn’t matter whether he’s selling a tech solution or he’s selling Coca Cola. It was all the same to him because he figured that it’s the technical pre-sales engineer’s job to discuss the technical requirements with the customers and compile the BOM while all he had to do was plugin prices. Obviously this is complete and utter nonsense because part of a sales executive’s job is to convince a customer to purchase the company’s products and one cannot do that unless one understands what the products do. What many sales executives hope for is that the technical pre-sales staff do the job for them while they receive the commissions and bonuses. This obviously defeats the object of hiring sales executives in the first place. It is for this reason that I have never really understood the need for a technical pre-sales role as it seems their only role is to compensate for the incompetence of the sales executives. As far as I’m concerned the sales executive and technical pre-sales should be one and the same job.
    • Communication skills: sales executives need to be well spoken and coherent in their communication. There is noting worse than a sales executive confusing you with illogical, inconsistent and contradictory statements. All this does is create the perception that they have no idea of what they’re talking about.
    • Strategic: sales executives will  be dealing with a multitude of customers and prospects and will therefore have to make an endless number of decisions throughout their day. For example, some customers are more trouble than they’re worth, stealing valuable time that could be used for more lucrative customers. Customers therefore need to be prioritised accordingly, which requires some form of strategy. Among many other aspects that need to be taken into account, some other examples include the life spans of products and whether they will be discontinued. For these reasons, sales executives that are not able to strategise can often find themselves running around like headless chickens.
    • Organised: most products and services that are sold require several steps after the customer has agreed to go ahead with the purchase. Some basic admin/finance tasks include the issuing and processing of purchase orders from the customers, placing orders with the suppliers, invoicing etc. When offering professional services the technical staff need to be briefed on the customer’s requirements. Hardware products and software licenses that are needed for a solution need to ordered ahead of time to ensure that they arrive in time for the go-live of the project. The customer’s expectations need to be managed correctly right from the start of the project when the sales executive is negotiating the deal. Failing to perform these tasks correctly and on time can wreak havoc on the technical staff, the customer and the project as a whole.
  • Irrational criteria used to hire sales people: now that we’ve established what the requirements for an ideal sales person should be, we have to ask ourselves how we end up with so many sales people that do not fit that mould i.e. what causes sales people and more specifically sales executives to be dodgy. Based on my own personal experience, I am convinced that the blame lies solely on the hiring managers putting way too much emphasis on personality when interviewing for sales positions, while completely ignoring all other attributes that would be required in any other job. Here are a few mistakes that are made by hiring managers when they’re recruiting sales people:
    • Mistaking narcissism for sales aptitude: as mentioned previously, sales people are required to have a strong ego in order to handle rejections and stay motivated. Their success needs to also be linked to their self worth prompting them to chase the next deal to restore their self worth. Unfortunately, all of these personality attributes are typical attributes of a narcissistic personality. On the other hand, the single personality trait that most clearly defines a narcissistic personality is a lack of empathy. A lack of empathy can be incredibly destructive in maintaining customer relationships and therefore getting repeat business. It can also be destructive in maintaining relationships with colleagues thereby creating toxic work environments inhibiting productivity. Ego and empathy are therefore opposing personality attributes but equally important to have in order to succeed as a sales executive. Ego is needed in the short term, while empathy is needed in the long term. The mistake that hiring managers make is being shortsighted by putting way too much emphasis on ego and too little on empathy when hiring sales people. This is essentially how we end up with so many narcissistic sales people in the world.
    • Too much emphasis on personality: conversely, throughout my career I have seen numerous sales people that have very few (if any) of the typical characteristics of a sales person but they happen to be phenomenal at their jobs. You might say that those people are the exceptions, but if that were true, then how is it that those individuals can be so good at their jobs despite lacking the personality traits of a typical sales person? You might say that a sales person deals with people a lot more than in any other profession and therefore personality should take priority. However, I think that people who believe that sales is all about personality are clearly undervaluing the products and services that their company is offering because as a customer I’m not looking to purchase a salesman, I’m looking to purchase a product or service i.e. I don’t care how charming and charismatic a sales person is, but I do care about the product I’m buying and the service I receive thereafter. What is the point of having a sales executive that can be charming and charismatic when they cannot explain the products they’re selling or even put together a a simple quote. This theory would therefore explain why telemarketing companies hire for personality since they’re mostly selling useless products that nobody wants. We can then conclude that the value you place on the personality of your sales people should be indirectly proportional to the value of the products the company selling i.e. the higher the value of the products, the less the personality of the sales people should matter and vice versa.
    • Purely focusing on sales track record: given all of the above, i’s quite clear that a sales executive’s skills should extend far beyond just personality and negotiating skills. It therefore boggles my mind as to why so many hiring managers fail to look at non-sales related success stories in their candidates’ track records i.e. whether the sales executive being interviewed has ever accomplished anything outside of sales. To drive this point home, let’s look again the at the types of people that end up in a sales positions and try to determine which would be a best fit for. The entrepreneurial types would be fantastic at the job, but the problem is that you normally won’t be able to hold onto them for long. Shortcut people would make for the dodgiest and laziest of sales executives, so I wouldn’t recommend them at all. Those with a useless education might be okay and could even survive in the industry, but they have no track record of ever achievement other than completing their education. Given their choice of getting a useless tertiary education you can also count on them being impractical, which can be disastreous to a career in business. Based on my own personal experience I can honestly say that the best sales executives are those that have decided to leave their past careers behind and try their hands at sales. Every single great sales executive that I have ever met was in a different profession before they got into sales. To give you some examples: one of my first managers studied mechanical engineering, thereafter started coding on the side and went on to launch several software companies. Another fantastic sales lady who was also the Country Manager and at an OEM subsidiary was previously a pharmacist and then decided that although she loved the chemistry side of things, working in a pharmacy wasn’t for her. Her predecessor was an electrical engineer turned salesman and her boss who was the global sales director for EMEA was previously a mechanical engineer. Another great sales executive and businessman I work for was preciously a chartered accountant. There are lots of other examples that I could give, but the point is that what all of these people have in a common is a track record of succeeding in some other profession before they became sales people. It undoubtedly shows that a charming and charismatic personality has very little to do with sales compared to the long list of skills required to be successful as a sales person.

A story of scope creep in a software project

Suppose you are a non-technical entrepreneur and you have a brilliant idea for a killer app. How do you now go about getting the app developed and what are some of the pitfalls you should look out for? Conversely, what if you’re one of the developers that gets asked to developed it? Over the years, I have seen the same story being played out over and over again, but just with different characters. Here is how the typical story goes:

  • The app idea: The story begins with the non-technical entrepreneur. Let’s call this character Marry. She has a brilliant idea for a killer app, but she’s not a software developer herself. She is however very business savvy. Marry therefore thinks that all she needs is to find one or more developers to turn her dreams into a reality. She figures that once the app gets developed and they go-live with it, she can tell the developers to step aside and she’ll take it from there.
  • Requirements: Marry puts together a list of basic requirements together. Like most entrepreneurs Marry is very optimistic and sees the app as being very easy to develop. She reckons that it shouldn’t cost too much and the whole process cannot take longer than a few weeks.
  • Corporate quote: she approaches a professional software development company to get a quote. Upon receiving the quote she gets the shock of her life. She thinks to herself that she can get a copy of a popular out-of-the-box software product at her local store for a fraction of that price. Marry then gets comparative quotes from other software companies which come in with similar estimates. Since she can’t understand how these companies come to these conclusions about the cost estimates, she figures that all established companies and corporates are being greedy and are all trying to rip her off.
  • The software geek: one day she meets a software developer called John. He seems like a nice, honest, down to earth guy and above all very intelligent guy. John is a typical geek that is obsessed with coding and technology. Instead of a wearing a suit, his attire on most days includes jeans and t-shirt. Being young and full of energy John has aspirations of starting his own software company one day. Marry immediately gets a light bulb moment and asks John to get her the app developed. She then proceeds to have a casual chat with John about her requirements. John hasn’t had that much experience in building commercial software products nor does he have any experience in project and cost management. However, he sees Marry’s proposal as a huge opportunity to learn a few new technologies and make some extra cash.
    • The agreement: since John hasn’t got that much experience he reckons it shouldn’t take longer than a few weeks. He puts together a basic cost estimate making sure that it’s an offer Marry can’t refuse. Since Marry has a bit of life experience she negotiates with John to bring down the quote. She also asks that they agree for payment to only be made upon completion of the project. Although John is a little reluctant to do so, he agrees, since he reckons that it’s better than nothing. The quote ends up being a fraction of what the professional software company originally estimated. Marry is overcome with joy in finally getting someone to develop her app and knowing that all her dreams will come true in a matter of weeks. Likewise, John is over the moon with getting Marry as his first customer and the opportunity of starting his own software company. This has always been his dream. Just like that two naive but well intentioned and optimistic people enter into a business agreement.
    • Bringing more developers on board: although John is excited about the project, he does feel a little nervous about doing it all by himself. Perhaps it could be due to a lack of confidence from a lack of experience, or perhaps he thinks they will get it done quicker as part of a team. He therefore decides to bring one or more of his developer friends into the project and agrees to split the money with them.
  • Project inception: since John doesn’t have that much experience, he doesn’t bother with an analysis workshop to flesh out the exact requirements for the app. Being filled with excitement, he and his friends pull out their laptops and get to work on coding the app based on their current understanding of the requirements. John gives Marry a status update every few days about how things are going. Marry is content with the feedback, everything sounds like it’s going according to plan.
  • Scope creep: after a few weeks, John announces that the app is finished and ready for go-live. It’s finally time to demo the app to Marry, who at this stage is overwhelmed with excitement she can barely contain herself. They setup a time and date to meet. It’s camera, lights, action! With each second that passes Marry’s excitement begins to fade and disappointment starts to creep in. In John’s defence the app does indeed meet the vague requirements that Marry set out i.e. it has all the buttons, data grids, links etc. Marry begins noting an extensive list of changes that will be required. For example, the UX and styling of the app is all wrong i.e. the colours, images and positioning of the controls. Furthermore, the business logic of the app is not completely correct and in some cases even missing. Although the app is not ready for go-live, being the optimist that Marry is, she says that it’s a good start, but the app will however require a number of “small” changes. Unfortunately for John, Marry doesn’t quite know the exact changes that will be required. For example, she knows that she doesn’t quite like what she sees in the UI but since she’s not a UX designer or graphic designer she can’t quite pin-point what or how it needs to change. She therefore makes more vague requests to John asking him to make the colours lighter and rearrange them a bit to make it “slicker” and more “modern” looking. What defines “slicker” and more “modern” looking to either of them. After seeing the app, Marry also realises that there are a number of business logic requirements that she hasn’t thought of previously. She now mentions those requirements that she can think of off the top of her head. Marry thinks to herself that whatever she can’t think of now, she’ll bring it up later.
  • Going pear-shaped: John realises that this will be more work than he bargained for. To appease the customer he decides to let this one slide by agreeing to complete the list of changes. After completing the changes they go through another demo. Since Marry did not have a complete and clear list of requirements, she once again asks for more changes. By this stage John is starting to become visibly irritated because he realises that the workload keeps increasing but the amount of money they agreed on is fixed. Going forward him and his friends will essentially be working for free. He explains to Marry that if she wants changes going forward she will need to pay more money. The way Marry sees it is that that they already agreed on a price and shook on it. Naturally she feels that she is being extorted for more money i.e. she cannot use the app in its current form while John is requesting for more money to complete it even though they agreed on a fixed price. On the other hand John also feels that he is being extorted for his time i.e. he agreed on a fixed price, but since the app requirements keep changing, him and his team will need to work for free with the possibility that they might never finish the project and thus never get paid for their work.
    • Jumping ship: after a few cycles of this chaotic coding and demo process, one or more of John’s friends decide to cut their losses and quit, leaving John to fend for himself. For John it’s not that easy to quit, either due to a moral or contractual obligation to complete the project. He is now stuck between a rock and a hard place.
    • Recruiting other developers: John explains to Marry that his team members have thrown in the towel and have gone on to greener pastures. He also explains to her that the progress will obviously slow down as a result of reduced man power. By this stage Marry sees his team as unprofessionals and lacking integrity to keep their end of the agreement. She also realises that recruiting more developers to replace John’s team member will require more money since the new developers will obviously not work for free. This isn’t what she bargained for, since she expected a fixed cost for the entire project. Furthermore, Marry believes that it was John’s decision to hire those developers and he should be accountable for that. However, she also realises that she cannot fire John since he is the only one left with the technical knowledge of the design decisions that have been made in the code. Depending on how forgiving Marry is, she may very well forgive John for what she perceives to have been mistakes on his part. Either way, just like John, Marry is now also stuck between a rock and a hard place. Left with no choice, she agrees to start looking for other developers to replace John’s team members. In the long run, throughout various stages of trial and error, Marry will end up paying the full price of getting the app developed i.e. the price that the professional software companies initially quoted her. Alternatively, Marry may also give up on the project if she lacks the funding.
    • Future projects: assuming that Marry ultimately gets her app developed, what are the chances of her getting John to develop another app for her in the future? I will leave you to ponder and decide that for yourself.

Now that we have a backdrop for this very common scenario, let’s a do a post-mortem of what actually went wrong and why it went wrong. In terms of placing blame I believe that neither John nor Marry are solely to blame, but are in fact both equally to blame.

  • What Marry the entrepreneur did wrong: although Marry may know a thing or two about business, she has limited knowledge and experience on what it actually takes to develop software. Ignorance unfortunately is at the heart of this these sad stories. Here’s what Marry didn’t realise until it was too late.
    • Paying for time and expertise vs paying for a finished product: when getting custom software developed you’re not actually paying for the finished product, but rather the time and expertise of the people that will be developing the product i.e. you’re buying development hours. This is comparable to purchasing a finished car out of a shop vs getting a custom car designed, engineered and manufactured to start your own car brand. You won’t need millions but billions to create your own car brand. The same applies to starting a business with software at the core of its operations.
    • Pricing of a product: even when purchasing a finished product, the price of it is not dictated by the value of the product but rather by the demand versus supply for the product. In the grand scheme of things and from a financial perspective, if you invest $100K into the development of an app, its value in terms of the number of features doesn’t really matter that much. What matters is the return on your investment i.e. how much money the app will help you make and/or save in the long run. This determined based on supply and demand of the app.
    • Finite mindset: Marry believed that software development is a finite process i.e. that it has a beginning and an end. She thought that she could pay a fixed amount of money for a fixed amount of development work to get the app that she wanted. Unfortunately that is not the case. For starters, the main reason being that requirements constantly change just like the world is constantly changing. There will always be new features and improvements that will be required. Older software frameworks and programming languages that are consistently being discontinued need to be replaced by new ones. Security mechanisms need to be constantly upgraded.  Not to mention the hardware capacity that needs to be increased in order to scale that application. Let’s look at Facebook as an example: according to them they have 1 engineer per 1 million users. That equates to thousands of engineers working for Facebook all working night and day just to keep a website and mobile app running 24/7. To quote Mark Zuckerberg’s character from the movie The Social Network, “software is like fashion, it’s never finished”.
    • Greed and short-sightedness: had Marry realised that the work required on a software product is never finished, she would have realised that there are only two options for getting her app developed:
      • Deep pockets: Hiring a contractor might have worked in the short term to get MVP (Minimum Viable Product) created. Long term however, the engineers really need to be working for your company in order to have full control of the product on which your entire company would rely on. Either way, Marry would need to have large amounts of money to fund the ongoing development. She either didn’t have the money or was too stingy to spend it.
      • Equity: even if Marry didn’t have the money to fund the development she should still have realised that software development is an ongoing process requiring an endless supply of money and work to keep it going. In which case, she should have offered John equity in the business thereby incentivising him to work for free/less money with the possibility of profiting from the business in the long term,
  • What John the software developer did wrong: John isn’t without fault either. He might be a talented software developer, but he had minimal experience in project management, requirements analysis and customer management in general. He pretty much broke most of the rules in professionalism in the software industry. All of these topics are discussed in upcoming chapters:

Do project managers actually add value to software projects?

Throughout my career I’ve worked with various types of PMs (Project Managers) and I too have managed many projects over the years. I’ve often pondered about whether PMs do indeed add value to projects or not. The simple answer is that I think PMs can indeed indeed add value to a project, but in my experience 90% of the time they just simply don’t. If anything they probably make the project go slower and bring about unnecessary complexity. Having said that, I don’t believe it’s any fault of their own. Personally I think this is caused by upper management assigning the project managers for the wrong reasons or there are other corporate politics in play that prevent PMs from adding value to projects.

So let’s start with a list of very wrong but very common reasons why a PM gets assigned to a project and how they end up adding little to no value:

  • Promoting the weakest link: Suppose there’s a guy on a software team called John and suppose that John has limited technical skills. This could be because he doesn’t have any talent for coding, or he’s lazy, or he isn’t analytical enough, or he writes horrible code, or maybe he simply doesn’t care enough about the company or project. When it comes to employees like John, upper management will have tried to place him in various roles in the hope that there’s something that he’s good. Unfortunately, John cannot code to save his life, and when given the opportunity to code, he creates more problems than solutions. They’ve tried putting John into an analyst role to gather and document requirements, but because of his limited technical skills he cannot translate functional requirements into technical requirements. Worse yet he doesn’t have any eye for detail, and misses a lot of important information when relaying information between the customer and the development team, which in turn can cause havoc on a project. They’ve tried putting him in a support role, but he ends up escalating almost all the issues to the developers without ever learning anything in the process. As ugly as it may sound the bottom line is that John is pretty much useless. So, what do you do with a guy like that when you’ve tried everything to increase his technical skills and the only thing that he seems to be half decent at is talking to people. Well, what often happens is that upper management will assign him as a PM on the next project. Their reasoning is that in their minds, project management is only about managing the customer, so John will definitely not be able to screw it up. Even if John does screw it up, project management can cause the least amount of collateral damage i.e. the developers will continue with their development and the project can still be a success.
  • Maximising billable hours: In software consulting companies it’s all about resources (people) and time. The more hours the company bills the more money it makes. Suppose you have two developers on a project and they communicate with the customers directly: any time spent attending meetings, phone calls and emails is often ignored i.e. it’s a loss to the company. Even if that time is actually billed for, you’ll only have those two people billing time. Therefore what many software companies do is to add as many people on the project as possible i.e. instead of having only having two resources on a project let’s add a PM into the mix so that he too can bill hours for attending meetings and drawing Gantt charts. This is the oldest trick in the book by any company that makes money through selling services. Lawyers often apply the same tactics: instead of getting one lawyer that can do everything, they will tell you that one lawyer specialises in one side of the law while another will specialises in something else, and you’ll need another to take notes, another to do research, and another to supervise the whole circus. In the software industry, it often happens that a PM gets assigned purely to increase the amount of billable hours instead of to actually manage the project.
  • Specialised project managers: many software companies hire PMs that have some sort of formal project management course under their belt and they assign these people purely into PM roles without any technical responsibility i.e. they’ll never do any analysis, design, development, or support work etc. The problem with this approach is that these PMs have no technical skills or engineering experience whatsoever. So if they ask developers for time estimates, they will take whatever the developer tells them because they don’t have any hands on experience to tell right from wrong. Worse yet, they might not even ask for estimates from the developers, and instead simply thumb suck the schedules and timelines. When deadlines are not met being met, the PM passes the buck by blaming the developers. Furthermore, when the developers try to explain a technical issue they’re struggling with, the PM cannot articulate those issues to the customer.
  • Glorified secretaries as project managers: many software companies are run by non-technical business people. For this reason, these business people often do not understand the work that the developers do, nor can they measure their developers’ progress. They’re often also not interested in the technical details regarding issues the developers are facing. What the business people do understand though are numbers. So what they often do is assign a PM for the simple purpose of capturing, keeping track and reporting back on costs and timelines throughout the project. At the same time, the PM is given limited authority. So when it comes to the technical staff not performing, missing deadlines and dealing with unhappy customers, this PM has virtually no power to do anything about it i.e. they might have the word “manager” in their job title but none of the technical staff report to them. In cases like this the PM is in fact nothing more than a glorified secretary that schedules weekly meetings to ask for progress updates, accepting anything the developers say without questioning anything. Thereafter the PM will update the Gantt chart and spreadsheets and forward them to the real manager who is not even involved in the project. This is a recipe for disaster because these kind of PMs end up being nothing more than shock absorbers for the developers thereby fostering  laziness i.e. the developers never have to face a screaming customer because their glorified secretary of a PM will take the hit, while at the same time the PM is not able reprimand them for non-performance.

For all the above reasons I believe that PMs add little to no value in most cases. However, I do believe that PMs can indeed add an incredible amount value under different circumstances.

Here are a few very good reasons for assigning a PM on a project and some strategies for maximising the value that they can add:

  • Reduce communication channels: the most important reason for assigning a PM to a project is reduce the number of communication channels between stakeholders. This really comes down to Fred Brooks’ famous quote, “What one programmer can do in one month, two programmers can do in two months.” The simple logic behind this statement is that the more people you add on a project the more these people spend talking instead of working. If you only have a single person on a project, then this person has no one else to talk to and therefore spends all their time working. If you have two people, they will spend a considerable amount of time talking to each other and consequently establish a single communication channel amongst themselves. Having three people means you have three communication channels between them. Having four people results in six communication channels. Hence, increasing the amount of people on a project increases the communication channels exponentially, which in turn reduces productivity. This is rule is known as Combinatorial Explosion and the formula for determining the number of communication channels is as follows: l = n(n -1) / 2 where n is the number of people on the project and l is the number of communication channels. Using the formula we can calculate the number of communication channels on a team of 10 people to be 45 i.e. 10(10 -1) / 2 = (10 x 9) / 2. As you might expect, in such a team, the 10 people will spend all their time talking instead of working. This being the reason why so many corporate environments have endless meetings without ever getting anything done. Smaller companies on the other hand tend to be a lot quicker and more productive. It’s in cases like these that PMs can be added to reduce the communication channels. By adding a PM in the centre of a 10 people team it will reduce the communication channels from 45 to 10 i.e. instead of each team member talking to every other team member, the communication becomes centralised by them talking only to a single PM.
  • Assign a PM with strong technical skills: adding a PM to reduce the communication channels is all good and great, but it will prove to be futile if the PM has insufficient technical skills to hold a discussion with the developers. For this reason it’s important to ensure that a PM has a strong technical background as well as people skills to communicate not only with the developers but also to manage the customers and/or business people. The result of having a weak project manager is that the developers will simply resort to sidestepping the PM by talking directly to the customer as well as manage the project amongst themselves. Evidently this defeats the object of assigning a PM in the first place.
  • Increase the PM’s authority: If a PM is going be assigned to a project, the PM then needs to be given absolute authority over the project. Even if some team members do not directly report to the PM within the company, within the context of the project, they should be reporting to the PM. Higher level management should explicitly make it clear to the team that they report to the PM and failure to do so comes with consequences.
  • Do one project at a time: Even if absolute authority is given to the PM on a given project, the developers for example may be working on multiple projects at a time reporting to multiple PMs simultaneously. The problem with this scenario is that the developers can use one project as an excuse for non-performance on another project. For example, a developer could say to PM 1 that they haven’t made any progress on project A because they’ve been busy on project B. They could then turn around and tell PM 2 that they haven’t made any progress on project B because they’ve been busy on project A. Meanwhile back at ranch, the developer hasn’t made any progress on either of the two projects, but the two PMs will be none the wiser. Amongst many other pitfalls of running concurrent projects is that it undermines the PMs’ authority thereby enabling the developers to run amok.
  • Global authority: In many companies it’s simply not possible to run a single project at a time. This could be for financial reasons where customers cannot be held off for several months in waiting for resource availability. In such cases, it’s best to assign a single PM to manage all concurrent projects, thereby granting the PM complete authority across all projects. The goal being that a single developer should report to more than one project manager at any given time. By doing so the developers will never be able to deceive the PM by using one project as an excuse for non-performance on another project.

Managing Costs of a Software Project

Developing software is an extremely time consuming process, requiring long hours of uninterrupted focus on the technical task at hand. That coupled with constantly learning new technologies, analysing requirements, designing, documenting,  coding, debugging, testing, installing etc. makes software development a stressful and difficult job. But no matter how difficult the job, for certain types of people the process of imagining something and bringing it to life from nothing proves to be work that is incredibly rewarding and self satisfying. Most successful software developers that I’ve met over the years love coding and most cannot imagine doing anything else with their lives.

Before I started working as a software developer professionally, I  remember spending hours sitting at my computer for hours on end writing code just for fun, without any interruptions or any other worries. When I was done my code had no bugs whatsoever and by that measure the code was perfect. If I wanted to implement another feature, I would just start coding it right away. The only limits were my own imagination. However, after I started working as a software consultant for a few years I noticed a few things that would kill the joy of coding. It’s for these reasons that many developers end up changing careers or at the very best keep switching between jobs in the hope of finding a light at the end of tunnel i.e. bringing joy back into coding.

The truth is that if you want to enjoy your career in the real world, you cannot continue sticking your head in the sand and pretend that you’re just a coding geek, and ignore the business aspects. You may not enjoy getting involved in the business aspects of software, but as the saying goes, “if you can’t beat them, join them” and believe me when I tell you that you definitely cannot beat the business people for the simply reason that they are pragmatic realists while most coding geeks are idealists with their heads in the cloud … or sand or whatever else geeky developers put their heads in. As George Carlin once said “Inside every cynical person is a disappointed idealist.” Continuing on a path of avoiding business meetings will turn you into a disappointed and grumpy pessimist, ending up complaining to your grandkids over Christmas dinner about how unfair the world is. So you may as well join the business people and turn yourself into a pragmatic realist that somehow always seems to find a solution where others see only problems.

Here’s some advise for getting involved in the business side of things. It all starts with managing ongoing costs of projects. Firstly, every software project has three components that need to be managed and there isn’t a single business meeting in which these components are not brought up:

  • Money: in the real world, people need to put food on the table, bills need to be paid and companies need to make a profit otherwise they go out of business. For this reason every little thing needs to have a monetary value assigned to it. So if you have an idea for a feature you’d like to develop, you cannot just start coding it because someone needs to pay for your time and effort. Your customer/boss will only pay for you to do it if it provides an ROI (Return On Investment) to the company i.e. a financial benefit the company gets from having this feature/application developed. Therefore before you start coding, you first have to create a proposal, estimate costs, prepare an ROI analysis, present it to the customer and wait for approval. Depending on the costs, complexity of the project and other factors this process could take a week, a month, a year, or it might never get approved (probably because your proposal sucked).
  • Time: regardless of whether you’re billing by the hour or you’re getting paid a flat salary, your time is being paid for. Therefore any feature or app you are developing must have a time constraint assigned to it because time equals money. To make matters worse, there are deadlines imposed by the customer because they need it by a certain date. If that’s not bad enough, you’re competing with other software companies, and so in order to win a contract, you’ll then have your salesman promising the customer (on your behalf) that you will in fact delivery the finished software in half the time for a fraction of the money that other companies are offering it for. While you’re still standing there dealing with the shock and horror of the situation, the salesman will then turn around and spew out motivational quotes to you which he heard at some sales seminar that he went to last week … or maybe he’ll just quote Barack Obama by saying “Yes, we can!”.
  • People: the more people are involved in a project the more politics you can expect. That’s just a fact of life. The reason being that different types of people have different agendas with different incentives in their job. So once again, before you get to write any code, people need to agree on what this code needs to do and how it needs to do it, how long it’s going to take, what budget is going to be allocated to the project and who is going to handle which work. Going forward you can expect millions of emails, phone calls, conference calls and endless recurring meetings that will make want to pull your hair out … assuming you have any hair left to pull out. Throughout this process both functional and technical specifications need to be written up which essentially serve as contracts for what will be delivered as the finished software to the customer.

You would think that people would be aware of all the above, but most people, especially inexperienced or non-technical stakeholders, somehow still believe that software projects are purely about just writing code. They either fail to foresee all the above mentioned factors or they simply choose to stick their heads in the sand and not learn from past mistakes. So they typically end up quoting purely for the time required to write the code, thereby setting up unrealistic expectations with the customers. On the customers’ end, it goes without saying that most customers are not software people and therefore never expect to pay for anything other than the time required to write code.

When these naive people inevitably run into these problems they throw their toys out the cot, arguments ensue which lead to meltdowns and they just generally become stressed out and unhappy with life. Many of the software companies then end up going out of business because of failed projects or loss of money due to time that was never billed for.

In order to to survive in this industry and avoid projects going pear shaped, you have to start managing expectations. Expectations translate into managing money, time and people and it all starts with the first quote to the customer. A million questions will arise when doing the first quote on a project. Here are some examples:

  • “Should we quote for emails, phone calls, meetings and other project management related work?”
  • “What if the customer refuses to pay for anything other than purely coding time?”
  • “Should we then just act like a charity and give that work away for free?”
  • “What percentage of the project do we spend doing project management versus time spent developing software?”
  • “What if unexpected things go wrong and the costs go up?”
  • “What if the customer keeps changing their requirements resulting in scope creep?”
  • “Should we then quote for requirements analysis and documentation work?”
  • “Will our competitors be cheaper than us because they’re not quoting for all the above?”
  • “What if our competitors undercut us by deliberately underestimating the time and effort required and oversimplifying the customers’ requirements?” This happens on a regular basis by the way. Many sales people do this because they know that once they get started on a project the customer will not be able to simply turn back if the project ends up costing more than what was originally quoted for. This approach is like the drug dealer sales approach i.e. the first one’s free, after that we’ll nail you.
  • “If that happens, will the customer be experienced enough to realise that they’re being played by our competitors and that in the long term it will eventually cost them more than they bargained for?”
  • “Should we then preempt the competitors’ tactics and deliberately under quote just so we can get the deal i.e. should we stoop to our competitors’ level?”

These are all difficult and valid questions to ask yourself before quoting on a project. What I can tell you though, beyond a shadow of a doubt, is that if you’re only charging for purely coding time, your company will inevitable go out of business. The reason being that in my experience at least 50% of the work required on most projects excludes coding time.

So what is the best way to quote and bill then?

  • Wrong sales approach: Under quote and over bill i.e. the drug dealer sales approach. As mentioned above, most inexperienced sales people will under quote and over bill in this manner and most inexperienced customers will accept these quotes, which unfortunately perpetuates these bad practices i.e. people learning from bad examples. This approach is equivalent to over promising and under delivering in terms of costing. There are all sorts of other problems which this approach can create:
    • By quoting for purely coding work and/or cutting the budget, you are cutting the time on the project, thereby putting unnecessary pressure on the developers who will end up taking shortcuts in their code, resulting in massive amounts of technical dept being accrued. In the long run, the project will end up costing way more anyway. Hence I say that you would be putting yourself and/or other developers under unnecessary pressure.
    • It goes without saying that taking shortcuts leads to lower quality code being produced and the software being filled with bugs.
    • Due to the low quality code and over-budget costs, your reputation will end up being tarnished in process. So even if you end up finishing the project successfully, that very same customer will most likely never call you again for the next project.
    • In the end it really comes down to the customer getting what they pay for. That being the reason for many internal and enterprise products only being as good as they need to be i.e. sales people undercutting competitors, underestimating requirements and customers being cheap and shortsighted.
  • Right sales approach: Over quote and under bill: it’s always difficult to estimate the costs and timelines of a project. For this reason and all the reasons mentioned above, I have found the best strategy to be as follows:
    • Sales meetings: During your first sales meeting/s with the customer, get a sense of the their requirements. You don’t need to get into too many details about every custom single business rule and how exactly each feature will be developed. The reason being that the customer is not paying for these sales meetings. Hence you don’t want to spend too much time doing the analysis and design work before any payments have been made or approvals have been granted i.e. you do not want to work for free. Furthermore, it can often happen that you’ll go through a long and rigorous analysis phase, designing and fully documenting a proposed solution only later to find out that the customer took your design to a competitor and ended up paying them for only their coding time. You may or may not be surprised to know that this in fact happens quite often. If you do this enough times your company will end up going out of business. The purpose of the sales meetings should only be to:
      • Sales Pitch: Pitch yours and the company’s services to the customer. The main aim of your first sales meeting should simply be to prove your competence and skills to the customer.
      • Requirements Overview: get an overview of their requirements for the software they’re looking to develop. Don’t get bogged down into specifics. The specifics should be left up to the analysis phase when the customer is actually paying for your time.
      • Proposal: put together a proposal for the solution you plan on implementing. This proposal should not be a functional and especially not a technical specification. There should be no mention of specific features or technical details of how the software will be developed.
        • Technical Information: from a technical perspective it should only provide an overview of the technologies (hardware, frameworks, SDKs and programming languages) you plan on utilising to provide the solution. You can  provide them with generic architecture diagrams, but don’t spend too much time creating custom diagrams that are specific to their business.
        • Solution Benefits: you should mention the benefits of implementing such a solution. This could be an increase in productivity, accuracy, automation etc.
        • Costing: this is the tough part that most people get wrong. Only through experience will it become easier to prepare costing estimates.
          • Development Costs: firstly, you need to think of the time required to develop the software by breaking down the tasks. If you’re using XP and Agile, these could be your stories or whatever you like to call them. If you’ve done similar projects in the past it will be easy to make an estimate. However for features that you’ve never implemented before, I would advise you to always be conservative i.e. think about the time required for research, testing debugging etc. If you’re not the one developing the software, this process will be become even more difficult in which case you will need to speak to the developers and get estimates from them.
            • Developer Confidence: Keep in mind that you cannot just take the developers’ estimates at face value. The reason being that some developers provide optimistic estimates, while others provide pessimistic estimates and this is based on their confidence, which may or may not necessarily have anything to do with their actual skill level. Confident developers typically tend to under estimate the time and effort required for coding, while under confident developers will overestimate time and effort.
            • Code Sloppiness: Some developers can be incredible quick to write code but they code can be sloppy. For such developers, you need to add buffer time for them to go back to refactor and debug etc. Others are perfectionists and take really long to code, but when their work is done it’s actually done. Therefore, you need to take all of this into account on the overall costing.
            • Buffer Time: Once you’ve come up with a fair estimate, it is best to always add a further buffer by multiplying the estimated hours with a factor. This factor is something of gut feeling you get through experience. For example, suppose a developer gives you an estimate of 10 days of development, you could then multiply that by 1.5, thereby your estimate to the customer being 15 days. The reason for this buffer is to take into account unexpected issues that can and do always pop up. Some may say that allocating extra time encourages procrastination, but I think that’s non-sense because it is the project manager’s job to check on up progress and ensure that people are meeting their timelines.
            • Do not quote on details: when quoting for development work, do not make the mistake of separating and displaying costs for every little coding task e.g. do not quote for each and every single button that they want on a form. Instead group the costs together and have only one or two development line items on the quote. The reasoning behind this is because you do not want the customer interrogating you about every single line item e.g. “Why would it take 8 hours to develop a single button.” The purpose of not quoting on details is not to be dishonest about the costs, but rather to avoid having technical debates with a customer that isn’t technical i.e. the customer has no idea how much work goes behind implementing the logic of that specific button and therefore to the customer it just looks like a simple button, while there could be 2000 lines of code behind that button for it to do what it’s supposed to do.
          • Project Management Costs: think about all the time that will be spent on the phone, writing emails, in meetings and driving around to those meetings. You must also take into account the kind of people the customers are when making this estimate. If your customers are professionals that know exactly what they want and they themselves plan ahead, then the project management costs can be reduced. However, you will have customers that know very little about software projects, are unprofessional, will constantly change their minds about what they want and the goal posts and timelines will constantly change. For unprofessional customers, I’d advise you to increase the project management costs substantially because you’re going to be doing a lot of baby sitting.
          • Analysis Costs: this is the time required for you to sit in workshops and meetings to discuss and finalise requirements and write up documentation. This time needs to be paid for because at least a third of your project will involve analysis work. It is for this reason that you should never make the mistake of starting the analysis phase before presenting the proposal and getting the customer’s go-ahead on the project.
        • ROI Analysis: finally once you’ve come up with a final number for the costing of a project, you then need to sell it against a value you’re providing to the customer’s business i.e. you need to give your customer a financial reason to spend the money on doing the project. Simply listing reasons is not going to cut it. Your motivation for doing the project needs to be have financials attached to it and that is typically the ROI (Return On Investment) calculation. In most cases, customers will already know why they want the software implemented, that being the reason why they called you in to take on the project. However, that may not always be the case, especially in cases when you are the one approaching them. In such cases you need to show the customer that doing the project will be an investment in their business and like any investment it must have a return/payback in a certain amount of time. So for example, if the project costs will be $100 000, you need to show the customer that the software will reduce costs in other areas of their business thereby enabling them to save X amount of money every month.  Those savings will amount to the total investment in a certain amount of time and that will be your final ROI payback period. Going forward the customer will continue to save for as long as they continue using your solution. In other words, the purpose of an ROI calculation is to establish a win-win deal with the customer whereby you earn money from the project implementation and the customer wins even more in savings over time. Selling based on ROI is the most difficult kind of sale you can make because you will need to have a thorough understanding of the customer’s business in order to put together an ROI calculation. However this kind of sale is also the most rewarding because instead of selling based on billable hours, you’re selling based on the value your software solution provides. It always helps if you are already familiar with the specific industry that the customer is in. If not, then you will be required to do a lot of research into the industry. Either way you will need to ask the customer a multitude of questions regarding their business before you can understand how to solve their problems and cut their costs.
      • Project inception: once you’ve presented the proposal to the customer you can expect to have a few backwards and forwards rounds of meetings and discussions about the proposal. Do not make the mistake of starting a project without the go-ahead from the customer. If it is a new customer that you’ve never dealt with in the past, I would advise you get a formal approval in written form from the customer. This can take the form of a PO (Purchase Order) or otherwise some sort of a signed contract.
      • Analysis and Specification Documents: it is only at this stage once you’ve gotten the go-ahead from the customer that you can start working. However, it is still not time to start coding just yet.
        • Project Plan: First and foremost you need to put a project plan together. The project plan will consist of the timelines of when each project deliverable (feature/work) will be completed and which resources (people) will be working on those deliverables. Both you and the customer need to agree on the project plan and the timelines need to be in line/comparable to the project costing in your proposal.
        • Functional and/or Technical Specifications: included in the project plan should be time allocated for analysis work and writing up the functional and/or technical specification. This phase of the project will involve having workshops and meetings to discuss the requirements of the software. Throughout this process, you will document the requirements in a formal specification document.  Many developers will say that documentation is a waste of time, but in the business world these documents will essentially server two purposes:
          • Contract for work required: The specifications will serve as a contract for what the customer can expect of the software. No more and no less than what is specified in the document will be delivered to the customer for the agreed upon price. It is for this reason that many software companies only quote the customer after the analysis phase, because they will say that they cannot quote for the project without fully understanding all the project requirements in detail. However, remember that I mentioned that in the costing process you should always add a buffer i.e. allocate extra budget and time for unexpected costs. This buffer that you added in your costing should cover any unexpected work that is being requested during the analysis phase and it will also protect you from doing the analysis phase at the risk of not getting paid for this work.
          • Mitigating scope creep: without a specification in place, the customer can continue asking for changes and you will end up spending way more time on the project than you initially anticipated all the while the customer is getting all this additional work for free.
      • Billing:  Many software companies bill only at the end of the project with an agreement in place that the customer only pays once the project has been completed and the solution has been implemented and tested. This is a huge mistake. The reason being that the customer will be under the impression that the project costs you presented in the proposal are a flat fee and in such a scenario the customer will not take into account the accruing costs of changing requirements, calling you in for additional meetings etc. All of that can land you in a mountain of scope creep costing your company ridiculous amounts of money. Hence it is important to:
        • Bill actual hours not estimated hours:  It is crucial to make the customer understand that the costing you did in the proposal are only estimated costs and that they will be billed the actual hours worked instead of these estimated hours. This clearly tells the customer that it will not be a flat fee for the project, but instead can change based on changes in the requirements. If you added a buffer to the budget (over estimated costs) in your proposal, the customer will end up being pleasantly surprised when the costs of the project are less than the estimated costs. However, if the customer continuously asks for changes throughout the project even after the specification document has been agreed on, these changes will be handled as CCRs (Change Control Requests) which fall outside the scope of the initial specification. The CCRs must be paid for and given enough of these CCRs the total cost of the project will end up going over the initial costing in the proposal. Having these mechanisms in place will encourage the customer to think twice before asking for changes to the initial agreement and will protect you against scope creep.
        • Bill in cycles: Bill the customer for the hours worked in continuous cycles e.g. monthly or even every two weeks. The developers and other resources on the project will then have to keep track of their hours worked and ensure that the costs are not going over budget. If the costs do end up running over budget, either because your initial estimation in the proposal was wrong or because of CCRs, the customer must be alerted of it and approval must be gotten from the customer before continuing with the project.

Keeping all of the above in mind, here’s a summary of golden rules to follow in order to manage the costs of a project.

  1. Always over quote and under bill instead of under quote and over bill.
  2. Do not get into too many details in the sales cycle i.e. when drawing up the proposal and estimating the costs of the project.
  3. Bill actual hours worked instead of estimated hours: Explain to customers that the quote is purely an estimation and that they will be billed actual hours worked rather than estimated hours. Explain to them that if there are no change requests, they can most likely expect the total cost to be less than the estimated cost in the initial proposal.
  4. Never work for free: aside from the sales meetings, proposal and costing, no other work should be done for free without formal approval from the customer. Even after the project has started, any change requests must be paid for.

Why do large software companies open-source their projects that they’ve invested so much into?

This is a good question, because it seems like a bit of a contradiction: these companies are there to make money and they’re spending money to develop these products but they’re still “giving” their code away for “free”.

Obviously I don’t know exactly what the thought process is by the executives of these companies, but I can take a guess. My guess is that open-source is great if you want to:

  • Lower costs: get others in the open-source community to work for free in testing and spotting bugs in your software.
  • Lower risk: this goes along with lowering costs i.e. lowering the costs lowers you investment risk. Furthermore, getting feedback from the open-source community is a lot quicker than having to wait for the software to be released and only thereafter get feedback from your users, by which time they might have created a negative impression with the end-users (if the software is full of bugs).
  • Increase adoption rate: most of the products being open-sourced are SDKs and other development tools. This is very beneficial to developers using those development tools i.e. because it gives the developers more freedom and control. In the long term they end up with more developers/users hooked on their platforms at a quicker rate. As an example, I’m guessing it’s one of the reasons Microsoft opted to finally open-source .NET because it would get a lot more developers hooked on their platform, programming languages and development tools, which ultimately results in more apps being developed using Microsoft technology. Once they’ve increased the number of apps on the market developed using .NET, I’m pretty sure Microsoft have plans to capitalise on that in one way or another.

When to open-source and when not to open-source

If you’re a developer and have no intentions of every getting paid for writing code, then deciding between open-sourcing your software or not can be a simple decision. However, if you have any intentions to get compensated for your work, then the decision to open-source or not can be a complicated and long winded debate which has gone on for decades. On the one side you have the capitalists/conservatives that sell software for a price and their pricing models are relatively simple to understand especially in commercial and non-enterprize environments i.e. you get this product for this price. On the other hand, you have the open-source socialists/liberals/anarchists, advocating for making software “open”, transparent and most of the time offering it for free. However, for anybody that has ever delved into the open-source debate, they will quickly realise that open-source is in fact not that clear and transparent after all.

It’s all good and well to spew out socialist rhetoric about how we should all be more altruistic by volunteering our time and skills to open and transparent software communities, but once we’ve all had our turn at singing kumba-ya, the truth is that in reality there’s no such thing as free lunch. Meaning that although many open-source enthusiasts pitch the idea of so called free software, the users will still end up paying for it one way or another, be it in some sort of fee, time, energy and/or frustration. The reason being that in the real world, time equals money and money makes the world go round. Therefore, any developer working on a “free” and open-source project still needs to pay the bills, put food on the table and at the very least still have money left over to buy a laptop on which to work on. So how do open-source developers get compensated? Open-source projects typically start off as side-line hobby projects, then perhaps moving on to offering paid for versions and/or charging for services.

Over the years I’ve thought about this debate countless number of times and like most analytical people I’ve searched far and wide for an absolute answer i.e. is open-source good or bad. When I was younger I leaned more towards the open-source point of view and their anarchist/hippie rhetoric about how corporations are evil, money-grubbing establishments designed to create monopolies and control people’s lives. Now that I’ve gotten older, my view has become a bit more conservative. Maybe it’s got something to do with there being a grain of truth in Winston Churchill’s wise words where he said that “any man who is under 30, and is not a liberal, has no heart; and any man who is over 30, and is not a conservative, has no brains.”

So here’s my attempt at an absolute answer as to when to open-source and when not to:

  • How most open-source projects start off: as the saying goes, “necessity is the mother of all inventions”. By that token, most open-source projects start out from a need/problem that someone has. A developer may want to achieve something that they cannot do with commercial software that is available or they just don’t have the money to purchase commercial software that can perform the given task. While developing this new app for their own needs, it suddenly dawns on the developer that other people may have the same need/problem that their new app can solve. At this point the developer begins to think about how they could possibly get others to use this new app and possibly capitalise on it. After careful consideration they realise that there’s more to selling software than simply putting a price tag on it i.e. a company needs to be setup, marketing needs to be done, payments need to be captured, orders and invoices need to be created, taxes need to be paid and amongst many other things, all sorts of people need to be hired e.g. marketing, sales, finance, support etc. Starting and managing a company requires a lot of work and responsibility. Due to the fact that a descent amount of capital is required, it also involves a huge amount of risk i.e. it’s not always easy to predict whether or not a software product will be a hit or not. So as opposed to going through that whole nightmare, our friendly developer decides to rather just upload his code to a popular open-source repository that all his friends can access. If nothing else, it will look good on their resume.
  • If the software is a hit: if there proves to be a substantial demand for the software, the developer may begin thinking about capitalising on it. At this point the developer will probably be stuck between a rock and a hard place. If he closes down the open-source repository and begins to charge for the software he’s fear is that the users will just continue using the latest open-source version available and never purchase any new versions. Even if there are some people willing to pay for the software, the problem is that the developer will never be able to sell it to enterprise customers because no large company will agree to adopting a product that is being supported by a single individual i.e. it would just be too risky for the company. So it’s a bit of a chicken and egg scenario i.e. you need to generate revenue to hire more people, but customers are hesitant to commit to a one man show. On the other hand if he keeps the open-source repository available, then there is no way to make money on it. To get out of this dilemma, most developers in this situation either begin selling services or offering paid for upgraded versions with additional features.
  • Charging for services approach: most open-source developers will write the code for free to develop the software, but if users need any help with specific feature requests, installations, advice or any consulting services, they will be charged an hourly rate or are sold a 1/3 year Service Level Agreement. As a bit of a realist, it is at this point that I start questioning the incentives put in place for this type of revenue stream. I ask myself, what incentives do open-source developers have to produce quality software that is easy install and use when their primary revenue stream comes from selling services? If charging for services is your only revenue stream on an open-source project, then there is a clear conflict of interest in this approach and I would advise against it. Reason being that what users want is software that is easy to install, configure and use, while at the same time the developers are well aware that the easier the software is to configure and use, the less services they will sell. So what you end up with, is open-source software that is counterintuitive and users are constantly left with more questions than answers. In this kind game with these kind of incentives in place, there is not much that is open and transparent to the users i.e. the software and code is available and free for anybody to use, but nobody knows how to set it up and us it. You may be of the opinion that it doesn’t matter whether there’s a conflict of interest or not, as long as you’re making some money off of your efforts. However, my argument would be that users are not stupid, they always know when there is a conflict of interest and sooner or later they will start posing questions. This approach also creates confusion that results in users asking why you’re doing some work for free while charging for other work. This is where open-source can lack transparency. With the above said, there are some more negative side effects with this approach:
    • Minimal documentation: the whole point of writing documentation is to make it easier for users to understand the process of installing, configuring and using a given piece of software. Given the fact that many open-source software is offered for free, the developers have almost no incentives to write comprehensive documentation i.e. the more difficult it is for a user to get up and running and troubleshoot issues themselves, the more services the developers can sell. What you naturally end up with is open-source software that often has little to no documentation aside from a simple two page quick start guide. The counter argument from open-source developers is that “the code is the documentation, just look at the code”. But if we cross over from the delusional hippie world into the real world, we realise that most users are not coders and therefore having the code adds zero value to their lives. Even as a coder myself, if I’m interested in using someone else’s software I will neither have the time nor the interest in doing support on other people’s products. Personally I just want to be able to click install, use the software and move on with my life because I have enough of my own code to deal with, without having to deal with other people’s broken code.
    • Lower quality of open-source software: in terms of quality, the argument made by open-source purists is that their software is of much higher quality than that of proprietary software. According to them this is due to the fact that open-source communities are larger and there are more people testing, spotting bugs and fixing them as opposed to small teams that develop proprietary software. This is based in Linus Torvalds’ law that “given enough eyeballs, all bugs are shallow”. That does indeed sound plausible, but on the other hand it seems to me like a bit of a contradiction to the many open-source companies that rely on services as their primary revenue stream. If the quality of open-source software is so incredibly high, then how do they make their money on services i.e. if there are no bugs to fix, the apps are easy to use and everything just works, then what kind of services are these developers selling to pay the bills? Developers creating proprietary software on the other hand have every incentive to write high quality code and create intuitive user interfaces, because if they don’t, then nobody will buy their software.
  • Paid for upgraded versions approach: an alternative to only offering services is to develop additional features into the open-source software and offer those features at a premium i.e. offering a “free” open-source community version as well as a paid for version with additional features that are enticing enough that make users want to spend money. Open-source can be fantastic when you want to lower your risk while at the same time increase the user adoption rate of your software. By open-sourcing your software you can start a project without having to take on the risk of starting a company, investing capital etc. and if there proves to be a high enough demand for your software, you can then take it to the next level by offering additional features and charging for them. This is the only time I would see open-source as good idea i.e. assuming that you actually want be compensated for your work.

In summary, before open-sourcing your software you should consider the number of features that you have in mind and whether or not there will ultimately be a demand for those features on the market. There are many apps that can be incredibly useful, but beyond their basic features there are a limited number of additional features that can be developed and incorporated into future paid for versions. A great example would an SDK (Software Development Kit) to interface with third party application or hardware: there are only so many features you can add to such an SDK. This kind of software with limited useful features should either be open-sourced without any intention of ever making money or it should never be open-sourced, but rather be released and sold as proprietary software right from the start.

Technical engineering vs social engineering in a software project

I started off my career in a product development environment; I sat behind a desk all day every day writing code. The only work related discussions I ever had to have was with the CTO (Chief Technical Officer). He told me what to do and how to do it. I was incredibly lucky to have fallen under his wing, because he was an incredibly talented developer and manager with years of experience. Not only did I learn a lot from him but I could always count on the fact that he always had answer to any problem I was facing.

However, in retrospect I realise I was working in a sheltered cocoon. Wanting to explore other opportunities I later moved on to a software consulting company. Soon after having started as a software consultant, I realised that I was in over my head. Interestingly enough, the technical challenges I was facing were relatively trivial compared to what I was previously doing. At the time I couldn’t for the life of me understand why I was struggling. Through experience, I later learned that the problems were not technical in nature, but they were rather social engineering problems i.e. I wasn’t in charge of managing the people on the project and even if I was, I wouldn’t have known how to manage them.

Every software project will always be made up of three major components:

  • Problem: at the core of every project is an underlying necessity for a problem to be solved.
  • People: there are expectations that are set out in every project by the stakeholders. These expectations are essentially agreements as to how a solution will be developed for the above problem to be solved. The stake holders involved in setting out the expectations are mostly made up of two crowds of people.
    • People requesting the software solution.
    • People providing the software solution.
  • Solution: once the expectations have been set out, they need to be met by the software developers i.e. developing the software that solves the defined problem according to the expectations that have been set out.

Most inexperienced software developers and business/sales people often believe that developing software for a customer/investor is all about the technical solutions that need to be implemented to make the customer happy. These kinds of people often accept the word of the customer as the word of God i.e. they walk around saying “the customer is always right” or the “customer is King”. Personally I believe they do this because they either lack the experience, a backbone and/or foresight. Hence they are “yes people” that often say yes to whatever the customer asks for, no matter how ridiculous/incorrect these requests may be and without considering the big picture. Hence they become a puppet being played like a ping pong ball by the customer’s stakeholders, and thereby ultimately ending up with a failed project on their hands.

Part of the reason this happens is because as kids, most of us are brought up to think that our superiors (parents) are always right and that they have our best interests at heart. When we enter the working world, we tend to see our managers and/or customers as our new superiors because they’re paying paying us. Therefore our natural instinct tells us to believe the same principle applies to them i.e. that the customer is always right. However, in the real world a consultant is hired to recommend and provide solutions, not to just simply take instructions. Simply put, the customer is not your parent.

Furthermore, as the name implies, each stakeholder has their own individual interests and incentives that motivate them. Whenever there are a multitude of varying interests, you can bet that there will always be conflicts of interests. Hence it would be foolish to allow the stakeholders to control the expectations and proposed solutions, thereby controlling the project itself. Your job as a consultant is to understand the needs of the businesses, the needs of each stakeholder, what motivates them and what their incentives are, so that you can gather enough information to make your own proposal for a solution. The consultant must be the one in the driver’s seat of every project.

Simply put: the consultant should never ask what needs to be done, but instead tell the customer what needs to be done and how it will be done based on the problem at hand. This means that at least 50% of the consultant’s work involves setting the right expectations, thereby requiring social engineering to be applied before a single line of code is written.

So what is social engineering in the context of software development?” Here a few points on this:

  • Understanding the customer’s business:
    • A customer will often request for technical solution to solve what is often only a simple operations problem. For example; in a warehouse they may request for software with a simpler and more intuitive process flow to be used by employees handling stock on the warehouse floor. Doing so may increase the productivity by 10-15%, but given the fact that according to statistics a warehouse worker spends 50% of their time walking to different locations, the more serious problem at hand are the long distances between the bin locations, rather than the process of data processing on a mobile device. In this example, software cannot solve the problem of the physical distances between bin locations, instead it can only optimise the existing processes which may be inherently flawed. As a consultant you need to understand these nuances and draft your proposal accordingly.
  • ROI (Return On Investment) & Budget: keeping in mind that that the primary aim of most businesses is to make money, the need for most software projects comes down to a necessity to optimise current processes by cutting costs and increasing productivity. Hence, any recommendations should be applicable to the customer’s business needs i.e. do not make recommendations to develop features just because it would be fun for you to develop them.
    • ROI: any feature to be developed, needs a cost associated with it and an ROI to be proven i.e. the customer is paying X amount to have this feature developed, therefore how much money will they be saving and how long will it take before the feature is paying for itself?
    • Budget: you also need to keep in mind that although you may be offering a great solution and a great ROI, the customer you’re proposing the solution to may not always have the budget to invest in it. This applies to any sort of business. For example, someone may present you with a bargain to purchase a block of flats that you can rent out and get a fantastic ROI, but if you don’t have the budget to make the investment, it really doesn’t matter how great the solution/business opportunity is. Hence, you should never be shy to discuss the budget with a customer upfront. This will prevent you and the customer from wasting each other’s time.
  • Understand your audience: IT staff for example, are more concerned with the network and IT infrastructure of your proposed solution than the usability or how it improves the business. Finance people are more concerned with the costs and ROI than with the actual features being offered by your solution. Operations people are more concerned with efficiency of the solution rather than the costs or technical architecture. Finally, end users are more concerned with the features and usability of the solution than with any of the above. You need to pay careful attention to who you are talking to at any given time as well as what you say, how you say it and what questions you ask.
  • Managing expectations: customers often do not understand the implications of developing software, such as the amount of effort and time that will be required. Based on that you should not allow the customer to dictate how long something should take and how much effort will go into it. As a software developer, it is your job to inform the customers of the above and be firm about it. They must accept your estimations or go somewhere else. Needless to say that the estimations and expectations you set should be reasonable and some flexibility (within get reason) on your end will prove to go a long way.
  • Getting paid: finally you need to worry about when and how much you will get paid. You will come across many customers that expect you to work for free with only a promise or a maybe of getting paid. Therefore it is imperative that you address this question with the customer right from the start in order to set the right expections. Also keep in mind that many customers that deal with software consultants are often under the impression that they are buying software, which couldn’t be further from the truth i.e. they are not buying software, they are buying your time and expertise which you need to make crystal clear to them right from the start.

To summarize: a software project is more than just someone telling you what feature to develop and then coding it. Therefore it is imperative that you understand the social engineering aspects so that you can manage the customer instead of the customer managing you. With the above said in mind, half the project is performed in boardroom discussions and over emails and phone calls, not just behind a computer simply writing pretty code.

Will software developers continue to be in high demand in the future?

These are some of the trends that I have seen over the years:

  • Data agnostics software: if you’ve ever spent time jumping from project to project developing custom software for various customers’ requirements, you will pretty quickly come to the conclusion that you’re basically developing the same software over and over again and the reason you’re doing it is because each customer has different business rules. So to make your own life easier, you will inevitably start thinking about removing the business logic out of the code and making the software more and more customisable thereby making it data agnostic so that it doesn’t know anything about the data its working with. By developing data agnostic software, you are basically handing over the power and responsibility to your customers enabling them to implement the business rules themselves instead of relying on you to change code every time they change their business rules. Doing this is all good and great for the customer and even for your own company, because you can then resell your software to many more customers without having to code business logic for each new customer. However, the problem is that other competing software companies that are still coding custom business logic will be blown out of the water by you i.e. their customers will now rather just buy your out-of-the-box and customisable software from. The end result being that there will be less and less demand for software developers building custom business applications. That is why for example most corporates prefer implementing large systems like ERP, CRM, WMS, CMS etc. that are trusted and have been proven to work as opposed to developing their own system from scratch. Although these large software systems are more and more business logic and data agnostic, for the time being there will still be a need to have technical people installing and customising these “out-of-the-box” products. However the “technical” people required to do so will be less and less technical i.e. less and less technical skills will be required to perform customisations for each customer.
    • Example: back in the 1990s, if you wanted a simple company website you would have hired a web developer to put together a few HTML pages i.e. Home, About, Contact Us page etc. At some point, some clever guys decided to develop a CMS (Content Management System), which is exactly that: a data agnostic piece of software that doesn’t know or care about what content you’ve got, but it gives you the power to configure it yourself. You would still need an IT guy to perform the configuration and handle the hosting, but you no longer needed a web developer.
  • SAAS (Software As A Service) & PAAS (Platform As A Service) in the cloud: to make matters worse (or better , depending on your perspective), these large systems (ERP, CRM, WMS, CMS etc.) are now being moved into the cloud and offered as a service i.e. monthly payments to access the software online. That means that business people no longer even need technical IT staff to manage the hosting or to install and configure anything because that is now handled by the SAAS providers. Thus, once again making more technical people redundant.
    • Example: at this point the customer no longer even needs a CMS hosted on their own server. Instead they can just create their own website on wordpress.com without having any technical knowledge. If integration with a payment portal is still too difficult, they can even use Facebook Store or shopify.com.
  • Platform agnostic software: I started my career in mobile development, back when the popular operating systems available to develop for were Symbian and Windows Mobile/CE. If someone wanted a mobile app developed, they would have needed to hire a developer to code the app from scratch. Coding an app for Symbian was incredibly difficult with a 6–12 month learning curve, Hence requiring highly skilled Symbian C++ developers. In the company that I was working for, we were developing a .NET Compact Framework to run on Symbian, thereby allowing less skilled .NET developers to write code targeting the .NET Compact Framework and thereafter run that same app on Symbian. The very same people that I was working for ended up starting another company (devicemagic.com), allowing people with limited technical skills to put together a mobile app that will run on any of the popular operating systems like Android and iOS. Once again, if your requirements for a mobile app are relatively simple (data capturing, taking pictures etc.) then you no longer to hire expensive iOS, Android or .NET developers to build the app for you.
  • AI (Artificial Intelligence): at this stage AI is still a baby, but the baby is growing. Once fully grown it will further exacerbate the situation where we might see autonomous software writing code by itself based on your specifications. With AI programming languages will not even be needed anymore because the only reason programming languages exist is to enable humans to define the execution of a program. If the machine is generating the code, it will simply generate binary code.

The moral of the story being that it’s survival of the fittest i.e. the big fish will continue to get bigger by eating the smaller fish. The name of the game is consolidation; of technology, money and power. But to be fair humans have been playing this game since the beginning of time to the point where the little people on the ground get fed up and come out with their pitchforks, after which war breaks out, people die, everything gets destroyed and the survivors start rebuilding everything from scratch thereby starting the cycle all over again. But even knowing this I still can’t stop myself from recoding that function in my code to remove the business logic so that I can reuse it with my next customer.

To answer your question: as long as software still exists in this world, there will always be a need for software developers, but personally I think that the demand will drop in the long term. In a few decades, only the most talented developers will have jobs and they will most likely be working for the big fish, like Microsoft, Apple, Google, Oracle, SAP etc.

Knowing this, what can you do about it if you’re currently a software developer? The answer is; not much … except enjoy the proverbial gravy train that you’re currently on.

In the interim: focus on the following caveats of the above mentioned trends/technologies:

  • Security & Trust: there are still plenty of companies out there that are hesitant to move their data and infrastructure to the cloud. This especially applies to financial institutions which hate the idea of putting their money (numbers) into the cloud hosted by a third party. Their concerns being centred around the security of their data and whether or not they can trust the cloud hosting providers with their data/money.
  • Control: many of these companies are still run by control freaks that want highly customised software that works exactly the way they wanted to work. They will never be able to get that with so called “out-of-the-box” solutions. Thus they will still require highly skilled developers. For how long … only time will tell.

For the future: plan ahead by deciding between two different paths:

  • Technical: if you decide to stay the course and focus on being technical, then you better make sure that you are part of the best of the best. Average won’t cut it if you’re planning on working for one of a handful of tech companies in the world. Keep in mind that age will catch up with you sooner or later, and competing with twenty something year old guys that have no family, commitments or a life for that matter, will prove to be incredibly difficult.
  • Business: alternatively, you can become more business minded, worrying less about the details of software and more about how to sell it or manage the people implementing it.

Not all software companies are in the software business

Many people have the misconception that a software business is purely about developing software i.e. that as long as code is being written that is valuable to someone else, then money can be made. This may be partly true, but it is a very narrow sort of view on what it takes to generate revenues.

The question of “what are we selling and when should we request payment?” determines the type of software business you are working for and/or managing. There are three main types of software businesses:

  1. Software as a means to an end: there are many businesses that dedicate the majority of their resources (money, people, time) to developing software but they do not directly generate money from the the software itself. Instead the software they develop is nothing more than a means to an end to support and/or automate their primary business, which may be anything from marketing/advertising, to selling physical products or perhaps managing logistics. The quality of the software produced by these companies has less impact on their profits than the primary service/products that they provide. Here’s a few examples of large corporations already doing this:
    1. Google may for example develop software as part of their business strategy, but they are primarily just an advertising agency and they just happened to have found a way to reach a wider audience by developing a search engine. More recently they have started making money on Google Apps but it pales in comparison to their revenues on advertising through their search engine. They have indeed developed Android, the most successful mobile OS (Operating System) in the world, but as far I know they make a minimal amount of profit on it, while Microsoft gain the majority of the profits which Google have to pay out to them for royalties. Customers that advertise on Google care less about the features Google provides than the ROI (Return On Investment) they get from advertising on their search engine. On the flip side, the people using the Google search engine do care about the quality of the search results, but those people are not paying to use the software.
    2. Facebook too is nothing more than an advertising agency that have just happened to find a different way of reaching a wider world wide audience. They do this by attracting people to a social networking website, keeping them engaged and gathering information about their interests (likes). Once again, the paying customers don’t care so much about the features available on the software, as long as their advertisements are reaching the target audience. Facebook is not exactly in the business of developing software as it is in the business of connecting people and feeding them targeted advertisements.
    3. Amazon for the most part is nothing more than a shop/store that happens to be online and they have thereby managed to automate the process of selling products to a wider world wide market. Only as of more recently have they started selling software products and services such as AWS (Amazon Web Services), but this is not their core business. Again, the features provided by the Amazon website have little to do with their customer satisfaction; their customers care about the products available on the website and how quickly those products can be delivered to them. Therefore Amazon is not so much  in the business of selling software as it is in the business of selling and delivering physical products.
    4. Uber is simply a company that acts as a middleman managing taxis. They may as well be a personal assistant that helps you coordinate the travelling via a taxi: contacting the taxi driver, telling you where to meet, keeping track of distances travelled and of course keeping track of the costs. They just happened to find a way of automating this whole administration head ache by developing software. The customers using Uber once again don’t care so much about the features on the software, as long as they get a taxi to take from the A to B at an affordable price.
    5. Apple: is in fact a hardware company that just happens to have developed their own operating systems and developer tools as a strategic way of improving and controlling the performance of their hardware and keeping their users within their ecosystem. The same applies to every other OEM (Original Equipment Manufacturer): they may have internal software engineers, but they are not on the frontline of what keeps the company going.
  2. Software Consulting: a consulting business charges for services rendered, meaning that you’re not selling software but rather your time, skills and effort. The consulting business is very much like prostitution: a salesperson (pimp) sells the services of software developers (prostitutes) to customers and theses services are billed by the hour. A software consulting business is not purely in the business of developing software, but rather in the business of providing services and adding value to customers.
  3. Product Development: traditionally software was regarded as any other engineering endeavour: we create a product, we sell as many units of it as we possibly can and make lots of money. Microsoft is a great example and the original company to have implemented this strategy.  These kinds of companies are the only companies that exist purely for the purpose of developing software. The challenge these companies have is that they will not be making any money until the first product is finished and ready to be shipped off. Therefore it requires massive funding and involves great amount of risk. With this approach, customers are purchasing the software products for no other reason than for the software itself and the features it provides. Therefore in order for such a company to survive it needs to provide finished software products that are of the highest quality and offer the largest amount of features.

The moral of the story is that the activities of a company do not always have a direct impact on the bottom line, and thus do not necessarily dictate the the kind of business that a company is in i.e. employees can be spending 90% of their time developing an advertising platform, but if the money is made from selling advertisements, then the company is not in the business of writing software, but in the business of selling advertisements.