And Vijay Says…

Having “Chief” in your title is pretty awesome . I am friends with several people who have “Chief” in their title and they are rightfully proud of it – and I am very proud of them for getting to those important career milestones. I have my own ambitions on this matter – some day I hope to the the “Chief Trainer” at the dog training business I intend to establish post retirement. While I don’t exactly know at the moment what people with the title “Growth hacker” actually do – that is also a cool title I intend to take on in that post retirement business.

The baseline case is that the person running the company is called CEO and the direct reports to the CEO carry “Chief ” in their titles like COO, CMO, CFO, CRO, CHRO etc. CEOs cannot have an indefinite number of people who directly report to him – so some other C level roles get one notch down in the pecking order. For example – CIO working for CFO, a Chief Risk Officer working for the COO and so on. From that point on – it gets out of hand pretty quickly.

While I chose to rant on “C” titles here – this does happen in many flavors. EVP/SVP/GM roles for example all have a habit of playing out the same way.

There are about a half dozen common reasons I can think of on the top of my head why additional “Chief” roles get created. I am sure there are many more.

1. Some “must have” movement happens in the industry and pundits will advise the board and CEO that this needs a C level role. Hence roles Chief AI officer, Chief Analytics officer, Chief Digital Officer and so on get created with great intentions to drive transformation – but not always with any real budget or authority to make decisions.
2. Some “top talent” types won’t join the company without a C level title. Off late I have seen “Chief Growth Officer” as a title cropping up – and many of the people occupying those roles are people who otherwise would have only joined for a CEO or CRO role.
3. A way to retain senior talent for a period of time till another plan can be created . A famous big data company had a chief or technology, chief of engineering, chief of engineering and a few other similar sounding titles co-existing . This scenario is very common when the company is limited in making compensation increases. Similarly it could also be a way to show that a growth milestone has been met, usually for startups. The VP of Legal will become General Counsel, VP of sales becomes CRO, VP of marketing becomes CMO and so on – even with very little or no change in actual responsibilities.
4. A way for the boss to punish someone without actually firing them immediately . I know of a CTO who created a title of “Chief of intellectual renewal” for a very senior engineering leader who was out of favor. It could as well have been “Chief Librarian” . It could also be the other way around – A way for the boss to save face after hiring someone with a great resume only to find out quickly that the candidate is not going to work out, but cannot let the person go immediately due to contractual or PR issues . Not that long ago, a high profile CTO hire was converted to a Chief Business Officer with an unclear charter – who then left the company several months later.
5. A way to temporarily make sure a big transformation effort does not get off the rails – like a business reorg, a new product line , a big M&A etc . Lots of overlay roles are put in place as guard rails – especially for making sure organizational antibodies don’t kill the change before it takes root.
6. As largely aggregation functions – where the role in reality just adds up the work of everyone below then in the hierarchy, and reports it to the top. And similarly serves as a traffic cop on decisions coming from above.

All the above reasons might have been absolutely valid for the context in which those decisions were made . But the trouble is that once these roles are created – they don’t get eliminated even if there is limited proof of value add. And there is a tipping point where everyone will agree that a C level title is meaningless because it is given away cheaply.

What will absolutely happen every time is that the overall cost will go up – and revenue might not proportionately go up. These additional CXOs will need support functions. They create additional operational overhead. They exponentially increase communication overhead. They will all measure the same things across various dimensions and ask similar but repeated questions to the same people on the frontlines, wasting the time they should spend on value adding activities . And at a certain scale – invariably they will create conflicting messages and confuse the heck out of everyone.

Over time, a top heavy organization is a diminishing returns proposition. In the simplest case, it makes a company less agile. If market needs it to shed overhead quickly – it is a lot harder to let go of people at the top than at the bottom of the pyramid even if that is the right solution. Too many people sitting in meaningless roles creates a problem in promoting organically, and worse still – there will always be people aspiring for those low value jobs because the title is impressive.

So what can we do about this ?

Clearly the corporate world will not eliminate every low value CXO role – so what we need is a framework to minimize the trouble it comes with .

First – The CEO and the Board should come to terms with how much dilution can they live with C level titles being dispensed liberally. Obviously if they are ok with significant dilution, they deserve the pain it will invariably generate.

Second – Don’t create any leadership role, especially a C level role, unless there is a clear charter that makes it a unique necessity. That charter should then come with adequate budget and decision making power to deliver on the charter. Agree on a clear way to measure the success of the role before announcing it.  This cannot be a one time activity just when roles are created – all roles need to be reviewed critically every few years.

Third – if you need to make an exception for any of the half dozen reasons I listed above, then put a firm time frame around the life time of the role and define periodic check points to see if you still need the role. Make it a CEO level decision if the role is still needed after the role gets to its expiry date.

Fourth – Ideally, hire people on a time and outcome bound contract into those additional C level roles – so that it is an easier conversation with the people when the role expires, or performance does not match up to agreed levels.

Fifth – Automation ( as in analytics, AI, BI etc ) and business process changes should be the first way of solving aggregation issues. It may not be enough to eliminate all redundant roles at once – but in general it will help point out the glaring holes in organizational design very quickly.

 

 

Over the last few days – I had multiple conversations about different aspects of anxiety in the work place . I also chimed in on a couple of threads in social media about it . So when I woke up today – I felt like I should share some thoughts about how I deal with it myself .

When I was a young consultant – I was anxious all the time . Every Sunday I would get anxious about getting on a plane on Monday morning . Every time a Partner visited my project, I would get anxious . Every time I had to make a presentation or report status – I would get anxious . It didn’t take much to for me to feel anxious .

It would manifest in many ways – ranging from sweaty palms on the mild side to acute acid reflex on the harsh side . I was misery personified . What made matters worse was that I also tried really hard to hide my anxiety from my colleagues . And strangely I never asked anyone for help – and just chose to suffer through it myself . Not a lot of my friends even know today that I had to deal with those problems back when we worked together .

It had an impact on my career progression too – At 29, I was still a senior consultant when most others who started with me were managers and one or two were already senior managers .

