Author: Paul Kolozsvari

Software engineer and consultant with 10+ years experience in the software industry. Worked at various kind of companies, from startups to multinational tech companies doing product development, consulting, sales, pre-sales, testing, project management etc.

Developing software to compete with established SAAS rental products

Posted on by Paul Kolozsvari in Business, Management, Sales, Software

Imagine you have have a customer/prospect that are already using an existing software product which they are renting from another software vendor through a SAAS (Software As Service Service) model. Now suppose that you want to develop your own new and improved version of your competitor’s product and sell it to your customer/prospect to replace what they’re currently using. An engineer’s first thoughts will be centred around what features can be developed to differentiate themselves from the competitor. Although this would be a good question, it shouldn’t be the main question because you have bigger problems than that:

  • Money constraints: the biggest problem you’ll have is funding, or the lack thereof. With your competitor already having an established SAAS business, they have a reasonably safe source of passive income to pay developers’ salaries and other costs, while you on the other hand have nothing i.e. at least not from the product you’re planning on developing. At this point you’re probably thinking that getting an investor would be the answer. However, here are the problems with investors:
    • Firstly: most investors will not give you any money unless you’re already making money. Most people invest in things that have a proven track record with an upward growth trajectory, not some airy-fairy idea that you came with up last Wednesday while in the shower.
    • Secondly: people understand that investing in a product that is in its infant stage carries a lot of risk. For that high level of risk, they expect a high level of return on their investment e.g. they want to see 50%, 100%, 200% (or more ) year-on-year growth, because otherwise they may as well invest their money in the stock exchange or put it in a savings account that has a small but guaranteed growth. What this means is that your product needs to have the potential to become a unicorn, not just an app that competes with an already established app. In other words, products aimed at catering to a niche market are basically out of the question.
    • Lastly, even if you manage to get an investor, it’s still not going to solve your time constraint problems.
  • Time constraints : you have to keep in mind that your competitor has already developed their product, while you have nothing to show except a presentation outlining some ideas. That means your competitor is already miles ahead of you. Before you can develop your fancy features that differentiate your product, you will need to still develop the basic core product which your competitor has already done. There’s a good chance that by the time you develop the core product, your competitor will have already developed the fancy features you’re planning on. In other words, you will always be several steps behind them. At this point you might think that you’ll just have to work harder and faster than your competitor. However, in most most cases the competitor has already spent years investing time, money, blood, sweat and tears into their product. Moreover, your competitor already has an established business with a stable cash flow and resources. So for you to think that you can simply work harder and faster to catch up to them would just be naive. I’m not saying it’s not possible, but just that your chances of success are drastically reduced i.e. you probably have a less than 10% chance of making it and I’m being very generous in saying that.

Given these constraints, how are you as David going to take down Goliath? A big established corporate may be slower than you because of bureaucracy, processes and procedures, but they have much bigger muscles. They just have to hit you once and you’ll go down, no matter how fast you think you are. In the story of David and Goliath, David wins the fight not because he was faster or stronger than Goliath, but because he identified Goliath’s weakness and changed the game. Instead of fighting in close combat which Goliath excelled at, David knew that Goliath had terrible eye sight. So he kept a safe distance from Goliath and used a slingshot to shoot a rock straight at Goliath’s forehead i.e. he changed the game.

In the same way, you will never be able to win against an established SAAS company if you take them head-on playing their game by their rules. You need to identify their weaknesses and use them to your advantage:

  • SAAS model weakness: in the case of a SAAS company their greatest weakness is their business model renting out the software instead of selling it as once off. Regardless of what the marketing machines around the world are spewing out, most people do not like the idea of renting products and therefore paying in perpetuity. Any person that thinks long term will prefer to own the products that they use, pay them off and never have to worry about payments again. The only reason the SAAS model exists is because the tech industry has realised that they can make a lot more money long term if they rent their products instead of selling them once off. SAAS is not for the benefit of the end-user or consumer, it’s for the benefit of the tech industry and developers that work in it. SAAS is basically a really good marketing scam.
  • Bloated product weakness: the other problem with established software products is that most of them are massively bloated with thousands of features that most people never use. All of those features are costed into the rental fee that their SAAS customers are paying for every month/year. That means that most customers are paying huge sums of rental fees for features that they never use. It’s like renting a mansion with ten rooms, but only using two of the rooms 99% of the time.
  • Lack of flexibility: one of the biggest problem in dealing with established out of the box products is the lack of flexibility. If the customer ever wants to a customisation to cater for their specific business needs, this will just not be possible. They have virtually no chance of convincing Goliath to change their product. The best the customer can do is voice their concerns and/or file a request for an additional feature in new release. If enough customers make the same request the software vendor may consider it and develop the feature in their upcoming release which may become available months or even years later. On the other hand, having software developed specifically for them allows the customer to be involved in the development process. They can submit a change control request to the developers and the feature can be available within days, or weeks

Knowing these weakness of most SAAS companies means that you can change the game by changing your business model. Instead of trying to develop and sell your product to your first customer under the SAAS model, you should offer services. You present your customer/prospect with the option of developing the software product by charging them for your development hours only, but promising that they’ll never have to pay any rental fees ever again i.e. they will own the software product once developed. The obvious issue here would then be the question of whether or not you’ll be able to resell the software to another customer. To get around this, you negotiate with your first customer for them to receive royal fees if you ever to resell the software to someone else. In other words, your first customer will also become your investor.

Using this method you can get your customer to pay for the development who will also have a vested interest in your product because they will not only get the benefit of using your product but also receive royalties for any sales you make in the future. Once you’ve gotten the product developed, you can then offer it to other customers on a SAAS model if you so wish. In summary, I believe with this strategy you can get your bread buttered on both sides i.e. get paid to develop a product as well as get paid after it’s been developed. I have personally executed and seen this strategy in action and therefore can vouch that it works.

Climbing software mountains with fake perfectionists

Posted on by Paul Kolozsvari in Business, Management, Philosophy, psychology, Sales, Software

Have you ever developed software for a client that constantly seems frustrated with the software you’re developing; someone that is continuously complaining and berating you for every little thing that isn’t perfect or throwing their toys out the cot whenever something doesn’t go according to plan? At first glance you might think that this person is a perfectionist with high standards, which in some cases may even be true. However, in my experience there are two kinds of perfectionists. The first type is the hands-on craftsman who is incredibly hard on himself, constantly finding flaws in his own work and continuously striving to improve the quality of what they’re building. This person may also be hard on their subordinates, criticising their flaws and setting high standards for them to meet. The second type is the one who never gets involved in the details nor does he do any of the work himself, but easily finds flaws in other people’s work and proudly proclaims to be a perfectionist. If you ever do come across a piece of their work you quickly realise that it’s anything but perfect. In other words, this second type is fake perfectionist. A fake perfectionist is someone who has high standards/expectations of other people without having a clue of what it actually takes to achieve those standards or meet those expectations i.e. a spectator who expects to see a lot of goals for the money they’ve paid to watch the game, but never having played the game themselves. In this post I’m going to discuss why these people are the way they are and how to go about mitigating some of the issues encountered when dealing with them.

Designing and developing software products is like any other endeavour; it requires a high level of skills, a lot of planning, hard work and continuous problem solving for an endless list of problems that need to be solved along the way. The end goal cannot be reached overnight and therefore also requires a high level of resilience and patience. The people undertaking these endeavours also need to be paid for their efforts which requires huge amounts of money to sustain the endeavour. There are two kinds of people in every endeavour: the people who get it done and the people who pay to get it done in the hope of getting a return on their investment i.e. the pot of gold at the end  of the rainbow. To use an analogy, you can think of these endeavours as climbing mountains. Lots of people want to get to the top of a mountain, but not many people do. The reasons for wanting to get to the top of the mountain is what differentiates the people who do versus the ones who don’t.  Some people want to get to the summit for the glory i.e. to be able to say that they’ve done it. Others only want to get to the top to see what the view is like from above. Some might even believe that there’s a pot of gold at the top of the mountain and therefore feel the urge to go after it. Unfortunately most of these people will never reach the top of the mountain without assistance and the reason for is is that they’re focused on the end goal without understanding what it takes to achieve it i.e. they see the summit of the mountain without seeing the actual mountain they would have to climb. On the other hand there are those that do make it to the summit. The difference with those that do make it to the summit is their genuine love for mountain climbing i.e. they’re in love with the process not with the end goal. Being in love with the process is what gives them the motivation and resilience to keep going despite the pain and struggles which they have to endure i.e. they are mentally prepared to endure the pain because they enjoy the process.

