And Vijay Says…

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.

I am on vacation and woke up late and the first thing I saw on my phone is this news that Salesforce is buying Tableau . I – and many others – have predicted for a long time that Tableau would get acquired but several years passed by without that happening . And now that it has happened – I would like to share my initial thoughts . As always – these are strictly my personal opinions !

I think it’s a REALLY good move for both companies – so congrats to both sides . Well done !

Is the price fair ?

The most recent acquisition to consider as a rough compare is SAP buying Qualtrics for $8B . Considering Tableau makes a lot more $ every year than Qualtrics , the price SFDC is paying makes a lot of sense . The other one is Looker going to Google . I don’t think comparing what Google did is not the optimal way to look at this given Google already had a lot of functionality home grown and acquired , and just needed to close some small-ish gaps .

Tableau has always been considered over valued. Back in 2013, SAP publicly said so and many others said that privately over the years . I don’t know if SAP Lumira is still a thing – but I firmly believe it was best for SAP to buy Tableau at that time instead of trying to build a competitor product from scratch .

Who else could they have bought ? There are companies like Alteryx, Domo , GoodData etc that they could have bought and for cheaper too. But none of them are anywhere close to the kind of market leadership that tableau enjoys . It might even still be the case that alteryx might end up in Salesforce kitty for the right price .

But behind the scenes – a lot of big companies have had tableau as a target to buy for a long time . Benioff just proved to be the most decisive leader to pull the trigger – and bravo for that !

Is it good for tableau ?

I think tableau had kind of hit a plateau and needs fresh thinking on where to take the product next – perhaps also rethink licensing models for that matter . Microsoft Power BI is giving them a good run for their money in the market . I think this acquisition will be perfect for the team to get some fresh thinking – and maybe some fresh talent as well .

Is it good for Salesforce ?

Salesforce is the undisputed leader in CRM . And the key to customer facing tech is how great insights can be derived from the rich data and how those insights are surfaced to users to act on . Salesforce has been on that mission for a while – and with decent success – and having tableau in its fold will accelerate that mission . It should ideally reduce the custom work that their clients do today .

Cloud loves On-Prem !

It’s also worth noting that Salesforce – which is the poster child of cloud computing – is the most pragmatic enterprise software company . They bought MuleSoft not that long ago – which was a primarily on premise company . And now tableau too – also serving the on-Prem company . Tableau is leaps and bounds bigger/better than the cloud BI players . That pragmatism is one of the things that I love about this deal the most .

This time – with feeling

Salesforce has been dabbling with analytics and AI for a while but without great traction . Analytics – or more accurately visualization – is an ever green market . So it makes sense for Salesforce to get a significant market player into their portfolio . It doesn’t hurt that it helps with a significant revenue uplift too right off the bat . It also prevents tableau ending up with their big competitors .

Talent is already there

SFDC already has a lot of analytics talent – although a few good ones have left . For those that hung around and were reassigned to non data work – this is an excellent opportunity to get back to their roots and hit it out of the park . I may even venture a guess that some of the people who left SFDC might come back now given this acquisition

(Hi guys – will call you directly instead of calling out your names here. ) .

Integration is key

One of tableau’s strengths is its ability to connect to a variety of data sources – something that will come very handy once they are a part of Salesforce ecosystem . Next to simplicity for end users – ease of integration has always been the key to successful analytics !

New doors for Salesforce to knock on

On the go to market front – Salesforce has a great opening now to get close to the parts of enterprise they haven’t historically had direct access – like Finance and Controlling for example . That in itself should make the deal totally worthwhile in my opinion . I cannot think of a single large company I know of with significant Salesforce footprint that doesn’t also have Tableau deployed . I am tempted to wonder why they didn’t think of this sooner 🙂

Tableau is simple to use and solves a much needed visualization problem in an elegant way . It practically sold itself in a land and expand model in many companies I know of . They were brilliant in how they got to their current footprint in companies big and small . That trend will continue for some more time – and with a product refresh under new management it could pick up momentum – so even as a stand alone company, there is plenty of juice left for Salesforce to feel happy about .

Is it good for customers and partners ?

As with all large acquisitions, I expect customers to brace for impact on how the world looks like under new management for the products of the acquired company . I expect two different reactions from large and small companies ( of course as a generalization ).

I expect the larger companies to generally like this – because they can negotiate and rationalize and right size their licenses on both Salesforce and tableau , and hopefully reduce custom work on Salesforce over time . Of course we won’t know till joint roadmaps are fleshed out in detail .

For smaller companies – I expect a bit of grief in general as their first reaction . Smaller companies generally seem to like tableau more than they like Salesforce ( just from my limited view ). It’s not unusual – I have seen their general apprehension for all large vendors in the past too . I am sure Salesforce will gain their confidence quickly .

As for partners of all stripes – I expect a lot of cheering for this acquisition . Both companies have big partner ecosystems for their relative sizes and there is plenty of overlap . Generally that is a good thing when customers have lot more choice .