While struggling through anxiety for several years – I also got better at analyzing problems and experimenting with solutions . I started analyzing what was causing my anxiety and what could I do about it . And at some point – I think I cracked the code !

Life turned for the better – and rather dramatically . I started feeling better physically , and started enjoying Sundays . I no longer threw up before big meetings . And my career took off – in another 5 or 6 years I got into the executive ranks .

So what did I find out ?

The primary cause of my anxiety was fear – or more precisely the fear of getting fired !

I had very good skills for my line of work . And my line of work – SAP development – was in hot demand . And if I messed up at work – the first thing a Partner or my client would do was certainly not to fire me . In hindsight all of this is plain obvious . Just that it took me half a decade to realize that the odds of getting fired were really low !

I also realized I had two big weaknesses to overcome .

1. I could have come to this conclusion quickly if only I had asked for help sooner .

2 And there was a possibility that even though I had great skills – I just didn’t know enough good people to find a job if and when I needed one.

So I started actively seeking help .

Thanks to my wife insisting on it – I went and saw a doctor and he prescribed something that helped with my acid reflux . He almost immediately diagnosed that it was stress related – and he was right . As soon as my approach to work changed – acid reflux went away and I didn’t need the medicine any more .

Looking back – a part of the problem was that I was (and still am) an introvert whom many people who know me mistakenly take for an extrovert . By now I know I am not alone with this situation, and I can joke about it 🙂

I started asking for help early and often and that made a big difference . I no longer felt the need to be the smartest person in the room who knew all the answers . This also made me realize that everyone has some difficulty asking for help . The moment I started asking for help – others in my team did so as well . Collectively – we figured out solutions much faster and with less stress . Another learning was that it is a very limited exercise if you only helped people who could help you back . You have to help what you can and then over a long period of time , you tend to always get more help than you ever expected .

I also made it a point to keep my skills sharp all the time . Every quarter I set a goal to master a new skill and I would use the weekly plane rides to get it done . It’s a habit that has become second nature . It has helped me change my line of work several times over the years – from ABAP to SAP functional consulting to BI to CRM to AI and so on . Off late – my interests have also widened to ethics , psychology and history . Eventually it became no longer about job risk mitigation – but it doesn’t hurt that it serves as an insurance in case I ever need it .

Then came the need to network . It didn’t take long to realize that just by connecting to a lot of people on LinkedIn and Twitter didn’t do me any favors in having a useful network . It’s a painstaking process of building meaningful relationships one at a time – starting with strengthening existing friendships and business relationships and then working from there to extend to others . It takes a long period of time and there is no end to it – it’s something you do all the time , and again without making it a “I will only help people who help me ” transaction .

There are other factors involved like living under your means and saving for a rainy day , taking good care of your health , prioritizing your family over work and so on . You can’t take those for granted – just by optimizing on work alone will not get you to a good space .

The confidence – and especially the peace of mind – that comes from removing fear from your mind is something that you need to experience for yourself . Words are not adequate to explain it . It’s a huge feeling of liberation from a jail that you created for yourself .

It’s not that I no longer feel anxious – I absolutely still do . It’s just that I have learned how to use it to my advantage instead of letting it stress me out . The “trick” for me essentially is to have a routine about things I feel anxious about .

For me – that includes listening to music – usually Carnatic , getting plenty of sleep (I need 7 to 8 hours) and focusing hard on just the first couple of things I need to do to get into a rhythm . If I have a presentation to make that I am starting to worry about – I focus on making sure I know what I have to talk to for the first 2 or 3 minutes . Once I get through that – my experience kicks in and I can get through the rest quite easily . If I have to review my business with my bosses – I think about what they would want to know and figure out that aspect of my answer very well . I spend less time worrying about peripheral things . If I still feel the stress – I know it’s because I need more help . I call one of my mentors and spend a few minutes talking with them and pretty quickly I am back in a good mental space .

Dealing with your own anxiety is one thing . That in itself takes a lot of effort – but it still might not be enough . There is a high chance that people in your team are anxious – and you may actually be the reason for that . As I grew into leadership roles – this started becoming more and more a topic of interest for me .

My approach to this is as follows –

1. I cannot be insecure at all if I have to help some one in my team with their anxiety . This means I need to think carefully about how I hire , how I communicate and so on . Insecure managers compound the insecurity of their team .

2. Everyone is different . What worked for you to minimize your anxiety might not work for them at all . I remember a young colleague who got anxious about flying – fearing that the plane will crash if there is turbulence . That led to a couple of glasses of wine every trip and some times even before getting into the plane . I tried to help but this was beyond me – and I was happy that this person went to a professional and got the help he needed .

3. You need to proactively and consistently take fear away from the work place – and then make sure that other people in your team are reinforcing that behavior .

4. Your primary expectation as a leader should not be to be liked – it should be to be respected and trusted . If they like you – that’s a nice side effect . The truth is that you will have to take hard decisions that affect people in your team . As long as they know you have been consistent and fair with your decision – they will understand and respect your decision even if they don’t like you for what you did . I try to be as transparent as I can be with my team – and give them headlights into what will happen next for each course of action we take .

5. All that said – there is one area where I haven’t been able to minimize my anxiety . That is about firing people . Almost invariably the moment I take that decision – I feel sick and the acid reflux comes back full swing . It’s predictable and that makes me realize it’s my body preparing me and I get through it with some pain . It is one area I definitely need to improve .

The smart people that I listen to have been saying for some time that I should think about the issue of “work life balance” more as work – life integration and it will be easier to make sense that way .

Their infinite wisdom was that I will find a lot of useful things that I can take from work to life and vice versa . Also – it’s easier to perfect one behavior and then use it seamlessly all the time instead of the constant context switching between my two phases of existence . What’s not to like ?

I have been giving this whole seamless integration thing a shot since I was a trainee at TCS . I was born and raised in Trivandrum and my training was in Mumbai – which was two days away by train , or a month’s salary by plane . Phone calls were so darn expensive too for my trainee salary . So before I left home – my mom told me to write letters instead of phone calls .

In a couple of weeks time, TCS drilled into me that communication should be crisp and concise . I tried it on Amma

My letters looked like this