Using the mountain climbing analogy, you can think of the software developers as the mountain climbers and the business people as the ones paying them to help them get to the summit. The developers are the ones who are in love with process and all its struggles and obstacles while the business people are the ones who only want to get to the summit for the pot of gold and the glory. I thoroughly believe that this divergence in their way of thinking and feeling is the root of all conflicts and failed products or projects. Imagine a rich businessman that pays a mountain climber to help him get them to the top of a mountain. The mountain climber lays out the plans in terms of the route they will take, the weather that can be expected on each day, as well the equipment and other resources that will be needed. Unfortunately, things don’t always go according to plan in the real world. The one reason being that there are millions of variables to think about and even the best and most experienced mountain climbers will not be able to foresee every single point of failure beforehand i.e. they’re human after all. The other reason being that many of the factors that influence the success of the expedition are often outside the control of the mountain climbers e.g. the weather conditions could change, the equipment could break, a team member could get hurt, or perhaps one or more of the team members are not fit enough thereby slowing down the entire crew. Experienced mountain climbers have learnt over the years that anything that can go wrong will go wrong, and although they may not foresee every single problem that could arise they are prepared to deal with it as it comes i.e. these unforeseen problems will not deter them from the mission because they are mentally prepared for it and more importantly they enjoy the process. The rich business people on the other hand will throw their toys out the cot every time something doesn’t go according to plan. They will think to themselves, “What am I doing here, on this godforsaken mountain with these idiot mountain climbers who don’t seem to know what they are doing. Why was this issue not foreseen and planned for? What am I paying these people for? Why is it so cold on this mountain? Why am I in so much pain and why this so difficult? It should be easy, that’s what I’m paying them for.” The mountain climbers try to explain the challenges that are being presented and how they plan on getting around them. Unfortunately the business people couldn’t care less about the nitty gritty details. The simplest explanation for the business people feeling frustrated and not being interested in the details is because they just don’t enjoy the process. In fact most business people hate the process but they all want to reach the summit where the pot of gold awaits. They are the same people that are the fake perfectionists, that will endlessly bitch and moan about every little issue or discomfort. They are also the same people that will act like petulant children asking you every five minutes, “are we there yet, are we there yet?” They simply see the climbing as a means to an end, until one day someone comes along and offers them the option to take them take up to the summit in a helicopter, without any of the struggles or issues … even if that means splitting the gold with the helicopter pilot. The same thing goes for software development or any engineering endeavour; most business people hate the process and couldn’t care less about the details. They’re only enduring the pain and struggles because they don’t have any other options i.e. they want a custom product developed that doesn’t already exist on the market and they want to own the IP (Intellectual Property). Along the journey they will act like fake perfectionists by constantly bitching and moaning at every step without offering any solutions. Fake perfectionists are people that disguise themselves as perfectionists when in fact they have an intolerance for the process.

  • Negative consequences of working with/for fake perfectionists:
    • For starters, these sort of people can make your life a living level by creating problems for you instead of making the journey to the top easier.
    • Some of them might even look for imperfections in order to use them as excuses to not paying you for your work. For example if you’re billing the client on an hourly basis, these sort of tactics could include asking you to do bug fixing and ongoing support for free.
    • The worst case scenario is where they get offered an off-the-shelf product by another company, that promises to do everything your software does and more without of the hassle and inconvenience i.e. where the business people no longer have to worry about any technical details. What the business people don’t realise in these cases is that the off-the-shelf product took years to develop by this other company and in order for that company to make their money back they will have to charge hefty license fees. In the long term those license fees can end up costing a lot more than the development costs of the custom software. Not to mention that your client will not own any of the IP of the off-the-shelf product.
  • Ways to mitigate some of the negative consequences of working with fake perfectionists:
    • As with everything in life, the best way of avoiding conflicts and misunderstandings is to manage expectations. You need to make it crystal clear to every client right from the start of the project/endeavour what they will be getting themselves into. You can even use this mountain climbing analogy with them right from the start. Explain to them that this will be a long and difficult journey with lots of obstacles and challenges. You should go on to explain that one of your main responsibilities in this journey is to plan it out with the goal of mitigating risk, which is in fact the main responsibility of any software/solutions architect. However, you should mention that there will always be unforeseen circumstances and uncontrollable events that could occur and then follow up with few examples from your previous projects. Your intention should be to set out achievable but realistic goals. After having set the right expectations, you need to lastly ask for 100% commitment from the client i.e. are we going to do this through thick and thin or are you going to bail out at the first obstacle?
    • Before and throughout these projects you will find people having endless discussions and arguments about costing, timelines, deadlines and technical issues all in an effort to retain a client. However, you need to keep in mind that although you can have these back and forth discussions until the cows come home, they will have zero impact on whether or not your client enjoys the actual process of software development or not. It’s for this reason that you need to ensure that your process is an enjoyable one for the client. The simple rule of thumb for making a software development process enjoyable is to limit the number of surprises i.e. the less surprises there are the more enjoyable the process will be. This once again goes hand-in-hand with managing expectations.
    • As corny as it may sound, the last point I want to mention is that ultimately it comes down to how your client feels about the process of software development. Notice I used the word “feels” instead of “thinks” deliberately and it’s important to make that distinction because you can have all the intellectual discussions you want, but unless your client is in love with the process you are never really going to have their full commitment. That means that you have to change the way they feel about the process on an emotional level. This is obviously an incredibly difficult task because not all people have a technical aptitude. Here are a few tips for getting your client to fall in love with the process:
      • The best way do it is through enthusiasm and passion for your craft. If you’re oozing passion and enthusiasm for your work, it will rub off on your client, because enthusiasm is contagious.
      • Keep your client in the loop at all times in terms of what you’re currently working on, how it’s going, what you’re struggling with, how long it’s going to take, new ideas and recommendations you have etc. It’s also important for you to be completely transparent about everything. Do not hide information from your client regardless of whether it’s good or bad. Software development is like any other activity; the more involved you are in something the more interested and enthusiastic you will be about it e.g. the more news articles you read about politics, the more interested you’ll be in politics even though you have minimal influence over what happens to your country. The same thing  applies to watching a sport on TV; you’ll see people screaming and shouting at the TV because they want their team to score even though they have zero influence over it. You need to try and achieve the same thing with your client in terms of the software development process and you do that with constant feedback even if it means information overload for them. My preferred method of doing that is through email notifications sent out from my software as well as project management tools like Basecamp, Freedcamp and Microsoft Azure DevOps etc. I also make a point of ensuring that my clients have access to all the to-do lists, discussions, releases and the hundreds of email notifications from these tools. Some might say that email notifications and project management tools provide too much information for the client to process, but I beg to differ because you have to realise that ultimately you are competing for the client’s attention and attention to something equals interest which equals enthusiasm and a love for the process.

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

Posted on by Paul Kolozsvari in Business, Management, Philosophy, psychology, Sales, Software

Most people in 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 eternity. The 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 bringing 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 therefore 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?

Posted on by Paul Kolozsvari in Business, Management, Philosophy, psychology, Sales

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 imagine 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 about the profits being 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 an understanding of 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 anything 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 disastrous 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 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

Posted on by Paul Kolozsvari in Business, Management, Sales, Software

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:

Pros and cons of working from home

Posted on by Paul Kolozsvari in Business, Management, psychology

