Developer Strategy – Random Musings Of An Ex-Developer

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 🙂