Dear Amma and Achan

Pls note the following

1. I have been eating and sleeping well

2. Hope my dog is coping with my absence . Tell him I love him

3. Training is going great . I am learning a lot

Love

Your son

It took about three such letters before my loving mother strictly forbade me from writing anymore letters . Apparently “crisp concise bullets” and “restricting the note to three main things” are not what the communication with mom is supposed to follow as a template . Who knew ?

It’s a good thing that phone calls became cheaper over time . Otherwise my parents might have disowned me a few decades ago . I write very few letters, much to everyone’s relief – but my letters (and post cards and Xmas greetings and …) all still have bullet points . I have made peace with it since my use of written communication is mostly for work purposes 🙂

As I progressed through my career – I gained an invaluable survival skill . I can go back and forth with anyone with whom I have a disagreement without becoming emotional about it . I don’t raise my voice . I just stick to logic and data and I don’t tire easily . If the other party makes a good point – I quickly stand corrected with no drama . Occasionally I have had to break some glass – metaphorically speaking . At some point I also learned that humor helps make some points easier as well .

This skill had been honed over a couple of decades and in the spirit of work life integration – I of course try it liberally outside work too . If you haven’t tried it yet – take my advice . DO NOT TRY THIS AT HOME !

With friends and family, it turns out that raising your voice and being an emotional wreck is absolutely the expected way to express your disagreement . Apparently humor is the least effective tactics of all . If you want to be a real pro – you need to curse and swear , and at least minimally be capable of breaking glass physically . Metaphors are like humor – don’t bother . And last but not least – outside work , you are an absolute weirdo and/or psycho if you concede your point without a major fight .

Again – it’s a good thing that most of my arguments are on the work front . So once again – I just stick to one behavior and gracefully accept my weirdo status outside of it .

It’s not as if I haven’t taken some lessons from outside work and tried it at work .

My parents are both super charitable people . My mom has often taken on debt to help people who were in distress . My dad has helped hundreds of people with no expectation of getting anything in return . My grand father was also wired this way and he was a big influence on me when I was growing up . Having seen them all operate this way throughout my formative years – I have this tendency deep inside me that when I see someone at work who is stressed out – I often jump in and try to help . Most of the time I make their problems into my problems , in the process of solving it .

My own mentors have warned me several times that I should be a lot more careful about this . And while I have largely ignored them on this piece of advice – they have been proven more right than wrong about this . In the work place – if you don’t do this “let me help you” thing very thoughtfully , all that you do is to create a belief in those people you help that they should lean on me again the next time they are in trouble .

I still believe that helping someone of the right thing to do , so despite the first hand experience of its side effects – I still do it . I have a feeling that I have started to do more of “here is some fish , but let me also give you a few tips on fishing” . I also have a feeling that my mentors still think I am at best a work in progress on this front 🙂 . I also firmly believe that a lot of people have helped me when they had no real reason to bother .

You would often hear from very successful business leaders that you learn more from failure than from success . Intuitively that feels right . Like every other sales leader – I have done my fair share of “loss reviews”.

But there is one thing I absolutely won’t do – if I lose a deal , I will never open that proposal deck again . I don’t delete it – but it will never see the light of day again .

This means that I often have to recreate content from scratch – even if it’s much easier to take the good slides from those decks that I had put in the “never open again” folders .

It’s certainly not an efficient way of working when you are under time pressure – and I won’t blame anyone for calling me superstitious . In my defense, I generally have won more pursuits than I have lost . So I haven’t had a lot of incentive to change so far 🙂

This habit was triggered by my parental grandfather when I was a teenager . He was a history professor . I did poorly in a social studies exam in high school and when I came home – he went through my answer sheet in great detail . There was one essay that I did an excellent job and the rest of my answers were pretty mediocre . My history teacher had told me to save that essay since there is a good chance that I will need it again for the final exams .

My grandfather had some very different advice . He asked me to throw the whole answer sheet in the dust bin and start learning from scratch – and don’t even bother saving the two pages with the essay . His theory was that the answer sheet will just rekindle negativity in my mind – and however great the essay was , it will always be associated with failure . I agreed with him then , and I still agree with him today !

So yeah – work life integration seems like a fine theory . But it sure would help if the experts had some concrete advice on better templates to write letters to mom !

This blog you are reading is written on a “low code” system – it is a wordpress blog where I have not used any custom coding at all. I could have – and I am an experienced developer. And yet I chose to not even touch html or CSS because it works for my limited purposes. Few hundred thousand people have checked out my blog in the past – and literally no one has asked me yet anything that needs me to write some code. At the most – I will need to switch color schemes or font or pictures – and none of that needs me to write a line of code.

What works for me will not work for a larger and professionally run web property like Diginomica for example . They need code – lots of code. And if you go to an even bigger media company like NYT or WP, I can only imagine the talent, tech and processes they need to run it.   There is no way that 90% of Diginomica, let alone NYT can run with low code tooling today. Some day in future it may be possible – but I can’t even do any speculation on how long that is going to take.

What triggered my rant here 

This article Unqork CEO – ‘Agile has failed on Diginomica got shared on my twitter feed. That served as the inspiration for this blog. It had a catchy title – and I have criticized the poor use of agile and scaled agile  a few times in the past  . I opened the article thinking the Diginomica gang has uncovered a new angle on this. Unfortunately not only did I not find a new angle, I got very frustrated by a weird conflation of agile and low code, and some poorly articulated assertions on the applicability of low code. Usually Diginomica takes a critical take on the topics they cover – and that is the primary reason for me being a loyal reader. This one unfortunately did not cover the “so what” aspect – and honestly that disappointed me.

The fundamental premise is illogical – and poorly articulated

First – Waterfall and Agile are ways to execute a project or build a product from a methodology perspective. That has nothing to do with the actual tech that is used. For example – MongoDB came into being after Agile became popular. So if NASA did a waterfall project – should they avoid using MongoDB because it is more modern and hence only fit for agile ? The line of thinking itself is ridiculous . Now substitute MongoDB with low code tool of your choice and the silliness of that argument will be even more evident.