There’s always been a lot of debate around the idea of working from home (for those who can) vs going into the office every day. Some people strongly believe that working from home is a lot more productive while others (mostly managers) believe that to be nonsense. Having done both for many years, I think there are a number of variables to consider in this debate. In other words, it depends. So here are a few practical advantages and disadvantages of working from home.

  • Advantages of working from home:
    • Save time and money on travelling: this is obviously the most common argument for working from home. It means no longer having to waste valuable hours of your of your life sitting in traffic and wasting money on petrol and trains tickets. It means having extra time to work when under tight deadlines or using that time for leisure or spending it with your family.
    • Save money on food: most companies do not offer free food in their offices and therefore people are often forced to buy their lunch at cafes and/or restaurants close to the office. Since a lot of these offices are located in affluent areas, the prices of food in those areas can be considerably higher than making your own food at home. Of course there is the option of packing your own lunch, but in the rush of getting to work or perhaps for the sake of convenience, many people still purchase their lunch at places close to the office.
    • Fewer interruptions: when you’re at home you don’t have people unexpectedly dropping by your desk to ask you questions or starting up random conversations. Having less interruptions means it’s easier to focus and get into “the zone” when trying to work.
    • Less background noise: most company offices nowadays are open plan generating a large amount of noise, with people chatting, telephones ringing off the hook all day and sometimes even having workers drilling and bashing down walls in the office. Again, working at home in a quiet environment allows you to get into the zone more easily.
    • Removes the need to clock in: depending your job’s requirements to communicate with other people, working from home largely means having the freedom to decide on your own daily schedule and routine. As long as you get the job done and achieve the set out goals within the scheduled timelines nobody will really be bothered too much about what time you start and end your day. Early birds can wake up at 5am and finish their work early, while night owls can sleep in and work later at night.
    • Saving time on running errands: since most people work in offices from 8-5pm, they inevitable have to schedule their errands during the weekend where possible. For example, going to the bank, renewing drivers’ licenses, sorting out bills with the municipal etc. Some of these errands can indeed be accomplished during the weekend, but since everyone is that during the weekend, it means spending your Saturdays mornings in long queues of people. Some errands cannot even be done during the weekend, meaning that you have to take time off from work during the week. When working from home, you can easily pop into the bank without having to sit in the queue. You can then easily make up that time at night or during the weekend. In the grand scheme of things you end up saving a lot of valuable time.
    • Work in your preferred environment: working in a company office means being forced to use the provided company facilities whether you like them or not. Everyone gets the same kind of table and chair, gets told where to sit and and in some places people work there for decades before they get a seat by the window or a corner office. Furthermore, many offices have very little natural lighting, with workers being forced into cubicles where they never see the light of day. Air conditioning is another issue where everyone is forced to work at the same temperature; if it’s too hot or too cold for you, you need to become a politician to convince others to change the temperature. Working from home on the other hand, means having the freedom to chose which room you want to designate as your office, the lighting and temperature conditions as well as the desk and chair you prefer to use. The work environment and ergonomics are on your own terms.
    • Reducing contact with people you don’t get along with at work: maybe you’re lucky and you work in one of those companies filled with only nice people and you all get along fabulously. However, for a lot of people that’s not always the case and unfortunately we sometimes have to endure having to work with people we don’t like. We’ve all known someone at some point in our careers that we didn’t get along with. Working from home gives you the ability to reduce the amount time spent with those people. This can go a long way towards improving and maintaining your mental health.
    • No office politics, rumours and gossip to worry about: even if you do get along with people in the office, there will alway be rumours and gossip in any office that you work in. Working from home means not having to waste time dealing with any of it. It means no longer having to worry about rumours and gossip of people getting retrenched, promoted, rewarded, complimented or reprimanded. Instead you can use all your mental energy on your work, instead of wasting it on things that you cannot change.
    • Living in larger properties: most company offices are located in central business districts in the heart of major cities. Due to the high demand for property in those areas, workers are often forced into paying exorbitant amounts of money to live in smaller properties closer to work. Being able to work from home on the other hand means being able to live in cheaper and larger properties further away from the city, without having to worry about additional time and costs of travel.
    • Access to larger pools of talent: due to location and distance constraints most companies have had little choice but to hire people in areas that are in close proximity to their offices. Allowing people to work from home on the other hand, removes that constraint giving companies access to a larger pool of talent.
  • Disadvantages of working from home:
    • Cabin fever: many people who have never worked from home underestimate the notion of cabin fever. They don’t see it as something that could happen to them, but rather as something that happens to a few extroverts. Unfortunately that is not the case and can happen to almost anybody especially to those that live alone. Human beings are social creatures and are not meant to be living out their lives alone. There is a reason that solitary confinement is used a punishment for prisoners that misbehave in prisons.
    • Temptations to not work: as mentioned above, there may very well be less interruptions from other people when working from home, but there is also something to be said about temptations. Interruptions are caused by other people, while the temptations at home are those that get you to do anything other than work. Since you don’t have anyone looking over your shoulder at home, it’s easy to be distracted and lose countless amounts of time browsing through your social networks, watching TV/Youtube, reading the news etc. All of these distractions will suck the energy out of you, leaving you unmotivated and struggling to concentrate.
    • Home duties/responsibilities: there are numerous responsibilities you may have at home, which you wouldn’t normally have have to worry about during a regular work day at the office. These  include washing your coffee cup and dishes, vacuum cleaning, doing the laundry etc. You may also be tempted to save costs by no longer paying for child care and instead taking care of the kids yourself since you’re at home the whole day. All of these responsibilities at home will strip away your ability to focus on your work.
    • Additional costs at home: while you may be saving on travel costs, working from home doesn’t come without other costs. Your water and electricity bill will be higher since you don’t have your company paying for those costs any longer. Since most companies offer free coffee in their offices, this is yet another benefit saving you’ll have to forfeit when working from home.
    • Lack of social pressure: many of us believe that we are self motivated and do not need any external pressure from others in order to motivate us to do our work i.e. I mean we’re adults after all. However the truth is that most people compare themselves with others and even if we don’t, having other people waiting on our results or pushing us to achieve our goals has an immense impact on our motivation levels. The fact that nobody in the history of the world has ever started a new company by themselves is testament to the fact that none of us are completely immune to the effects of social pressure.
    • Lack of team cohesion and culture: there are numerous chat, project management and conference call tools available that we can use to facilitate communication between coworkers. However, the problem with remote correspondence is that it’s only ever done when it’s necessary i.e. conference calls and chats are only initiated when we need to discuss work related tasks. Some people may think that’s a good thing since it prevents wasting time on small-talk. Personally, I beg to differ. In this kind of remote work setup, you can work from home for years with other coworkers, and not ever share a single joke or know a single personal thing about them i.e. what their likes and dislikes are, what personal struggles they’re going through, what ticks them off or what motivates them. One might say that all of that is irrelevant but I don’t believe that because ultimately we are working with other humans not robots. Therefore it is important to understand that all people have emotions, worries and aspirations, none of which you will ever be aware of without the daily/weekly lunch breaks, smoke breaks and water cooler talks. All you have to do is watch any one of the hundreds of movies about team sports to understand the impact that team cohesion has on performance. The emotional connections and knowledge we have about or colleagues may be intangible but that does not mean that it has no impact on team performance. Managers should especially be concerned about these aspects when managing remote workers.
    • Integrating new staff is difficult: some companies that switch over to a work from home policy may not immediately pick up the issues mentioned above especially related to team cohesion and this is because they already know each other within the team and the company’s culture. The problem arises when new people get hired and they struggle to adapt to the company culture, simply because company culture is almost invisible when working from home.
    • Coaching junior staff is difficult: things get even worse when you have new junior staff that need coaching, training, and hand-holding. It becomes very difficult if not impossible to do all those things while working remotely.
    • Barriers to asking for help and sharing or discussing ideas: while the most talented, experienced and skilled workers may feel that they don’t need help from anybody, the truth is that nobody is an island. At some point or another we all get stuck with some issues and it always helps when you can ask for help from someone that’s sitting a few meters away. Working from home imposes some  barriers to that approach since you cannot see what the other person is busy with and therefore have to resort to scheduling a conference call. This somehow almost always feels a less casual. Brainstorming sessions will also not be the same through remote correspondence, that’s if they even happen at all. The truth is that most creative ideas do not come about in formalised meetings that are scheduled in one hour intervals, but rather in casual and impromptu chats.
    • Transparency and visibility between colleagues is lost: when working in a company office setting, you can always see who is at work and whether they’re busy or not. Remote working does not offer that visibility i.e. you have no idea what your coworkers are busy with or if they’re busy at all. So when you ask someone for assistance or to attend a meeting and they tell you they can’t because they’re “so busy”, they could very well be busy watching TV and you won’t know any better. From my own personal experience I can tell you that the “busiest” people that never seem to have the time to help are always the ones that work from home, while the ones working at the office always somehow manage to find the time to help.

