And Vijay Says…

Some of you might know this – I trained to be a mechanical engineer, and then did an MBA thinking I wanted to be an investment banker. But right out of business school – I figured what I REALLY wanted to be was a developer. So I took a developer job and stayed a developer for many years, before moving on to management and other more mundane things.

I still code at every opportunity I get, and I introduce myself as a programmer most of the time when I meet strangers. I don’t think I am an ace developer – I used to think that way, but learned along the way that I over estimated my abilities. But in a pinch – I can design and code to save my life. So that is the background based on which I am making these comments – an ex-developer, who moved on to management along the way. And I am fairly sure that if I ever succumb to the temptation to get out of management – I will consider being a developer as my first option.

Please don’t take this as the views of my present or past employers – I am not representing them here. These are just MY personal views. If I ever start a technology company (as opposed to an Indian restaurant), this is how I plan to engage with developers.

1. Align developer strategy with company’s stated objectives – or don’t have a developer strategy at all

This is the first step – and it is a mandatory step. I would NEVER want to have a developer strategy if I cannot figure out how to align it with company goals. If I need to make a certain revenue, or profit or whatever – I should know how developers can make that happen. If I cannot do that – I won’t waste my time or developers’ time . No strategy is better than a terribly articulated strategy.

Why? because if such a connection with business goals does not exist to justify it – developer strategy will become disjointed over time, and it will never have top management support when times get hard. Then developers will turn neutral (or even negative) and kick start that dreaded accelerated trip downhill for the company’s technology.

2, Don’t just evangelize to developers – have the periodic sermon to keep them faithful

Lets take a leaf out of religion. Evangelists will make larger than life statements to get the attention of the people who have another faith and try their best at mass conversion. But then the evangelist will move on and come back only periodically to reinforce the belief. However, someone else needs to keep the conversation going so that the converted do not go back to their old faith, or worse yet – fall for another evangelist’s promises. The latter needs to be more low key, since people will get bored if there is no change of pace in the message. Eventually, the social needs of the faithful to talk to others will take center stage, and once that happens – faith is on strong foundation.

Developer strategy in many organizations fail because all they do is evangelize. No one keeps the conversation going. And since the community feeling does not kick in, developers will drop off and move on to the next thing. I know I will if that happens to me.

3. Fire the person who comes up with a “one size fits all” developer strategy

That will be a “shoot first, don’t ask” thing for me. There are many types of developers – and there is no one strategy that works for all of them. What excited me to take up C programming in 80s is not what excites me today about Python. If the person evangelizing to me does not get that – I will tune out in a hurry. I might even say uncharitable things to their face. So don’t be fooled into having one strategy for all developers.

Based on many factors – age, experience, geography and many others, you need to find out what makes developers tick. You will do that routinely for customers and vendors – because that is part of your corporate strategy. Do the same for developers – do some good segmentation, and refuse to cave in to lowest common denominator. As you can see – this is why I said before that if developer strategy does not align to corporate strategy don’t bother having one at all.

4. Don’t treat external and internal developers significantly different from each other

That would just be utterly silly if you had different messages for each group. If internal developers won’t buy your message on new technology – see what is wrong and fix it before you preach at scale externally. Remember – they are internal when they work for you in office – more often that not, if they are any good, they will be on other forums doing other things outside work if they don’t care for your technology – although that is what pays their bills. And everyone talks in this day and age – the world of developers was social before social was fashionable.

5. Don’t just listen – act !

Listening to developers – internal and external, is table stakes today. That is the minimum expectation. Act on it – that is what differentiates the good companies from the also rans. No one will give you serious feedback a second and third time if you don’t show them that not only did you listen, but you also acted. Act does not mean you agree with the feedback – “act” might just be telling the developers you heard it loud and clear, but for some logical reason, you have to take a decision that is not along the lines of what they wanted you to do. If you are genuine – they will be ok with that and respect you. If you fake – they will call you on it.

To act – you need authority. And this again goes back to aligning developer strategy to company objectives. If the highest levels of the company does not think this feedback needs to be acted on, who ever faces developers will just get stuck between a rock and a hard place.

6. What is in it for the company and developers ?

For long term commitment on both sides – there should be some benefit for both sides. I chose to become a developer because I clearly saw in the mid 90s that I could pay my bills and have a career being a developer. If I did not think so – I would have become an investment banker who might have coded now and then for fun. Money and career might not be what motivates other developers – it might be peer recognition, thrill of learning something new and so on. Whatever it is – the strategy should cater to it. And in reverse – the technology provider should know what they expect from developers. May be it is to harden the code base, may be it is to make better product decisions, may be it is better testing – or something else totally. But know what you want – and don’t be generic.

A strategy is only as good as your ability to execute. So don’t make sweeping statements about goals that you have no chance of achieving. It will only make you look bad before developers. If your business strategy is to have 1000 customers use your technology in 5 years – and each customer at the most is expected to use 5 applications at the most, you have no reason to target 100,000 developers to begin with. Maybe 10,000 itself is more than enough. However, if your strategy is to reach 10 billion users in 5 years – maybe you do need a billion developers to build on your technology. In the latter case – if you aim to have 10,000 developers, you will look pretty stupid.

7. Every one should carry the message – but leave execution to one team