Second – between Waterfall and Agile is squeezed “there were vendors that claimed they could build you everything you needed into one package/stack” . I don’t know what to make of this. Incidentally, those solutions – like say SAP or SFDC – also can be implemented in Waterfall or Agile. It is a terribly illogical way to segment it on par with Waterfall and Agile.

Third – Agile has not failed universally. Poor execution of agile leads to failures as I called out above in the links to my past blogs.  But there are plenty of Agile success stories all around us. Since we already used SAP as an example – they deliver their product using Agile and so does SFDC and Workday and so on. So the fundamental premise of the title itself is flawed.

Now back to the idea of low code itself.

The principle of low code is a VERY good thing

Code has a tendency to become a liability the moment you finish coding. I am all for being a minimalist when it comes to coding. This is why engineers encourage re-use, why we establish frameworks, why we standardize tooling to the extent we can, why we encourage automation , why we like “shift left” and so on. In theory, I would expect low code based apps to be lower in maintenance cost.

We all like to do things better, faster and cheaper. Any tooling that promises that value is worth checking out. Time is precious for business and technology people.

And finally – there are only a small number of good developers to go around. Low code tooling goes a long way to mitigate this problem.

And yet, with all my positivity about low code – I think what the Unqork CEO is saying here is very far from reality today, and for foreseeable future.

You could build anything you can imagine without me needing to write a single line of code or generate code, because we think that’s also legacy. So the idea is to stop writing code, stop legacy. 90% of what any company does today, we could confidently do on Unqork without a single change today, without a single line of code. The last 10% is where 100% of their engineers should be building. Right I would say that that last 10% is purely APIs, interfaces that engineers are building that are unique to them

Low code is not new – we have lived through several avatars of this over the years. I remember SAP coming up with Visual Composer  something like a decade ago. It did not go very far. SAP was not the first – and things did get better over time. I am a fan of lighting platform that Salesforce introduced and it has several nice low code features. But even in salesforce projects – it is rare that 90% of the work is on declarative side.

Of course – history of failures is not something to worry about too much in tech. Tech usually improves with time .

A strong start to the low code story  does not mean it usually ends well

Time to market is absolutely a critical business driver today. Low code is a big help in proving out something as an MVP – as a prototype or pilot. If business likes it – great, and if they don’t you can throw it away with very little to write off. That is the good part. But that is not how this story typically unfolds.

Business will love the first version, especially the speed at which it got delivered. They will add a few more things to be done by the app. Most of the time – low code tooling can get that done too in record time. Then along the way – a high value requirement will come along which cannot be solved by the low code tooling . So it gets handed off to an engineer to enhance. This is where it typically picks up downstream momentum . There is a good chance that there is no way to make that enhancement without a significant rewrite. There goes time to market for a toss !

Mobile might be the hardest problem

Mobile is a harder problem to tackle than web. To get the best experience – I don’t think there will be a lot of debate that it is hard to challenge native development with generic tooling. Device integration, performance , Mobile UX are all hard to perfect without going native from what I have seen. If your experience is different – pls leave a comment, as I am very curious on this aspect especially.

Technical compromises just defer the costs

Low code ( and similar templated tooling that goes by other names) all are built with “general” requirements in mind. That comes with some obvious constraints – like the tooling expecting pre-existing APIs (in an enterprise world that is largely built as monoliths – or poorly designed/implemented APIs ) , some limitations in logic that can be implemented by drag/drop/click, and often performance limitations. That is the price you pay for faster development cycles. That is the price you pay with interest when your successful app gets asked to do more ! And if the tool can be extended – you have to ask yourself if it is “low code” anymore 🙂 .

There are indirect costs 

Low code also has some organizational costs that only become evident when you scale. A lot of the products are sold to business users with the promise “It is inexpensive, and you don’t need to wait on IT to get what you need – you can do it yourself”. Soon you have a proliferation of apps ( or reports or dashboard or whatever ), a lot of unused licenses/subscriptions,  and there is tremendous friction with IT ( traditional developers ) , and between business users. The typical solution – establishing a COC to “guide and govern” the low code system. Before you know – the COC gets bloated. And they put way too many constraints on governance (with good intentions usually) that the original time-to-value advantage is not true any more.

To conclude

I think low code tools absolutely have a definite place in the tool kit. It needs to be used for what it is good for – and that expectation should be clearly set with the customers who buy it. Over time, like with all technology – I totally expect low code to solve more of enterprise problems. But for now – I think claiming only 10% of scope needs engineers is an extreme overstatement.

It was August 9, 1999 when I left my home in a train for Mumbai with a suitcase I borrowed from my aunt . I was home sick within about twenty minutes into that two day train ride, but also very excited to join TCS as a trainee in their Borivali campus – called the “Nortel building”. Twenty years later – yesterday, in an elementary school auditorium in Casa grande, AZ – Dhanya and I, along with 245 other immigrants from 53 countries became proud US Citizens !

As the day of the naturalization ceremony was coming up, a lot of memories have been flooding through my mind.

Few months after I joined TCS, I interviewed with a client in Colorado Springs, CO to be a developer on an SAP project. A couple of weeks later – I was on my first international flight ever ; BOM-LHR-JFK , with the $200 TCS travel desk gave me, and with practically no knowledge of how things worked on this side of the globe. But I was sure I could do a decent job at work – and till date I think the three months of training I got from TCS was the most valuable experience in my life. I also made some life long friends from that time.

My first two experiences in this country were two extremes. The first was a guy outside JFK who tried to convince me that the taxi fare to Laguardia was $200 . He ran for his life when I walked over to a cop to verify the fare :). The second was a very kind lady who realized quickly that I was lost (and stressed out)  in the Denver airport – and took it on herself to call my manager and get directions on where I should go next. She yelled at him on the top her voice on the phone (he would tease me for a long time on what I did to him) , and then bought me a coffee and then walked away before I could even say a proper thank you. Till this day I believe she was an angel !

Most people who know me also know that I love Indian food. I have driven through snow storms for several hours in strange countries to find an Indian restaurant . When I first landed in Denver, I did not know how to cook – nor did I know how to find an Indian restaurant.  I was miserable. A fellow Malayalee who was a senior to me in TCS invited me home and his wife fed me an amazing mallu dinner. Angels come in different forms !