Keeping all of the above in mind, you may still be wondering whether a work from home policy should be put in place or not. In my personal opinion, I don’t think a work from home policy is a good idea in general. In a perfect world, I think every company should aim to get workers to come into the office at least 80% of the time i.e. allowing a one day per week to work from home which they can use at their discretion when they want to take advantage of any of the above mentioned benefits of working from home. Having said that, I do concede that it is not a perfect world, and exceptions should be made. For example you may have a valuable employee that lives three hours away from the office, and having that employee spend six hours of their day travelling would be ridiculous and you could end up losing that employee purely for that reason.

N.B. although I mentioned all of the above practical pros and cons of working from home I do want to offer a word of caution especially to managers that are weighing up their options. At the risk of sounding negative, I’m going to go out on limb here and say that a lot of the debates that happen are often superficial, with productivity and the like being brought into the debate as shallow excuses to circumvent other underlying issues within the office culture. I am not saying that this is always the case, but I do believe a some of the debates are not so much about productivity, travel time and costs, but rather about exercising control and being controlled i.e. some managers feel they lose control by allowing people to work from home while workers want to avoid being controlled by working from home. It is very sad when this happens as it can point to underlying issues that are never brought to light and never dealt with. Some of these issues can point to a depletion of trust between employees and managers or even abuse of power. Therefore I would advise that when an employee requests to be allowed to work from home, you should listen very carefully to their reasoning and determine whether their request does indeed have practical merit or not. If their reasoning sounds superficial you should dig a little deeper to determine the underlying reasons for them wanting to work from home. Could it be that the office equipment are inadequate, or perhaps they want to distance themselves from the work environment, another colleague, or even distance themselves from the manager? If that is the case, you should try your utmost best to improve whatever conditions they’re trying to run away from. Conversely, if you are very opposed to the the idea of work from home, you need to ask yourself whether your argument against it does indeed have real practical reasons for it, or whether your reasons are simply superficial excuses for not wanting to relinquish control over your employees. In other words, are you being a control freak?

In conclusion, my overall view on this topic is that managers should put in every effort to make the workplace as comfortable and as work friendly as possible while considering full-time work from home policies only as exceptions where there are valid practical reasons to justify it.

Why bother writing functional/technical specs when developing software?

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Software

Maybe it’s just my personal experience, but I have only ever worked for one company that actively committed to writing functional and/or technical specs when developing software. Chances are that you’ve probably had the same experience in your career and perhaps you might even be anti documentation altogether. Personally I don’t think there’s anything wrong with coding without a spec if you’re working on your own pet project in your spare time, but on the other hand I’m a strong believer in writing a spec for formal projects. So before I begin making my case, let’s just quickly define what a formal project is vs just a hobby or pet project.

  • Formal project: A formal project differs from a pet project in the following ways.
    • Money: You’re getting paid to develop the software.
    • People: You’re not working by yourself, but in a team with other developers, managers, project owner and customer/s.

I’m going to use an analogy to make my point: developing software without a spec is like travelling from Cape Town to Cairo (10 134.8 km)  without a map. Instead of spending some time looking at the map and planning out your trip before leaving, many people are under the impression that the time spent planning is better spent travelling. This theory would work well if the road between Cape Town and Cairo is a straight line, but unfortunately it is not. Along the way there will be thousands of decisions that will need to be made. Without a plan you will take many wrong turns costing you a countless number of hours. If you had planned out your trip, you would know exactly which turn to take before you even arrive at an intersection.

  • Benefits of writing a spec: Here are the main reasons for why you should be writing a spec:
    • Managing budget and timelines: If you’re winging it without a plan you will never be able answer questions in terms of how far you are from the destination or how much more petrol money you’ll need. In the software world this translates to not being able to answer the customer when they ask how far you are and how much it will cost to deliver the software solution.
    • Avoiding scope creep: managing the scope of a project us really nothing more than managing the customer or project owner’s expectations. The spec serves as the scope definition and without a scope you will experience scope creep where the customer gets more than what they’ve paid for, while you and your team will suffer financial losses or at the very least negative cash flow. Aside from the financial implications, not managing the customers expectations and scope of a project, also results in chaos and stress, which obviously nobody enjoys.

