From Engineering To Sales


Yesterday morning, I woke up to see a mail that said I was given a “Thought leader” badge by IBM – which is our highest level of competence in consulting . We have switched a few different HR frameworks in my time here and this badge was a retrospective of the level I had achieved more than a decade ago as a senior manager .

It just reminded me of my shift in career direction and I posted it on LinkedIn . That led to a lot of people reaching out asking me about how they should think about a career transition between Engineering and Sales .

I am a mechanical engineer by training and a software engineer by profession . I chose engineering as my line of work strictly because I saw how much my father enjoyed being one . This is also why I chose a career in IT after my business school instead of Finance which was what I largely focused on while doing my MBA.

I am an introvert by nature . It takes a lot of effort for me to not let that hold me back and occasionally it still exhausts me trying to do that . This probably was the root cause of me hating sales with a passion when I started working . When I looked at sales as an engineer – I felt it is all about telling half truths and lies , wining and dining clients , speaking a lot of jargon and using fancy vocabulary , having a good golf game , taking credit for engineer’s work and so on . Net net – I couldn’t think of sales as an honorable way of making a living . The reality – which I know now but didn’t know at the time – was that I didn’t have the confidence to do any of the things sellers did every day .

I was a reasonably good developer , mostly thanks to an early start . I learned BASIC when I was in seventh grade and C when I was in ninth grade . My favorite uncle gave me his old PC when he left for his masters in US . Other than training dogs, and playing cricket – the only other thing that I had real interest in was in creating silly video games .

A big attraction for me to work in IBM was that this company had an iconic status in tech . I felt I can thrive in that environment . So when I joined and learned about career options , the most attractive option was to become a distinguished engineer – which is the executive rank for our technologists , much like a partner in consulting . I started getting all the certifications and other credentials needed and was generally progressing fine towards becoming a DE . The stretch goal – more like winning the lottery really – would be to make IBM fellow .

That is when my boss and I had an interesting discussion . He said something like this – “You will probably make DE in a few years and it doesn’t look like there is any big risk that will stop it . So why don’t you take a year trying to carry a sales and revenue target and see how you like it. If it doesn’t pan out – go back to your tech career” . A few discussions with my mentors made me realize there is no risk in trying this and I took on a sales target as an associate partner .

To my shock and surprise, I realized that pretty much everything I thought of sales – all the negative stuff – was purely my own ignorance and fear . I needed some training – and my boss signed me up for training in negotiations , executive presentations etc when I made those requests . I cannot emphasize how much that training helped me .

Here is what I figured out . There is a big similarity between good sellers and good engineers – they are good problem solvers . Engineering gave me two skills that proved very useful in sales

1. The ability to analyze problems systematically and finding solutions to the components

2. The ability to then combine the components to a cohesive solution for my client

All problem solving needs assumptions . And that exposed a weakness I had . As a programmer, I rarely needed a lot of help from my team to analyze problems . When I needed that help – I knew how best to ask that question and who is best positioned to give me a good answer . That was not how it worked in sales .

The unknowns are many in sales and often no one person knows all the answers . What’s worse – you often can’t even ask the right questions . That was the hardest challenge for me personally to overcome . Learning to ask for help early and often , and trusting others to build a solution with me . Doing trade offs on tech with people who think like me and doing it on a solution where everyone thinks differently – it is an acquired taste . Interestingly, once I acquired the taste – I think it made me a much better engineer too !

Then there is the idea of how you move from good to great . In engineering – tech changes from time to time , but if you are used to solving problems from first principles – you will thrive despite the massive changes around you . Sales can make use of the same idea – except that it is about people . Moving from being good to being great (or in my case aspiring to be great ) is all about your ability to understand people and their motivations – which is quite a bit harder than reading legacy code and figuring out a modernization strategy .

People do business with people – not with companies . We talk more about what is good for the company – but the truth is that sales is about what is good for people in that company . That needs relationships , that needs the ability to understand what makes people successful and motivated to work with you and so on . And when I say people – it’s not just people at your client . It’s people in your own company too ! The more deep our understanding of people – the better the sales process all around , even if no transaction happens in short term .

And that brings me to story telling . No one really likes to change – including and especially me . And yet – sales is all about making change happen . Of all the tools in sales – the ability to tell a story is what I find the most powerful . Stories are magical when told well – they get people to focus , helps them switch contexts and feel inspired . Numbers and facts don’t have the same effect on people . That was a hard switch for me as my basic DNA is mostly quantitative in nature . It took me a lot of effort to blend facts and figures into stories to make it work . But post facto – I can assure you that the juice is worth the squeeze .

Now that I have covered a lot on being effective , I will make a couple of points about efficient selling .

As programmers , we learn about code hygiene and why that is useful . That concept readily extends to sales too . Keeping pipeline updated , having people QA our pitch stories etc are all great things . Also just like with coding – your ability to say No is what eventually makes you most successful . Qualifying every step of the way – ruthlessly – is your key to being successful in sales . When I look at my old code , I have often wondered why I typed up thousands of lines of code that never executed . Similarly when I look at my old deals – I have often wondered why I bothered to do all the things that don’t matter to the client very much . Learn from my mistake and ask yourself frequently if your opportunity is more or leas qualified today than yesterday . And don’t keep the info with you – share it with your team and your boss . There is always someone with a fresh perspective on what can be done to make it better . Share it with your client too and ask if you are still headed in the right direction.