I also remember a colleague in Kansas City when I was working for Cap Gemini Ernst & Young . She had heard about the convenience shop owner who would go stand near his gun chest and stare at me every night I picked up a TV dinner on my way back from work. She started driving me there – paying no attention to my protests – and would stand there staring at the shop owner. Did I say angels come in many forms ?

When I started in consulting, there were not a lot of partners who looked like me that I could learn from . But then two senior partners – Ken Englund and the late John Leffler – took me under their wings and I eventually got to the executive ranks as well.

All those angels – these folks I called out above and many many more – far out number the evil I have encountered in my life. I have lived and worked in three continents, and this has been true everywhere.  I think these very kind folks are the primary reason I firmly believe in the idea of “Paying it forward” , loosely along the lines of what the principle of “Karma” teaches us. I don’t know if I will ever come anywhere close to what others have done for me – but I intend to keep trying.

For the first 6 years or so of living here – we had no intention of settling down here for good. The idea was just to make some money, gain some cutting edge tech experience, see a few places , and go back and live in India. But then the country grew on us. We had our daughter, our first dog, We bought a house, we made a lot of friends and IBM applied for my Green card. Just my luck – my application went into a lot of audits (including a court battle between the law firm that filed it with USCIS which they thankfully won). It took five or six years to get the Green Card. Another five years – more fur kids, changing houses and so on – we applied for Citizenship and finally got it yesterday. The legal immigration path is long and complex and it tests your patience. We respected the process and went through it – like many others – and it all worked out. I still need to figure out SSN updates, passport change and how to get an OCI card. But then again – I am sure the patience I gained through this long process will come to help 🙂

I am very proud of the country where I was born and raised. My love for my family in India, the schools and colleges I went to – and the teachers and class mates I had , my belief that there is no better cuisine than Indian food, my life long craze for Ilayaraja’s music, my conviction that Malayalam literature deserves more global recognition than it gets….none of that is ever going away.

I grew up in Trivandrum – where a the city center has a Hindu temple, a Church, a mosque and a fish market all right next to each other. I was born a Hindu. I attended a Hindu primary school, a Christian high school, a Muslim engineering college and a government run Business School. I am fairly sure if I ever counted – I have more Muslim and Christian friends than Hindu friends. Consequently – I am very secular in my belief system and certainly have no doubts that no religion is morally superior to any other. The idea that we are all equal and have the same rights – that is a deep rooted belief that India has ingrained in me.

Most years I get a chance to go to India for work and/or vacation. There is no feeling like landing in TRV airport seeing the shore line and endless coconut palms as the plane descends. I try to visit the local schools and colleges when I am there and share my thoughts, and engage in debates – something that I enjoy doing in US as well. I have some investment in India and I pay taxes for it. And like many other Indians who live outside India – I have always done what I can to contribute to help educate the children, fight poverty and help with disaster help whether it is in India or USA. Borders are important but ideally they belong to maps – they should not get in the way of doing the right thing.

When I finished my engineering college and B School – employment opportunities were scarce in India. That is not the case now. India is now a happening place and a fast growing part of global economy – even my sleepy old home town is buzzing these days. I often wonder if I would have ever caught that train to Mumbai if I got a good local job after college. If I grew up in the current Trivandrum – I probably would have never left . But that was not the reality when I was job hunting a couple of decades ago. And when I look back at the time I have lived in USA, it has been a huge net positive and fulfilling experience. So if I rewind the clock – I still think I would have taken that flight to JFK without a doubt !

The judge who presided over our naturalization ceremony asked us to stand up when each of our 53 countries were called out – and answer proudly one last time before we took the oath. It was a very emotional moment for me to stand up when I heard the clerk announce “India” – and I have no shame in admitting that tears ran down my face for a good few minutes. Later, after he declared us as Citizens,  he added “This is a diverse and plural country – you should be proud to continue your traditions and continue to speak your language as you live as US Citizens”. I believe those words were also from an Angel !

Thank you India, and Thank you America – you both made me what I am today, and I will be grateful forever !

Post Script 

Many thanks to all of you who sent your good wishes to Dhanya and me yesterday on social media – We really appreciate it !

I saw that some folks from India – none of whom I know from before, and only a small percentage of those who commented – got very offended on Linkedin that I said I am proud to be a US citizen . It is unfortunate that they leaped to an unkind point of view that my post meant that I am not proud of my Indian heritage, even though I said no such thing. Please be assured – that is not at all the case !

I also want to point out that I totally respect their right to voice their opinion – just as I have a right to express mine.  Thankfully the constitutions of both India and USA guarantee that right . I am not sure that calling me a Jackass is covered by the right to free speech though . I made my post in public domain, and I did it fully knowing that some folks who read it might not have empathy for the topic. There is a humorous and ironic side to the criticism as well – many of the “You are not a REAL Indian” crowd are employed at American companies like Apple, Amazon, 3M etc 🙂

 

 

This is one of those topics where my employer IBM has a vested interest and consequently I need to state upfront that what I say below is strictly my own views from my limited view of the large enterprise world. My personal experience over the last couple of decades has been in the very large company space. I have not spent enough time in small and medium companies to know their situation first hand. So please take what I say with a pinch ( or pound ) of salt . Also to preserve friendships that I value, I am not going to make any statements on specific cloud vendors. 

For once, customers led and vendors followed . 

I know several commentators on social media call proponents of multi cloud as snake oil salesmen. What they conveniently forget in this case is that multi cloud is a reality and vendors woke up to it late and smelled the coffee. In the large company space I am familiar with (granted it is a small set – but also the set that everyone else eventually tends to follow in enterprise IT)  – I cannot think of even one that does not have several cloud vendors they work with at some scale. Most common pattern that I have seen is their own private cloud, one major public cloud and then a few others at negligible scale (often brought in via developers trying out new things). In a few cases, I have seen two public clouds used at scale – commonly as the result of some corporate M&A activity .