Imagining people reading this, I can just hear the millions of excuses for not wanting to write a spec or any sort documentation. So below is a list of common excuses I’ve heard for not wanting to write a spec, and a counterargument for each.

  • “I don’t have anything against writing specs, but I see it as a luxury not a must-have. Unfortunately, I don’t have the time to write a spec because we’re running against a tight deadline.”
    • Counterargument: Continuing with our Cape Town to Cairo analogy, in the software world, the spec is your map which you can use as a reference on your trip to software excellence. For this reason, an hour spent planning your trip will spare you taking hundreds of wrong turns, and therefore of will save you days on your travels.
  • “Writing a spec is only useful when your developers are monkeys i.e. where you need to explain every little thing to them in detail. My developers and I are all very intelligent. Hence, we’ll just figure things out as we go along because we don’t need anyone else telling us what to do”.
    • Counter argument: This argument is essentially saying that we’ll just wing it. Continuing with the above analogy on travelling from Cape Town to Cairo, this false argument is equivalent to saying that you don’t see the point of planning your trip because Cairo is North of Cape Town and therefore you just need to head North and you’ll figure out the rest as you go along. Again the problem with this strategy (or lack thereof), is that it doesn’t matter how smart you are since you still don’t know what you don’t know i.e. even if you’re heading North, you won’t know what to do when you hit a T-junction. Instead you’ll rely on luck going either left or right and just hope that there will be another road somewhere that will get you back on track towards the North.
  • “A spec is just a piece of paper/document, it doesn’t actually do anything. Aside from using it as toilet paper, it has no other uses. Therefore it adds no value to the project.”
    • Counterargument: A spec is not just a piece of paper/document, it is a contract between you and the people you’re developing the software for. The objective of the contract is to manage expectations in terms of what the customer is paying for vs what is being delivered. You cannot meet expectations if you don’t know what those expectations are and failing to meet expectations leads to failed projects, negative cash flows and perhaps even your company closing down.
  • “I’m a creative type and therefore don’t like being constrained by a spec that forces me to develop the software in a specific way. Instead I like to think out of the box and prefer having the freedom to come up with more innovative ways of doing things on the fly.”
    • Counterargument: this one really comes down to your level of technical skills and knowledge i.e. whether you’re a junior or senior developer.
      • Junior Developer: If you’re a junior developer then chances are that you not quite read to make design level decisions on software that falls in line with the customer’s requirements. In such cases it would be better for a senior developer/analyst to write up the spec and for you to follow it religiously. If you feel that you can contribute with alternative solutions, you should make the suggestions to the senior that wrote the spec. At this point, the merits of your alternative approach should be discussed in an open minded fashion where you are taken seriously. If you can prove based on facts that your solution is a better one, then your solution should in fact be implemented. Otherwise the senior developer should provide you with a solid fact based explanation as to why your solution would not work in the given context.
      • Senior Developer: If you’re a senior developer and feel that you’re constrained by the spec given to you, then you should bring your suggestions to the analyst/developer that wrote the spec. Better yet, if you feel that you are capable of it, then you should probably be the one writing the spec. Reason being that having a single person designing and developing a system is a lot more productive that splitting the tasks between multiple people. This avoids having too many cooks in the kitchen. Either way, being the creative and agile type is not an excuse for not designing the software and thereby writing a spec before coding.
  • “The person writing the spec is only a systems/business analyst with limited technical knowledge of how software is actually developed. That means that their spec will be inaccurate and the software that I develop won’t match the spec anyway. So what’s the point of having a spec written anyway?”
    • Counterargument: This is a very valid point and I have in fact seen this scenario play out several times throughout my career. The solution to this problem can be solved in one of several ways:
      • Teach the analyst: Spend some time explaining what can and cannot be done and just generally bringing them up to speed on the process of software development. This simply comes down to managing expectations, not only between you and the analyst but between the analyst and the customer/end user. Educating the analyst is key for managing this scenario. Of course there are many cases where certain types of people are not open to learning or are simply too arrogant to accept help or advice.
      • Find another analyst: If you have no luck in teaching the analyst, you probably have no voice but to find another more competent analyst. Due to politics and also not wanting to hurt people’s feelings, this could end up being easier said than done. However, provided that you have tried everything in your power to remedy the situation, you will be left with no other alternative but to find a replacement.
      • Do it yourself: In many cases, simply replacing the analyst is not always possible, such as in cases where they are your boss or perhaps due to politics. In such cases, it’s best that you take over the design work by writing the spec yourself. Don’t bother asking for permission, just get it done as it’s easier to ask for forgiveness than to ask for permission. If you  delivery the solution successfully, you probably won’t have to ask for forgiveness anyway. The bottom line here is that whichever way you end up doing it, you still don’t have an excuse for not working with a spec.
  • “Documentation is for business people. I’m a technical person and I just don’t enjoy reading or writing documentation. For me the code is the documentation. If anybody wants to understand what the software does and how it does it, they just need to read through my code.”
    • Counterargument: It’s all good and great to say that you understand what the software does by reading the code, but what about the business people that cannot read code, how will they understand what the software does or is supposed to do? Furthermore, think about how long it will take another developer to reverse engineer the business logic out of the code. The point being that you have to think about more than just yourself, and instead keep the whole team in mind. This is a prime example as to why people still pay for software instead of using open-source because most open-source project lack documentation i.e. it’s all good and great to get free open-source software, but it turns out to be pretty useless if you don’t know what it does, how to use it and/or troubleshoot and fix it when necessary.
  • “It’s better to write unit tests for defining and validating requirements. Writing unit tests serves the same purpose as writing a spec by forcing you to think abut the requirements. Furthermore, it has the additional benefit of enabling you to also test your code, which is something that a spec cannot do.”
    • Counterargument: This is a comparison between apples and oranges. Unit tests and documentation are two separate things which serve a different purpose. This is the exact same false argument as the one above which implies that unit tests, which are in fact code, serve as documentation. Once again the rebuke on this argument is that code is not documentation since it’s incredibly difficult to reverse engineer business rules out of code.
  • “Nobody ever reads specs anyway.“
    • Counterargument: This is a people problem not a technical problem and therefore the people need to be dealt with. The easiest way to deal with people that don’t read the spec is to simply reply to their questions by saying “Check the spec, on page X” or even just “RTFM”. Sooner or later those people will take the hint. The moral of the story is that you need to teach people how to treat you which is to respect the time and effort you’ve put into writing the spec.
  • “Even if specs get written, nobody ever updates them, which renders them useless in the long run.”
    • Counterargument: Firstly, who’s fault is it that the spec doesn’t get updated? This argument is equivalent to saying that you won’t take a shower every day because you’re just going to be dirty the next day anyway. That is obviously nonsense and once again this is a people problem not a technical problem. The simplest solution is to become disciplined by getting into the habit of updating documentation on a regular basic.
  • “Working with a spec would make us too rigid, and requirements change anyway. Hence we prefer using XP and/or Scrum to manage requirements which allows us to be more agile.”
    • Counterargument: Yes, it’s true that requirements change, but regardless of whether they change or not you will still need to define the the scope of the project. Changes can still be handled in an agile way by using Change Requests which can be filed when new requirements are introduced. What’s important to remember, regardless of what methodology you chose to use, is that no customer or company that you work for will ever give you a blank cheque to spend countless number of hours developing software with no end in sight. Therefore wanting to be agile is no excuse for a lack of documentation and design.
  • “The software we’re developing is really large, will take a really long time to develop and as such it is not possible for us to design and document every little feature months or years ahead of time, due to the fact that things will change in the future.”
    • Counterargument: again is the same argument as the one above in terms of looking for flexibility and agility. Indeed it is a valid argument that one cannot predict what will happen months or years in advance. However, you should be able to predict what will and should happen a month or two in advance. I’m not saying that you should write a ten thousand page spec for the development of a two year long project/product. There’s nothing stopping you from breaking down the software into features that should be delivered in the next month or two and then further breaking it down into weekly XP sprints. However, you should write a spec for each software component/feature that you plan on delivering. In other words instead of writing a spec for a complete product that will take two years to be developed, you should write a spec for the first few features that will take two months to be developed. Thereafter the documentation can be updated with the next set of features that are planned for the next two months, thus enabling the documentation to grow and adapt organically as the code does. The point being that the documentation can adapt to changes just as the code does, but the spec and design for each feature should still be completed before any code is written.

In summary, I’m going to throw the age old proverb at you by saying that “if you fail to plan, you plan to fail“. When all is said and done, it really is that simple and there really are no excuses for not writing a spec when working on a formal project or product.

What to look for when hiring a software developer

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Software

Like most people that have been in the industry for a number of years, I’ve been on both ends of the hiring process; both interviewing candidates and being interviewed. Conducting an interview and deciding which candidates to hire is incredibly difficult because there are a multitude of red and green flags to look out for. Hiring a software developer is even more difficult mainly because so much of the value that a developer provides is intangible i.e. their talent and personality are difficult to measure.

