When Applications Scream “I don’t Trust You”


Between telecons today, I was glancing through twitter and had a brief chat there with Ben Haines, the CIO of Box.
See below.

20130920-084051.jpg

Just reminded me of a few phone calls I have had from the expense police in past life

Expense Police :Can you explain why you tipped $10 more than 15% at dinner ?
Moi : err- because the client loved the service at the dinner I took him to and let me get away with a missed milestone which would have cost the company a few thousand dollars

Expense Police : I need a daily exchange rate breakup for your claims for Germany trip last month. If you can’t respond in 2 hrs , I will deny the claim and you have to raise a new claim later
Moi : sure – let me step out of this stupid negotiation with CIO for a $30M deal right away and go find the exchange rates for you for my $5000 claim

3. Expense Police : I am denying the $2K air ticket because you didn’t attach a manager approval note

Moi : sorry – I made the assumption that the General Manager 3 levels above my boss had the authority to approve the travel and only attached his approval . Let me call and yell at him for aiding and abetting a willful negligence of company policy by me

4. Expense Police : I will let the first 3 things slide this time based on your explanation. But this is the last time and I will have to notify your manager

Moi : Much appreciated. I will let my manager know so that he can prepare his manager for his call with you for his own expenses

5. Expense Police : Remember I told you I will pass your claims this time? Well, we cannot do that. The system does not allow us to do that. So I am denying the claim.

Moi : OK – I am sure the system has good reasons to do it, given it is more intelligent than both of us. Does the system accept thank you notes or flowers that I can send to mark my appreciation?

I will stop here – there are a dozen more along these lines .

I would be hard pressed to find an application that is more universally loathed than expense apps .
Why is it so ?

Mostly because the fundamental thinking behind corporate expenses is. “Trust no one”. Everyone from CEO to Janitor are out there to cheat the company on expense reports apparently . Put as many obstacles in the way – and we can find that one bad guy amongst the thousands of employees and contractors.

Second , legal frame work is stuck in the 1950s . There are places where you can claim electronically with a nice iPhone app but you need to mail in receipts . A paradigm of productivity and efficiency , eh ?

Last, apps get built by people who don’t travel and hence have limited knowledge of how traveling employees live and pay .

I know many including me wanted job promotions in past strictly because then you can offload expense reports to an assistant . But every time I give a bunch of receipts to my EA , I feel rather sorry for her . I hope she doesn’t get as many calls from the expense police .

Zero Inbox Strategy – To Be Or Not To Be ?


I have a zero inbox policy . I read every email I get within a short time of it showing up , respond to the ones that need attention then move them to an archive . I don’t go to bed till I am done . And I have been this way for about 8 years .I don’t let my assistant reply to my emails , although she has access to it .I have the same zero inbox policy on personal email and twitter too . In that aspect , I was “real time” friendly before real time became the new black 🙂

It has its advantages that I can reasonably stay on top of my work , given the high volume of emails I get. In general it has definitely helped me with career success and progression too .

However , there is a big price to pay to keep this habit. And I will be lying if I say I enjoy this habit a lot . A more accurate statement will be that I have high tolerance now 🙂

For starters – it means I stay up late every night , including most weekends . Even on vacations I try to stay up late to finish email some times – which irritates my family to no end . If I don’t – I will never catch up with the back log . I kid you not – I had to once lock my smartphone in a bag and leave the key out of sight to stop looking at email during vacation.

It also means I very rarely write long , well crafted emails . I usually respond in one sentence or two – and it occasionally comes across as harsh or non caring to people who don’t know me . I am however a tad more careful when I email customers – but even there , I stay brief . In general – people need a bit of time to get used to my ultra brief emails with rarely any salutation or signature 🙂 . Thankfully – my boss is also a fan of brief emails .

One lesson I learned early in my career was to not rely on email for all communication . I use chat functionality and phone heavily , and that minimizes the email traffic . I also like to do face to face communication with others whenever possible . On the bad side – you might not have anything documented if memory fails you about a phone call . So for important stuff – I try to send a short summary via email .

I also use a separate email id for Internet stuff that has even a remote chance of spamming me in future . And of course I rarely open that account . If anyone spams me intentionally more than once – I block them . This is especially a problem with personal friends and relatives who will get offended quickly.

With my team, I encourage them to use the phone as much as possible and then just send one email in summary . It doesn’t always work – given I never had the same team working for me for several years at a stretch . So we relearn together periodically 🙂

I also don’t create a complex folder structure for my archive . I trust search more than my organizational skills . However , search is as much an art as a science – so occasionally I get some serious grief . For that matter , I don’t use flags or color coding or anything of that sort . This is probably why I think BI should also largely move to search as primary interface 🙂

Some emails always will fall through the cracks – given my frequent archival . I try to be careful , but I make mistakes . But the good thing is that if it was important – I would get a reminder most of the time . Again, if the email is from a customer – I try to be twice as careful , but of course I occasionally miss those too.

I do let my EA handle my calendar almost exclusively . I am terrible at that – and she is very good with that . So I just follow her lead and will only mess with it if something comes up when she is not working . I refer to her as my life saver .

So for all the good things I get out of having a zero inbox – and all the discipline I follow to keep it that way, there is one thing that I have no control over . Since I respond near real time – it gives the wrong idea to some people that I am “always on”. And some of them will get offended if I read but do not respond quickly at 2 AM . I have tried many different things – but no good scalable solution has been found yet .

So that brings me back to why I wrote this now – is it worth keeping up with zero inbox policy and the stress that comes with it? Or should I relax and let it slide ? That will be something I will think about in 2 weeks time when we leave for an island vacation . Last year when we went to Hawaii is when I decided to quit my job at IBM . I wonder whether I will decide to stop the zero inbox policy this trip . The decision kind of has similar magnitude in my mind 🙂

If any one has any tips, suggestions , wise cracks et al – let me know .

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 🙂