In short, multi cloud is a reality today – not some futuristic idea. As Eagles crooned – You can stab it with your steely knives, but you just can’t kill the beast. Every company struggles to manage it (Most cannot even monitor – let alone do some active management) and that is why vendors are on the job trying to solve it.

I don’t know why, but now I am now humming We didn’t start the fire 🙂

Multi cloud for Bursting / cost arbitrage – no one does it well…yet

While in theory – a lot of people would like to be in an ideal world where workloads can be sent intelligently to execute wherever it is cheapest to execute, that is still enterprise utopia. Even in the simplest case of your own private cloud and just one public cloud – seamlessly moving most of your apps from one to another is not easy to pull off . The two common use cases are when peak compute is required – like when month end closing happens, or thanksgiving sales happen , and when disaster recovery happens and you want massive fail over to happen to a different public cloud . You can do both  for well engineered applications today – but that is a very tiny part of the overall landscape, and won’t buy you much.

You can check out any time you like, but you can never leave !

(Sorry – the Eagles song just keeps playing in my brain in a loop).

In an enterprise with multiple clouds – the normal scenario is that data and algorithms don’t sit next to each other . One will need to move to meet the other when it is needed. Moving data is expensive – mostly because companies love to create data, and no one likes to delete anything . Unfortunately some data cannot move for legal or cost reasons, and some algorithms may not move because its vendor has no incentive to expose it elsewhere.

It is already true that you will need to do one-off extremely high business value solutions that need multiple clouds. It will only become more and more true in future. As an example, say five years from now (may be less)  – you may need a multi cloud scenario where a specialized solution that needs quantum computing from one provider, AI APIs from another and some good old algorithms from your own private cloud to manage enterprise risk.

The one off solutions usually don’t come with a lot of governance. So others will build little apps on all these clouds for other one-off solutions . Proliferation is more or less a given.

That was a long winded way of saying – multi cloud is very useful in adding significant business value ( since no one party will ever be the lone innovator) and hence you will use it. But once you are there – you are better off learning to live with it peacefully than just fight it all the time.

Containers are awesome – but only when used as intended 

Everyone wants to work like Netflix and Amazon. But the reality is that they all have massive baggage of applications that were built when cloud was not a thing. There is a massive fascination in the field when it comes to containers. I am a big fan myself. But if you look at how the move to containers look like today – you don’t need to be a genius to realize it is not used as designed. Most of the time there is no systematic refactoring done. Docker and Kubernetes are not silver bullets. I have lost count of how many times dev teams have overlooked security, performance etc in the quest to containerize everything.  Forget all of that – look at the docker image sizes in modernization projects and you will probably see a lot of them represented in GB and not MB ( and I bet you there are posters pasted all around the building saying lightweight images are what we are going for). If that is the trend –  the end result won’t look much better than just outsourcing your data center.

Got it – but what if we build our own management layer ?

Some companies have the ability to make significant investments in people and tech. They can of course attempt to solve the multi cloud management issues by building their own management layer. While it might help the first wave of hand picked applications to achieve utopian status – it is not without some long term pain.

The most obvious one is talent. There are only so many top engineers in the ecosystem and you need to recruit and retain them for a long time. And while top engineers love to build great new stuff, they don’t always fancy the maintenance of those cool things. So you will need to invest additional $ to keep it running and enhanced with high quality .

Then there is the problem of each cloud being unique. Over time better standards will evolve – but for now, if you want to build a framework yourself – you need to assume there is a relatively small set of common functionality that you can make use of. The rest you need to build into your custom layer, or offload to applications to do so themselves. I will leave it your imagination and level of optimism to extrapolate what happens next in each case.

So how does one proceed with multi cloud?

1 Invest in refactoring the tech, and be realistic on time lines. 

On an average – most large companies have only ten or twenty percent of their workloads that are cloud ready if you ask the question today. And that only means ready – it does not mean optimized for cloud. The best thing you can do is to invest the engineering effort to get your applications cloud ready.

2 Refactor the organization for the (multi) cloud world 

People are the make or break part of any transformation. Ask the hard questions – like can you manage DevSecOps that include your current private cloud and also one or more public cloud ? Have your governance process been refactored and will it be audit ready ? Have you budgeted for frequent re-skilling and attrition management? Does your platform team and apps team know what each other does and are there clear rules of engagement ? etc

3 Be a minimalist and work with the ecosystem 

As of today, I don’t think there is a pragmatic way to move to a low chaos multi cloud landscape without close partnerships with the ecosystem – including some partners you may fondly(?) call as “legacy”. On the other hand – you cannot work with everyone and get some place any time soon. So the practical way to do this is to choose a couple of partners to go deep with and try your best to influence their roadmaps and tooling to suit your goals. If you can resist the temptation – I would urge you to not go down the path of building your own management layer with great sophistication.

Parting shot

Every large company CIO that I know personally is a realist when it comes to cloud. Some may not admit their true beliefs in public – which is not uncommon, and not just about cloud either.  So I am an optimist when it comes to where multi cloud is headed.

I had a chance to catch up with an old friend this weekend whose retirement party I unfortunately couldn’t attend . He was a senior partner in a law firm .

He told me a story which I want to share here . This happened some 35 years or so ago when he was just hired .

As he walked into the office, he saw that all the partners were in a conference room with a very serious look on their faces . After an hour or so they called the office manager – a middle aged woman who had spent all her career in that firm – inside . She came back with a big file in her hand – and she was crying . She left office almost immediately , still crying . His first thought was that she was fired !

He ran into her at the train station that weekend and she told him what had happened . He bought her and her kids some ice cream and she explained the reason why she was crying that day .

She had an abusive stay at home husband who was blaming her for all his problems, and she couldn’t afford a divorce . Apparently one of the partners came to know about this from his secretary and he called everyone else into this meeting . At the end of it – all of them wrote personal checks of $1000 each (which was a lot of money at that time) for her , and gave it to her saying “You gave your whole life to this firm and you are family for us . We have this covered and we will represent you in your divorce case etc . Go take your kids on a vacation for a couple of weeks and come back and we will figure out what’s next”.