There have been cases where I’ve sat on interview panels, where we all thought the candidate was fantastic, but proved to be a nightmare to work with once hired. Obviously a similar situation arises when choosing which company to work for, but that’s a subject for another chapter. Here I’ll cover a few mistakes that I’ve noticed being made during interviews, as well as a few things you should be looking for when hiring.

  • Mistakes in interview process: here are a few mistakes I’ve seen companies make in the interview process.
    • Technical assessment before culture fit/personality interview: as far as I’m concerned, testing someone’s technical abilities before getting to know them is like having sex with someone before even talking to them. Some people might be fine with that but I believe that it might set off a red flag to some candidates and as a result you might lose a few talented ones that could have otherwise been great for the job. As a candidate, this approach would tell me that the company doesn’t care whether they’re hiring Mother Teresa or Adolf Hitler as long as they can get the job done. Chances are that a company like that will already have a few Adolf Hitlers roaming around, and that’s not an environment I would personally work in. Some companies might defend their position by saying that they will still have the culture fit interview after the technical assessment, and they’re choosing this approach in order prevent wasting time on people that are not technically competent. That’s fair enough, but at the same time it clearly exhibits the company’s priorities and as a result some candidates will feel that in a company like that they will be treated as disposable “resources”.
    • Theory based technical assessments: I’ve seen software developers (and people in general) that are exceptional at learning theory but are useless at putting it into practice. People that are great at memorising large amounts of theory might excel in some professions like law and maybe even medicine, but software development is not one of those professions. For example, I could take a programming book on C# for instance and give it someone asking them to read through the entire book, perform all the exercises and learn the C# syntax. I could thereafter give the same person a test asking them to write an if statement, while loop, create a class, name all the different accessibility modifiers, tell me the difference between an interface and an abstract class etc. Having read and memorised the book, the person will pass the test with flying colours even though they’ve never developed a complete app in their entire life. When hiring a software developer you shouldn’t be looking for someone that can talk about software, but rather  someone that can actually develop software. Moreover, software development is more than just hacking a few hundred lines of code together, instead it’s about developing complete applications that could require thousands of lines of code.  Hiring someone simply because they have the knowledge means nothing if they can’t actually put it into practice.
    • Skills based technical assessments: the company may be missing out on some really talented candidates if they’re filtering out candidates simply based on a specific skillset. For example, you could have a candidate that’s a genius but they’ve never worked with a specific technology used in the technical assessment. As a result the candidate will be filtered out without being given the opportunity to impress you with their other abilities. For example you could have a software developer that is brilliant at C++ but the interview is for a Java development position. Obviously hiring this candidate will involve a learning curve, but if they’re talented they will learn the Java development stack and become productive relatively quickly. On the other hand if you have a candidate that is an average or poor developer and only knows Java, he/she may be hit the ground running almost immediately but will never learn anything new and the Java code he/she writes will be terrible.
  • What to look for in a personality interview: knowledge and skills in a specific domain are obviously important and useful for a candidate to hit the ground running. I would definitely look for skills when hiring a contractor for a certain timeframe on a given project. However, when looking to hire someone permanently you are effectively making an investment in this person and expecting to get a return on that investment. If you’re only looking for a specific a skillset the person may deliver on a given project but may not necessarily deliver on the next project if a different skillset is required. For this reason I find it futile to hire people for specific skills and knowledge. More importantly knowledge and skills can be learnt by pointing them in the right direction, giving them a book to read, sending them for training, or even sitting down and teaching them personally. However, there are a few things that you cannot teach or change about a person and so these are some of the attributes I like to look for before I even think about doing a technical assessment:
    • Personality: when given the choice between working with a highly talented asshole versus working with a nice guy that needs a bit of training, I would chose the nice guy over the asshole every time. The reason being that you can teach skills but you can’t change an asshole. It’s that simple.
      • Test: This is obviously something that is very difficult to test, but through experience in dealing with people you can get a pretty good idea of the kind of person you’re dealing with by simply having a casual chat and asking about specific cases in which they dealt with conflicts in the workplace and how they handled it. If budget allows, you could even ask them to complete an aptitude test with a qualified psychologist.
    • Analytical: a person can have all the knowledge in the world but if they are not able to logically analyse a problem, troubleshoot and come up with solutions, they will never make it as a software developer. Being analytical is something you’re born with; you either have it or you don’t.
      • Test: The first thing I look at are their exam results from school and/or university, specifically on subjects that required logic reasoning. I wouldn’t care too much about their test results on theory based subjects such as Geography, History or even certain IT related subjects like Databases, Operating Systems, Networks etc. Instead I would specifically look at their results for Maths, Physics, Programming and other subjects that required solving equations like Electrical Engineering, Electronics, Digital Systems etc. If I had to chose between a candidate that had below average school results with two years experience in C# versus a guy that has never written code in his life, but was an A student in Electrical Engineering, it would be a no brainer i.e. I would hire the Electrical Engineer to work as a Software Developer. The reason being that Electrical Engineering is an incredibly tough course and completing it with As tells me beyond a shadow of a doubt that the he/she could learn to code relatively quickly and will deliver excellent results.
    • Inquisitive: in the world of software and technology things move very fast, with new technologies popping up every day. It’s obviously impossible for a software developer to know everything, but what you should be looking for is a candidate that is inquisitive and enjoys learning new things all the time i.e. as opposed to someone that sees learning as a burden/work.
      • Test: if you do a bit of research you will find that there are various ways of assessing whether someone is curious or not. The easiest way is to ask them at the end of the interview whether they have any questions for you. People that are inquisitive will ask a lot of questions, while others might only ask one or two questions just to show interest.
    • Quality of work: there are certain jobs that require people to complete a set of tasks to be productive. Some examples include a warehouse worker who moves boxes around the warehouse, a driver who has to do deliveries, a cashier in a store, an accountant who needs to process salaries, or even a businessman/salesman who needs to make X number of calls per day, close deals and reach a target by the end of the quarter. What all of these jobs have in common is that it doesn’t matter how the job gets done as long as it gets done. Software development and engineering in general is not one of these jobs. As an engineer you are not just performing a list of tasks, but creating products. The products created will be used by endusers who expect and are willing to pay for a certain level of quality. Therefore how you do the job and the quality of your work is not just important but critical. Obviously there are times when engineers work under financial constraints which limit the time required to achieve excellence. Nevertheless, you should look for candidates have some of the following attributes, which I believe makes them produce quality work:
      • Pride: nothing irritates me more than an engineer that has an “it’ll do” or “it’s good enough” attitude. When you’re creating products “it’ll do” is just not good enough. There is no substitute for people that put pride in their work and that’s not something you can teach i.e. you’re either born with it or you’re not.
        • Test:
          • Ownership: a simple telltale sign that someone puts pride in their work is to ask the candidate how they feel about code sharing i.e. someone taking over their code and/or modifying it. People who put pride in their work take ownership and accountability for their work, and generally have an emotional attachment to what they produce i.e. it’s like their baby. Having someone come in and take over and/or “damage” their “work of art” infuriates people that take pride in their work. People that do not take pride in their work are quite happy to let someone else deal with their mess. I know that many managers actively encourage code sharing in their teams mainly because they see the developers as just “resources” which they allocate to projects and codebases. I think that’s a terrible mistake on the manager’s part because it discourages ownership, accountability and above all reduces the quality of the code.
          • Neat & tidy: I’ve seen software developers in interviews that are incredibly bright, knowledgeable, confident, well spoken etc. But when you look at their code it looks worse than a dog’s breakfast. They simply don’t care how the code looks, they only care whether it works or not. If these people leave their job and someone else needs to takeover their codebase it will be a nightmare for the next developer who needs to deal with the mess. The only way to test for this attribute is to look through some of their existing code.
        • Eye for detail: a software developer that doesn’t have an eye for detail is like a blind sniper i.e. they will create a ton of bugs and produce shockingly bad quality software. You cannot teach someone to have an eye for detail so don’t bother hiring such a candidate into a developer position. You could instead put them in a support role.
          • Test:
            • Present a vague problem: the easiest way to test for this attribute is to verbally present the candidate with a feature request or a problem to be solved. They need to provide you with a solution of how they would solve the problem. Your description of the feature/problem needs to be quite vague with limited context. Ensure that you provide at least some sort of context. A candidate that has an “eye for detail” or detailed oriented will begin by drilling down into the problem asking you a million questions for clarification. You should obviously be prepared to provide those details. Pay careful attention to the level of detail they provide when proposing the solution. Give them the opportunity to write down the proposal since most people cannot present a long but structured solution verbally. A candidate that doesn’t ask for a lot of details will not able to provide details in their proposal, and will obviously only reply with vague solutions to your problem.
            • Email exchange: if working through a recruitment agent, you may not always have the opportunity to exchange emails with candidates. If however you do have a few email exchanges, pay careful attention to the length of their emails and the level of detail they provide in their replies. In my experience, people that write long winded but coherent emails are generally very detail oriented. Obviously it depends on the subject of your emails, therefore try and ask some detailed questions, which would required detailed responses. People that consistently reply with a single sentence to your emails are not detail oriented and probably never will be.
  • Technical assessment: once the candidate has passed a personality interview and you’re happy to take it further, you can then conduct a technical assessment. As mentioned previously I’m not a fan of theory and/or specific skills based interviews. Here are some of the best approaches I’ve seen in technical assessments.
    • Develop an app: a great option is to give the candidate a set of requirements to develop a full application. It doesn’t need to be anything complicated or incredibly time consuming, but it should require them to spend a few or more hours writing enough code that you can see their coding habits. The requirements must be such that it will require writing more than just a single function or algorithm. Also do not force them into writing in a specific programming language or technology stack, since you want to them to use whatever they feel most comfortable with, which will enable them to showcase their skills as opposed to have to learn a new language just to complete the assessment. The requirements for the app should also not be too constraining since you’ll want to give the candidate the opportunity to demonstrate their creativity. Since this exercise might take more than an hour or two, you can let the person develop the app in their own time and submit it when they’re done, which could be even a week later. To ensure that they did in fact write the code themselves without help from others, you could ask them to come back for code review.
    • Code review: the easiest way to ensure someone can actually code is to look at their code. One option is ask them to develop an application as mentioned above and then do a code review on that. However that can prove to be very time consuming for both you and the candidate, especially if you’re interviewing multiple candidates at the same time. An easier method could be to ask the candidate to take you through one of their existing code bases. Some candidates will say that their code is owned by their current or previous employers and cannot be shared with you. If that’s the case, don’t bother hiring the person because any developer worth his salt will have their own code that they work on in their spare time. Once they have agreed to show you their code, you could of course just look through it by yourself, but to ensure that it was written by the candidate and not someone else, it would be wise to have a code review either face-to-face or via a conference call. Ask them as many questions as you can, paying careful attention to how they’ve structured their code, whether it’s object oriented or procedural, the design patterns used (if any), whether it’s neat and tidy, easy or difficult to read, and ask them specifically about which parts of the code they struggled with the most.
    • Pair Programming: there’s a quote attributed to Plato where he said that “You can discover more about a person in an hour of play than a year of conversation.” I wholeheartedly believe in this. The quickest way to get to know a person is by working with them as opposed to just talking to them. The surest way of seeing the how someone works is to work with them even for just an hour or two. Give them a problem to solve or a feature to develop and then sit with them working through the problem together. You will immediately see their personality coming to light as well as their many other attributes such as troubleshooting and communication skills, work ethic, perseverance and ability to come up with new ideas. In the process, the candidate will also have the opportunity to learn something about you and what it would be like to have you as a colleague and/or manager. In the end if you extend the job offer and they accept, you’ll know that the decision was based truth and not merely on perceptions you have of one another.