Everyone in the company should know why and how developers matter ( or not matter if that is the business strategy). The benefits are obvious – if you look at customers as an equivalent case. Everyone from finance to HR to Procurement to legal to product management will bend over backwards if there is a customer angle to the problem they are solving. Why? because they know how customers impact the business. But that is seldom the case with developer issues. If these folks knew how developers impact the company’s goal, they can prioritize better and save a lot of time in getting decisions made.

While everyone should get the memo – it is also equally important to not dilute execution by having multiple internal teams trying to have their own strategy for developers. It is not such a difficult thing to understand – even if product managers and finance have a view on how to sell, end of the day – there is a team that is tasked with sales, and it is their call and everyone else should defer to them for that final decision. Same deal with developers – have someone with sufficient authority lead the charge. Everyone can provide feedback and help, but execution decisions should be left to that person and team. Hold them accountable by all means. There is a reason why cars have one steering and one driver’s seat.

This is not just an internal issue. Ecosystem of developers should know who they can talk to and get help. If they don’t know that – they won’t keep trying for ever to find out. They will move on to someone else who will listen and act. That is how it goes.

There are a few more things – probably MANY more things – but I am going to stop typing at this point. Weekend is over, and I need some sleep before the email flood gate opens on Monday morning. Let me know what you folks think.

Happy Onam to you all the developers out there – ok ok, non developers too 🙂

It is Friday the 13th today – maybe the best day to write this post after all .

First I need to turn back the clock to the 1980s.

In my teens, the most popular car in India was ” The Ambassador”. It was so popular that the company just did some weak spot welding to barely keep the engine in place, and slapped on 4 tires and let you take delivery of the car . Buyers then took it to a workshop to do better welding, do wheel balancing and all of that . That was normal – and till I moved to USA, that was all I expected of a car buying experience . I have driven those new Ambassador cars a few times from the dealership before taking them for wheel balancing and other fixes – and that caused this huge mental block for me about all kinds of misaligned things. It was further reinforced in the automobile engineering classes in college .

Then I did my MBA in mid 90s – and the only thing that stayed with me throughout my life after that was the concept of “policy by lapse”. In short – it essentially means “doing nothing” as the strategic response to a given problem . The example my professor used was of the former prime minister of India who took that strategy when some Hindu extremists destroyed Babri Masjid . The guy didn’t do a thing – and is “alleged” to have said something like this . “I am not indecisive . I consciously decided to not take any decisions at this moment”. Needless to say – I have a serious aversion to “policy by lapse ” ever since that lecture .

But it was only after I started working that I realized that it is rather common to run into both “misalignment” and “policy by lapse” for a given problem . And you can imagine what that did/does to me 🙂

Both are issues that take some top down management attention to solve . And you can’t take your eyes off for long – it needs micro corrections all the time , just as a perfectly wheel balanced car cannot drive straight for long without micro corrections .

I have given up on annual goal setting being a useful strategy – in my line of work , no goal remains static for that long . Along the same lines – i am not a fan of annual performance reviews either . These rules were set at a time when world changed slower – and now they are useless . The only reason they exist today , I think, is because it is a “scalable” process . Not because it works .

Whatever changes to goals happen at a lower level of org hierarchy – it should be aligned with goals of the company . Every goal should have a clear rationale on why it matters to the success of the company – not the success of a product , not the success of finance department – the success of the whole company . Otherwise , don’t set that goal . People like stretch goals – but that is not a reason to be unreasonable and reckless . It is a serious credibility loss for a leader if he or she cannot explain their direction in a rational way.

If you as an employee get an unreasonable goal – go right ahead and challenge it (Politely ). Ask the person who set it, to explain it in terms of how it helps the company in tangible terms . Either you will learn something you didn’t know before, or the other person will have that pleasure (or pressure , in some cases) . At a minimum you will know whether it is a hill that is worth your while to try capturing . If you don’t get satisfied with the answer – make a decision on whether you are going to disagree and commit , or quit . Do everyone (including you) a favor by NOT contributing consciously to misalignment .

It is not pleasant or efficient or even safe to drive a seriously misaligned car – and it is not easy or fun to work in a misaligned organization without widespread confusion and frustration . Not only will the goal not be met – you risk losing your best talent in the process if you keep doing that , on top of looking stupid for not meeting the goals in the first place . It is a high speed race to the bottom – and it is a race you can choose not to compete in .

Then there is the “policy by lapse” thing . Hope is not a strategy – and if you believe it is , I have a dead rich friend in Nigeria who has left you a large sum of money . Just send me your bank user is and pass code to make the transfer 🙂

I have encountered “Policy by lapse” several times at work , and can’t remember it succeeding even once . I do have several examples and battle scars of cases where it was the chosen strategy to deal with misalignment . And I have later regretted every such occasion I have decided to not take this issue head on . If you keep driving a car with misaligned wheels for a long time , it gets worse – not better . If you think it gets better – I have a couple of bridges to sell you right after you sign up to get the money from my dead friend in Nigeria 🙂

If people swap a few “what” questions they routinely ask in corporate world with “why” questions – this problem can be prevented easily . But even if you can’t prevent it – at least try not to use “policy by lapse” to fix it .

Trust me – remember I am the dude who sold you the nice bridges that you paid for with the money from my dead buddy in Nigeria . And I have some freeways I can sell you to go with those nice bridges too 🙂 .