Some years passed and my friend was nearing his own partnership at the firm . The trouble was that while he was good at his job – he just didn’t get the kind of visibility to the three senior partners . He went to this lady for some advice – by then she was supporting one of the senior partners as his secretary .

She pretty much coached him through the process – including apparently what to wear , what restaurants to eat, what jokes to crack and so on . She also helped him get some opportunities to be part of important work that got him the right attention . In two years he made partner .

She retired soon after – and at her farewell party, she told his fiancé (and now wife ) “I will never forget your boy friend buying ice cream for my daughters as we waited for the train – it’s the nicest thing anyone had done to them till then”.

A few days ago, my friend Frank Scavo wrote about the pendulum starting to swing from commercial software to custom built software .  Today morning, I listened to his podcast with another common friend Den Howlett .

I would highly encourage you to read Frank’s blog and listen to the podcast. The movement to DIY is real and I am seeing it in the field too. It is something I have wanted to write about and now is as good a time as any. I would like to focus on just a few aspects I have seen as critical to the success of custom building software at scale.

Do you have the right BRAND  to attract the top engineering and product talent ?

There are not a lot of talented software engineers to begin with. Attracting those few good people – be it a fresh CS grad or a veteran developer or product manager – to your company takes a lot more than throwing a lot of money at the problem. Your company may be the best retailer, or bank or automobile manufacturer on the planet.

Do these engineers you are trying to hire know of you as a place that works on cutting edge technology – and all that comes with it like great techies as your colleagues, modern work spaces, a thriving tech community and culture , cool perks and so on ? Do you have credibility in the market as an employer who invests in training people to keep up with the changing market ? Building that brand is real hard work and it takes significant time and investment . It is not a commitment you can make lightly.

Do you have the endurance to move from a project culture to a product culture ?

I have already posted my misgivings on IT shops using agile and scaled agile , so I will spare you those here. But in general – what sets apart professional software shops and rest of the world is the focus on products as opposed to projects. That is a culture shift that won’t happen without a lot of painful – and continuous – change management effort. Hiring has a direct influence on the culture .

The two largest pools of talent are other IT shops (commonly people jumping for better roles and $$) and SI companies ( commonly people who may even be willing to take a small pay cut if need be, but want to get out of their road warrior lives)  – both largely made of people who come from a project oriented background. May be ten years from now, this won’t be an issue – but today it is a definite issue.

One more thing while we are at it – If your team is global, are you willing to make the remote teams self sufficient and fully empowered and not just order takers from HQ  ?

Will your cutting edge team have the staying power?

If you are modernizing your IT function to enable a largely DIY culture – your economic model will probably need teams to be self sufficient on dev and ops, as opposed to one team having all the fun developing cool stuff and another doing the grunt work supporting it and answering the pager.

Will your software engineers hang around long enough if they are woken up at 3 AM by their buzzing pagers ? Do they have the skills to continuously automate ( the SRE types ) ? As you build follow-the-sun teams across the world – will your engineers have the skills and patience to work with people who are across time zones ? As you become more geographically distributed – will they be ok being further removed from the users for whom they are building software ?

Do you have a stress tested strategy for talent pipeline and IP protection?

Just as you want to build an awesome team, your competitors want to do exactly that as well . It is a lot cheaper to pay more $$ for your top tech talent than identifying them early and grooming them for a long time. Even if you are an amazing employer that checks every box, you have to assume a certain level of attrition.

Hence there are questions to answer about the supply chain for talent all the way from entry level to top levels in every geography that you operate. If there is anything more painful than attracting top engineers – it is in recruiting a top notch tech recruiting team and letting them do their job (often radically differently than what you have done traditionally).

Can you balance fun and discipline in engineering ?

Software development is not traditional engineering – developers are more artisans than engineers. On the good side, you will have plenty to choose from their creativity. On the not so good side – only a handful of engineering managers can balance it and eventually ship on schedule. Every good engineering team loves to create and evangelize their frameworks – and what they probably love even more is tearing down everyone else’s frameworks. I am as guilty of this as the next guy or gal.

The battle of frameworks goes like this typically – a new manager notices his teams are using 4 different frameworks . He brings them together and after a lot of debate they agree on a common framework . A few PIs later they find that they now have 5 different frameworks.

Needless to say – you need strong engineering managers, and ideally they are not repurposed from another function to fill a role.

So, can it be done ?

Despite all these uphill challenges – all this can be accomplished and to various degrees I have seen some companies do a decent job with modernizing their IT based on a DIY set of principles. I personally don’t know anyone who is still not struggling with it. The ones doing it better than others are the ones with extremely strong CIOs with the full backing of their CEOs (which is not common), and their boards (even less common).

I bought this book on Amazon Prime to read on a plane ride last week to Austin, and the round trip was all the time I needed to finish it, that too at a leisurely pace. I loved Walter Isaacson’s take on Steve Jobs when it came out and expected a similar in-depth treatment on Tim Cook as well. Considering the fact that Kahney did not get to interview Cook in person, I think this book does as good a job as possible under that circumstance.

I knew very little of Cook’s early years – except that he was an IBMer for a while. The book gives a great view to his upbringing in Alabama and ties together the themes on how his early years influenced his world view quite a bit.

The book paints the picture of a very talented Cook rising up fast at every employer he worked for – and yet never taking the lime light. The contrast is stark – he stayed in the shadows of Jobs when he was COO. And then when he became CEO, he had no trouble dismantling quite a bit of what Steve did at Apple. That takes a lot of bravery given the cult following Steve Jobs enjoyed – even after his death. People I know at Apple have confirmed this time and again that the culture has shifted significantly under Cook to a more pleasant, humane and charitable one.

The million dollar question in every reader’s mind is who has had more influence – Jobs or Cook ? This book makes a good case on why Cook was the better CEO for Apple, based on the financial performance ( which in turn is because of better operations under Cook), more fair employment practices, green initiatives and so on. Cook does not get much credit as a product guy – and only time will tell. His two major initiatives are Apple Watch and the secretive(?) Apple Car projects. Apple Watch has taken off and I bet it will go from strength to strength (already bigger than the swiss watchmaking industry) with the push on healthcare fronts. Car – the book indicates is a failure. If we draw a line today, of course Cook cannot hold a candle to Jobs on product front.