In summary, you should always aim to hire software developers for talent and train for skills as well as paying careful attention to personalities.

How do I manage Computer Rage?

Posted on by Paul Kolozsvari in Management, psychology, Software

Before we get into this topic let’s first establish what Computer Rage is exactly. It’s essentially anger that turns into uncontrollable rage over a malfunctioning computer or any other electronic devices . This results in people verbally or even physically abusing a computer. According to Wikipedia article (and many other sources which can be verified with a quick search on the Internet): “In 2009, a survey was conducted with British computer users about their experiences with computers. This survey found that 54% of respondents reported verbally abusing their computers, and 40% reported that they had become physically violent toward their computers. The survey also found that most users experienced computer rage three to four times a month“.

This may be bit of a sensitive topic for some, but if you’re planning on a long and prosperous career in the software industry or any other industry that requires you to use a computer on a daily basis, you or someone you know will at some point experience Computer Rage. Hence it’s probably a good idea to give it some thought and if you’ve ever experienced it, it’s an even better idea to try and manage it for your own mental health and those around you.

If you were to to go according to pop psychology, you would think that any one experiencing Computer Rage is a psychopath that treats other people in the same way that they would treat a computer when experiencing Computer Rage. Pop psychology even tells us that before dating someone you should first see how they react to working with a non-functioning computer or a slow internet connection. Personally I don’t believe that you have to be a psychopath to experience Computer Rage. Based on the above statistics, I cannot believe that 54% of British computer users are all psychopaths. There must be something else to it.

I’ve searched far and wide for information on Computer Rage and how to manage it. However, I have to say that aside from statistics and basic pop psychology I haven’t really found much value in the materials I’ve read thus far. A this point I have to be honest and say that over the years I have experienced Computer Rage on a few occasions, but fortunately with age and experience I’ve started to manage it much more effectively. So in other words, this advice is coming from someone that has first-hand experience with Computer Rage.

As a disclaimer, I’d like to add that I’m not a psychologist nor a doctor, but instead this is just simple advise from a software developer that has spent a minimum of 8 hours a day in front of a computer for over a decade and has occasionally experienced Computer Rage just like the other 54% of British computers users cited in the study.

Let’s look at some of the reasons that cause Computer Rage:

  • Impatience & unmet expectations: Impatience is an obvious one, but it’s important to think about what causes impatience. Suppose you’re on Holiday and you have all the the time in the world to relax and enjoy your life. There is nowhere that you need to be and there are no deadlines. You’ll probably notice that you and everybody else around you that is on holiday is driving slowly. Suppose you get to a traffic light and there’s one guy in front of you who doesn’t notice that the light has gone green: chances are that you won’t lose your cool but will remain calm and relaxed. Now imagine that you’re back at work and you have to catch a flight for a very important meeting with a customer on the other side of the country. If you miss the flight you miss the meeting and you’ll probably lose the customer. Now imagine you’re running late to the airport and imagine the exact same scenario where the guy in front of you at the traffic lights doesn’t see that it’s gone green. Chances are you’ll lose your cool, start sweating, maybe start cursing and hoot at him. The difference between the two scenarios has nothing to do with the guy not seeing the traffic light going green and everything to do with your expectations. In the latter scenario, your expectation is to get to the airport on time and get to the meeting. When people are driving slowly you realise that the expectation will not be met, which makes you impatient with other people and can lead to anger and even road rage.
  • Feeling helpless: Another major cause for anger and frustration with computers is when you feel helpless to change a situation. This can often happen when something goes wrong with your computer or software and you don’t know how to solve it. This can quickly lead to despair and generally feeling like your whole world is falling apart. Feeling helpless and despair will instinctively draw a fight-or-flight response from most people. Some people will start crying (flight response) while others will get angry (fight response) as a natural knee-jerk reaction to overcome the perceived threat they’re facing.
  • Lack of confidence & anxiety: A lack of confidence can lead to anxiety and anxiety can lead to a lack of confidence. This goes hand-in-hand with feeling helpless. A lack of confidence in your own abilities to troubleshoot an issue can amplify the feeling of helplessness and despair.
  • Existing stress: Working with computers on a daily basis can be stressful in itself. That coupled with additional external stress, either from your personal life or work politics can be prove to be overwhelming and turn into a recipe for disaster. There is only so much weight that one can carry on their shoulders and given long periods of time under heavy stress can make any one reach their breaking point. This can lead to irrational responses and Computer Rage.
  • Fatigue: Working when you’re tired can reduce your level of concentration and patience, which once again can reduce your ability to troubleshoot issues and therefore make you short tempered when things don’t go according to plan.