And then there is the time dimension . As engineers, we write code to ship and that usually comes with firm dates that look unreasonable . Sales is that way too . It’s not a deal unless there is a predictable date to go with it . Learning to estimate the time it takes to close a deal is just as much an art as it is to estimate a finish date to coding . Eventually you will have to pick a date and make it work on both fronts – with the associated cursing , coffee and late nights . There are always dependencies that we only learn about late in the process . Good engineers figure out a model to thrive in that stressful environment and it’s something you can figure out just as well in sales too .

I will conclude with this . For me – engineering and sales are co-mingled parts of my job . I switch from largely sales oriented to largely tech oriented roles every few years to keep it interesting . But there is never a case where I ignore one in favor of the other . It is a model that works for me and it probably will work fine for all of you engineers too who want to expand into sales roles .

I still need to learn to play golf better , improve my vocabulary, develop a fancy accent and develop a taste for fine wine 🙂

Victor Hugo on Enterpise Technology


I had a Sunday morning group chat with a bunch of friends who also make a living from the enterprise tech Ecosystem like I do . We were mostly talking about how our world seems to be changing even faster since Covid came along uninvited , and how each of us is coping with us .

After the call, I had a lively discussion with my daughter about Victor Hugo. She is taking an AP course on English Literature in high school and needed examples of famous writers who stood up against the powers that be of their time. So we spoke about Hugo and Napoleon . I chose the example mostly because we had vacationed in Paris last Christmas and she could relate more easily to the stories I told her at that time .

After these two conversations , I did some internet research on Hugo . I can’t help but connect Hugo’s writing to our life in enterprise technology world these days – on how we look at our life and work , how we survive and hopefully thrive , our fears and prayers and so on .

I am sure at least some of you will be amused like I was when the thought came to my mind 🙂

1. Emergencies have always been necessary for progress.

2. Hope is the word which God has written on the brow of every man.

3. It is by the real that we exist; it is by the ideal that we live.

4. Utopia today, flesh and blood tomorrow.

5. There is one thing stronger than all the armies in the world, and that is an idea whose time has come.

6. Great perils have this beauty, that they bring to light the fraternity of strangers

7. Be a bird perched on a frail branch that she feels bending beneath her, still she sings away all the same, knowing she has wings.

8. Be a bird perched on a frail branch that she feels bending beneath her, still she sings away all the same, knowing she has wings.

9. As the purse is emptied, the heart is filled

10. People do not lack strength; they lack will

Four simple steps to minimize analysis paralysis


Today, I was asked by a young colleague on how I avoid analysis paralysis . It took me down memory lane a bit . After the call, I figured it is a question that others might have as well and hence decided to share some thoughts here.

I am not a big risk taker by nature . I have often thought about the reasons why . My hypothesis is that there are influences from my parents and the managers I had in my formative years , and the academic system that I went through all contributed to me measuring twice or thrice before I cut .

There was a period in my career where I was a poster child for analysis paralysis . I would measure endlessly , toss and turn and lose sleep , and never make any cuts . Looking back, I understand why I was so stressed out . It was the first time that I was given a sales target . I felt the weight of the world was on my shoulders and even for very small deals I would over analyze and delay getting back to the client .

One very rainy day in Oregon, my client and her boss invited me to a coffee meeting and said something like this . “Vijay, we absolutely enjoy working with you on technology topics . You walk us through pros and cons and help us take decisions . But when we ask you for a commercial proposal , you struggle even for small things . What is causing your difficulty ? Why are you not taking the same approach as you do with tech questions ?”.

My clients came from engineering and finance background themselves . They had never sold anything in their lives either . But they gave me the best framing of the problem and almost overnight my problem with analysis paralysis was overcome .

So here is how I approach decision making in four simple steps

1. Gain clarity on my role – who is the best person to make the decision and why ? If it happens to not be me – do I have a role to play in helping that person take a decision ? If I am the decision maker , do I know who else needs to help me make the decision ?

This step helps figure out the minimum number of people required to take the decision and by itself eliminates a lot of paralysis . It is also important to make sure it is the best qualified people . Often we make decisions based on assumptions . People who are not close to the ground reality rarely make good assumptions , and that in turn makes even simple decisions really bad

2. Determine time line and consequence of inaction . How urgent is the decision ? And what will happen if a decision is not made in that time ?

Most decisions are not as urgent as they look upfront. Often we find that someone had padded time in the process and you just happened to be in a part that got squeezed and can negotiate a more realistic time line . Used to an extreme, this could have a negative effect because you just end up procrastinating because you are good at buying time 🙂

3. How important is the decision being right the first time ? Is this something I can change my mind on with minimal trouble if I got it wrong ? Or is it the kind where I absolutely have to nail it or else the consequences are more than I care to live with ?

Decisions that have big impact and are difficult to change – by all means spend the time and effort to get it right . The other kind – it’s often better that any decision is better than no decision . It takes a calm mind to determine which kind of decision we are dealing with when we face the problem for the first time . It’s only human to think most problems are big and important

4. What are the big trade offs ? Am I sweating the small stuff – things that have a low chance of going wrong , and things that could happen but have low impact ?

Here again we need the right people to make that determination . If you end up with the wrong categorization of risks , you will probably make a terrible decision. It’s like the millionth reason to surround yourself with the right people who can look at a problem from diverse perspectives . Once you know the risks and their categories, you can plan to mitigate them .

That’s it ! Just a simple four step process to help get to a good decision . For me a a good decision is one that lets me sleep better at night . I feel confident that there is a high chance that I got it right , and I also feel that in case I didn’t get it right – I know enough to mitigate .