All that said – the book makes a very strong case that Cook is a significantly better human being than Jobs. Jobs had no issue with lying, and he would never apologize for his mistakes. Cook on the other hand have very high standards for himself and he holds his team accountable for that.

As much as Cook cares deeply about Ethics, fairness etc – he is all about the business first and foremost. This becomes clear in the book from the wide gap between his talk on diversity and his actions on filling Apple’s board and senior executive team with mostly white males. He won’t risk disrupting what is in place today. He does deserve credit for significant effort and investment in STEM education and other initiatives to have a better entry level pipeline. Can’t blame him too much though, to be fair – what he has done so far is significantly better than most other CEOs.

While his stance on diversity can be questioned, his initiatives on cleaning up Apple’s act when it comes to their Supply chain partners is commendable. Of course we can argue that Apple can do more and should do more. But on a relative scale – Cook has not only made Apple a better company, I think he has laid the groundwork for the industry to be a whole lot better as a collective. Not a lot of CEOs can claim that !

The book covers in great detail his strong stance on not compromising privacy of his customers – especially with the FBI request for a backdoor entry to phones. That is admirable and is one of the parts of the book that I enjoyed the most. To do this in silicon valley when FB and Google and others all thrive on convincing customers to trade privacy for convenience is beyond admirable. Kahney paints this picture very well indeed.

I would definitely encourage you to read this book

 

 

 

Scaled Agile has the status of a religion in many tech shops I know. Like with religions – its followers express unquestioned faith, intolerance for other ideas (Waterfall is the devil, EVERYONE should be trained in SAFe), and its praises will drown its criticisms (its not a problem of the framework –  you are just too dumb to use it right) , and a whole branch of philosophical discourse seems to have developed around it ( its a way of life, its a culture, Its a journey and not a destination….) , and people who won’t know a CI/CD pipeline if it slapped them across their face have turned into its evangelists.

To be fair – it does work quite well at several software development companies. And on paper, I think it says all the right things. Actually the main diagram on the website is quite comprehensive and thoughtful and I like it. I go back to it when I have to debate my views and its quite useful to remind people on the principles .

My views here are not about the theory – they are just about how I seen it practiced. Now – the trend is “every company is a tech company”. That may or may not be true – but I can say with some conviction that the IT organizations of most of these companies that have embraced SAFe have not figured out how to do it efficiently and effectively.

Let me touch on a few things that are glaringly obvious

PI Planning. 

A good part of SAFe education is about explaining how the process differs from waterfall. But if you look at how it is practiced in real life – especially if you sit through a few PI planning sessions – you most probably will walk away wondering if all that education was wasted. Lot of PI planning sessions scream classic waterfall project planning. While the intention may be to explore “WHY” , the actual sessions usually are debates of “WHAT” and “HOW” – which obviously bleed into the sprint planning and execution too. Also – while conceptually the intention is to agree on goals, in reality most of the agreement is on actions. If you are deciding upfront for next few months – are you truly in continuous discovery mode you set out to do ?

Structure and Process trumps Autonomy and Agility 

Agility needs autonomy. And for a dev team to be autonomous – they need to be close to the people who actually use the product. How many engineers actually even see a real user and know first hand what outcome is best for them ? How many engineers only talk to ONLY their managers and product owners ? How many roles are needed to get SAFe to work – and are they helping or hurting agility in execution ? In practice – most of what seems to happen in the place of “product thinking” is classic project thinking, which is about tasks done within a specified time line. I think SAFe definitely helps with top down communication quite well given it is built with the traditional pyramid in mind. But is it helping back and forth communication with users ?

Deliver on cadence, Release on demand 

This is the part of SAFe I personally like the most. But I very rarely see this happen that way in the wild.  What does happen most of the time is that “deliver on cadence” works reasonably well – and that satisfies management because predictable rhythm helps measurements . But there is little to no ability for a lot of teams to come close to “release on demand”. Its not that teams don’t want to release on demand – but that will need fundamental re-engineering of what was done in the past. It takes time and money and specialized skills – which often don’t show up in abundance . And since rhythm of development is what gets rewarded, the “release on demand” dreams are kicked down the road .

Engineering maturity, or the lack there of 

I think several companies have rushed into SAFe without investing in sound engineering practices first. So while speed might look to have increased overnight – there are a lot of holes to be poked on value generation.

If I am king for a day – I would prioritize instituting solid engineering principles over teaching agile and SAFe. Once you have a strong engineering foundation, Agile works really well. Maybe SAFe will work really well too. But if you don’t have strong engineering capabilities –  all that agile does is to accelerate creation of terrible code that future generations will curse you for.

How do you collect and organize requirements ? If you do a sprint for requirements – then for dev – and finish with a sprint for QA, do you call that Agile or Waterfall ? Just asking for a friend 🙂

In the name of “engineering fun” or just pure incompetence, have you ended up with more anti-patterns than patterns in your code base and now trying to work on making it awesome with SAFe ? Are you comfortable with introducing a shift left culture given where you are ? How is your test coverage – are you certain you are not just testing the same thing ten different ways ? How well do your teams conform to frameworks or does everyone do their own thing in the name of speed ?

In the interest of speed, is Ops compromised ?

The unsung heroes in the tech world are my friends who focus on Operations. A lot of the conversation has always been about how the Dev side of DevOps works. But when the pager buzzes at 3AM – in most shops, it is usually not the developer that wakes up to log on and find what went wrong.

The lack of engineering maturity expresses itself perhaps the most strongly when apps fail. You cannot stop technology from failing – but you can and should be able to minimize the impact and make it easy for users to not be affected for too long. That cannot be an afterthought – it needs to be designed for upfront and operational sturdiness has to be a first class citizen for all development. What is the reality in how backlog gets managed – where do you find “observability” in the list ?

Where to from here ?

I started this as a rant on SAFe – but I think the solution is not about a focus on doing SAFe better. I firmly believe a “back to engineering basics” is where the most value is for most companies. Once you have a grip on that – I think the execution methodology will take care of itself for the most part.