So here’s my advise for managing Computer Rage:

  • Psychological tips:
    • Manage your expectations: the first step to becoming more patient is to start managing your expectations and you do that by planning ahead. You know that the traffic to the airport will be bad, hence you should probably leave earlier. If you do end up running late, you should realise that it’s your own fault and just surrender to the impatience and anger you’re feeling. This translates in a similar fashion to slow and unresponsive computers: you should start planning better for your deadlines and keep in mind that in the tech industry anything that can go wrong will go wrong. If you’re going to leave your work for the last moment, you will quickly lose your patience with the computer when it doesn’t behave the way you expect it to behave. Furthermore you should lower your expectations of your computer i.e. you should expect the computer to be slow at times.
    • Avoid working when you’re tired: I know that there are many companies that push for ridiculous deadlines and actively encourage workers to pull all-nighters. But the truth is that working while you’re tired is not in any way productive. Aside from many other negative side effects which I won’t get into in this post, you have to also keep in mind that you will be short tempered when you’re tired. I have never in all my years seen anyone maintain the same level of patience when they’re tired than as when they’re fully rested. Therefore working when you’re tired will without a doubt cause some Computer Rage.
    • Avoid working on an empty stomach: First of all, your brain needs to nutrients in order for you to think properly. If you’re hungry and come up against an issue when working, you will not be able to think clearly and troubleshoot the issue efficiently when you’re hungry. This once again can lead to feeling helpless and and ultimately even anger. This is known as being “hangry“. The reason for it is that not eating will lower your blood sugar levels and according to psychologists “Hunger and hypoglycemia (low blood sugar) are primitive signals known to set off the stress response in a person“. For some people this stress response can escalate into anxiety, depression, anger or all three. This is an evolutionary mechanism designed to put us (and animals) into survival mode in order for us to prioritise finding food. Therefore it is important to not work on an empty stomach if you want to avoid being short tempered when things do don’t go according to plan.
    • Don’t drink too much coffee: There’s a joke in the software industry that developers are machines that convert coffee into code. This may be true because coffee is a stimulant that gets your brain going, but at the same it can escalate anxiety which can turn into anger and being short tempered. So try avoiding getting over caffeinated.
    • Close your eyes, take a deep breath and count to ten: Even if you’ve put all the above measures into place to avoid Computer Rage, there will still be times when your computer will cause you to get angry. For example, the computer could become unresponsive because it is busy processing or perhaps trying to connect to a resource over the network. If you’ve ever run on a treadmill or done the plank exercise, you’ll notice that looking at the odometer or timer can be an excruciating experience where 30 seconds can feel like a life time. You will have probably come to realise that looking away from the odometer or timer and thinking about something else will make the time go faster. The same principle can be applied to dealing with unresponsive computers. If you start feeling irritated, try closing your eyes while waiting for the computer to become responsive. You could also try taking a deep breath and counting to ten while keeping your eyes closed. Nine times out of ten the computer will once again become responsive by the time you’ve opened your eyes.
    • Take a walk: As a last resort, if all else fails and you can feel the onset of anger, you should get up from your desk immediately and take a walk. While being away from your computer try thinking about all the possible causes of the computer malfunctioning. You will probably come up with a few ideas within seconds at which point you’ll be tempted to go back to the computer to try them out. Avoid going back to your computer before you’ve calmed down. Instead, carry on walking and come up with several more ideas. You can go back to your computer once you have a list of ideas and you’ve completely calmed down. You’ll also notice that as you become calmer, the ideas will start streaming in  i.e. your level of calmness and the rate at which you get new ideas are directly proportional.
    • Sort out other problems from your personal life: It is naive to think that problems in your personal life cannot affect your work life. The truth is that we are all human and if you have a personal issue, it can cloud your judgement and your ability to think properly while on the job. For this reason it is important to sort out your personal problems as quickly as possible so as to not affect your ability to work.
    • Practice silent leadership: It’s not always easy to be immune to drama and/or office politics happening at work, but it is important to at least try. The best way to avoid office politics is to practice “silent leadership“. There is a great deal of material out there on silent leadership so I won’t get into this topic except to say that silent leadership is essentially putting your head down and getting to work without complaining, arguing with other people or worrying office politics and drama.
  • Technical tips:
    • Don’t be cheap: This is by far the best and most important advise I can give anyone for preventing Computer Rage. If you’re a knowledge worker and especially a developer that spends at least eight hours a day behind a computer, then you simply cannot be cheap with your hardware. Development tools can be especially resource hungry causing a weak computer to be quickly brought down to its knees. Aside from the drop in productivity of using a slow computer, I can without a doubt say that it would be literally destroying your own mental health and maybe even your life in general. There is absolutely nothing worse than having to constantly wait for your computer to be doing something after every click. Given enough time working under such conditions it can literally drive you into a mental asylum. There are certain things in life that you could and should be cheap on, but a computer is not one of those things. I know that most of the times the companies normally provide you with their own computers to work on and many of these companies that are run by bean counters can indeed be very cheap on the hardware they provide you with. If that’s the case, do yourself a favour and go out and buy the best computer that you can afford. If it comes down to it, sell or downgrade your car if you have to, but purchase a fast computer i.e. your car costs you money while your computer is a tool that helps you make money.
    • Saving you work: One of the main causes for people losing their cool with their computers is when they’ve been working on something for an hour (or more) and all of a sudden something goes wrong with the computer where it freezes, blue screens or applications crash. This can easily lead to feelings of despair with people throwing their toys out the cot. This is in fact the easiest issues to solve by simply getting into the habit of continuously saving your work. Learn your keyboard shortcuts for quickly saving your work. If you’re coding for example, get into the habit of hitting the save keyboard shortcut after every function or line of code that you’ve written. If you get into this habit, you’ll end up instinctively saving your work without even thinking about it e.g. it will become like changing gears in your car, where you don’t even think about it you just do it.
    • Backups: I have personally seen people having meltdowns after documents that have somehow been deleted or their computers crashed without being able to reboot them. It goes without saying that the easiest way to prevent this from happening is to always have backups of everything using one or more of these options:
      • Source Control: You would think that every developer on the planet uses source control, but I have personally seen programmers with years worth of code just sitting on their laptop never having been checked into any repository. Seeing this blows my mind. Even if you’re a single developer working alone without having to collaborate with any other developers, it is crucial that you get into habit of checking in and pushing your code changes to the repository as often as possible. If something goes wrong with your computer or you lose it, you can simply check out your code from the repository and be back in business in no time.
      • External Drives: For very large files that may not be appropriate for source control repositories, I’d advise you to get into a habit of backing up these files to an external drive.
      • Restore Points: Start using  TimeMachine on Mac OS X and System Restore on Windows in order to create restore points. If anything goes wrong you can always restore your machine to a previous state. Personally I love using Apples’ Airport Time Capsule because not only does it serve as a wireless hard drive that I can manually copy files to, but it also performs automatic backups of my entire laptop every day while creating restore points for Time Machine.
      • Cloud Backups: Most operating systems nowadays have some sort of cloud backup feature whether it’s through Google Drive, iCloud, Microsoft OneDrive or even Dropbox. Get familiarised with these tools and save your most important files to the cloud.
    • Knowledge is power: The easiest way to overcome feelings of helplessness and despair when dealing with technical issues is to learn. This obviously doesn’t happen over night, but the more knowledge you have the more empowered you will be to overcome technical issues when they come up. So instead of getting angry and throwing your toys out the cot, you’ll be able troubleshoot the issue with confidence. Keeping this simple rule in mind can help when you feel the onset of anger.. Even if you don’t immediately know the cause of the issue or how to resolve it, you can at least start researching for possible causes and solutions before you lose your cool.
    • Task Manager / Activity Monitor is your friend: The easiest way to start troubleshooting an unresponsive computer is by using Task Manager on Windows or Activity Monitor on a Mac. Nine times out of ten, there will be an unresponsive application that is the culprit. Using Task Manager/Activity Monitor you can view which applications and services are being resource hogs i.e. taking up the CPU, RAM, handling heavy network traffic, or furiously reading and writing to the hard disk. If the application does not respond after a few minutes, you can quickly kill the process and restart the application.
    • Close apps you’re not using: This is all about setting up good habits. I have seen people running 50 or more applications and browser tabs concurrently on their computers. When the computer starts slowing down and becomes unresponsive they seem to be flabbergasted by it. It’s always good practice to try and limit the amount of applications and services that you’re running concurrently. This will free up your resources on your computer and provide more processing power and memory to the applications that are currently in use.
      • Browser tabs: you really don’t need more than a few tabs open in your browser e.g. email, search engine and two or three other web pages. For example, if you have 50 web pages that you’d like to go through, then you really don’t have to keep all of them open in your browser. Instead, rather copy and paste their links into a text file as a reference. When you’re done going through one web page close it and open the next URL.
      • Applications: Get into the habit of saving your work and  closing an application you’re not currently using. Not only does this free up computer resources, but it also makes it easier for you to navigate between the applications without constantly searching through all the clutter. This is essentially similar to having a clean desk because as they say “A cluttered desk is a cluttered mind.”
      • Background Services: On Windows for example, using Task Manager you should get into the habit of regularly looking at all the services that are running and the resources they’re consuming. On Windows for example; if there’s a Windows Service that is running and not being used, then stop the service and change its Startup Type from Automatic to Manual i.e. the service should only start when you manually start it instead of starting up automatically when the computer boots up.

These are all just some basic tips for avoiding Computer Rage and stress in general when working with computers. Keep in mind however, that simply knowing these tips will not help unless you practice them everyday.

Do project managers actually add value to software projects?

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Sales, Software

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.