Management, Strategy, Technology

The biggest challenge for “traditional” software vendors moving to a SaaS model is not technical

Image Credit:

Cloud Computing is probably¬†the longest surviving¬†buzzword in the IT industry for¬†the past¬†decade or more. From a software buyer’s point of view the important decision of¬†going for a “Cloud Solution” ¬†is based on economics, more specifically the¬†CapEx vs. OpEx trade-off. The pay-as-you-go nature of cloud computing is perhaps¬†the most important economic¬†feature¬†for customers.

Cloud computing has¬†three well known service models¬† IaaS, Paas and SaaS. Out of these, Software as-a Service (SaaS) is perhaps the most convenient model of acquiring IT for operating a business. ¬†The huge success of enterprise SaaS vendors such as¬†Salesforce¬†and more recently Workday¬†is evidence¬†that¬†many enterprise customers¬†are moving towards SaaS for software “procurement”.

These new kids on the block have prompted the “brick and mortar”¬†software vendors that follow the old model¬†of building software, burning it on a CD and shipping it to their customers for on-premise installation¬†to follow suit. These vendors are now¬†making their software more architecturally and technically cloud friendly. What¬†this usually means is that the software is now runnable on cloud infrastructure (IaaS) like Amazon AWS or Microsoft Azure.

Now building software that is more cloud friendly is one thing, but actually moving towards a true pay-as-you-go SaaS delivery model is a whole new ballgame for the traditional vendors.

I think the biggest challenge for existing non-SaaS vendors is not technical but its rather about overhauling their business/financial model. When moving to SaaS, the customers who used to pay all the license fees upfront will now be using a subscription payment model. This means the financials (such as cash flow) of the company need to be looked at from a different angle. It may also affect how sales and marketing approach their roles since customer LTV (Life Time Value) is now a bigger concern.

Possible ways to overcome this challenge would be to partner with (or even merge/acquire) another cloud company and piggyback on their business model for SaaS delivery. But when choosing a cloud partner it would probably be a good thing to avoid another SaaS provider and instead select an IaaS or PaaS provider to avoid market share erosion due to conflicting products.

Another way to address this challenge would be to setup a separate business unit for the cloud SaaS business. This would enable all new customers to be directly part of the SaaS business unit while existing customers are gradually migrated.


Key Learning from the GitLab Incident

GitLab is an awesome product!¬†Although I don’t use their¬†hosted service at, I’ve been a very happy user of the¬†product in¬†an internally hosted setup.

They had a pretty bad (and well publicized) incident a couple of days back which started with spammers hammering their Postgres DBs and unfortunately ending up with a sysadmin accidentally removing almost 300GB of production data.

I can empathize (#HugOps) with the engineers who were working tirelessly to rectify the situation. Shit can hit the fan anytime you have a production system with so many users open to the wild internet. The transparency shown by the GitLab team to keep their users informed during the incident was awesome and required amazing guts!

Now most blogs/experts talk about the technical aspects of the unfortunate incident. These mainly focus on DB backup, replication and restoration processes, which are no doubt, highly valid points.

I’d like to suggest another key¬†aspect that came to my mind when going through the incident report, the human aspect!

This aspect seems to be ignored by many. From all accounts it looks like the team member working on the database issue was alone, tired and frustrated. The data removal disaster may have been averted if, not one but two engineers were working on the problem together. Think pair-programming. Obviously, screen sharing can be used if the engineers are not co-located.

I know this still does not guarantee a serious f*ck up, but as a company/startup you would probably have better odds on your side.

An engineer should never work alone when fixing a highly critical production issue.

Image Courtesy: Flickr (licensed under Creative Commons)

When trying to fix critical production issues in software systems its super important to have a aircraft style co-pilot working with you on the look out for potential howlers that can occur, e.g. rm -rfing the wrong folder.

There is always something to learn from adversity, Rock-on GitLab! Still a big fan.

General, Management

Product Passion

The most amazing thing to me about this video is not the awesome rocket technology or the brilliance of Elon Musk but the crazy passion shown by the SpaceX employees (including Musk) towards the success of the PRODUCT!

Product passion is a result of product focus. You don’t have to be Musk or SpaceX to have crazy passion for your product, you just need the culture and mindset from top to bottom.
Finally product passion fuels employee engagement and then everything else becomes secondary!

Tip from Basketball for Software Firms

Many times a software developer’s performance is judged purely on the number of “tasks” that he or she has completed. This can be the number of bug fixes or user stories completed during a given period of time. This would typically co-relate to the amount of code contributed to the product by an engineer during this period. Now this can be an important performance metric no doubt.

But in my mind software firms need¬†to pay more¬†attention to another important ¬†non-tangible metric when evaluating a developer’s performance…ASSISTS!¬†I got this idea when watching some highlights of this year’s NBA finals. In basketball, an assist¬†is when a player makes a pass to a teammate that directly results in a goal and points for the team. The number of assists a player makes in basketball is considered an important stat in terms of his performance.

Similarly in software teams, some¬†developers may¬†contribute in many “non-tangible” ways to assist other¬†developers in the team.¬†These can be in the form of architecture/design tips, suggestions for new product features, code improvements or even pointing developers to look at similar implementations in other areas of the same product.

Contributing to the team in such¬†ways is¬†a key trait of a good software engineer and software firms should have mechanisms in place to “quantify” (at least to some degree) such “assists”¬†made by team members. Project/Product managers and even architects¬†can play a key role in helping software firms identify the amount of¬†assists¬†that a developer has contributed during a given period when evaluating her performance. This is by no means an exact science but a “ball park” rating can be very useful.

Software engineers should also realize that their value proposition is not just about writing code but also contributing to the team goal in other non-tangible ways as well.

Look at¬†Steph Curry¬†for example he is not only a huge points scorer but also brilliant¬†in assists, that’s why he is MVP!

Management, Mobile, Uncategorized

Mobile is to Desktops what Startups is to Enterprise

Something that caught my attention when trying to understand good¬†Mobile UX was that many of it’s patterns can be applied to larger devices i.e. Desktops as well.

In other words if you start with a Mobile first UX approach you tend to remove the clutter and come up with a more “lean” UX that can be used on desktops as well.

But interestingly (or strangely) I see a similar relationship between how Startups are managed compared to larger enterprises.

Startups are managed in a very lean, less bureaucratic manner with a bias toward action. I think smaller organizational units (e.g. software project teams) within a large enterprise can also take a leaf out of the startup playbook.¬†¬†This is similar to how Mobile forces a leaner UX design by¬†removing “unnecessary” clutter.

Folks¬†in the enterprise environment may call this Agile but I think having a “Startup mentality” at a large organization is going even more further by¬†shedding as much clutter as possible and getting stuff done.

I guess SAP has already recognized this with it’s AppHaus concept.


Edge Case Bias

An interesting thing I have noted when pitching or demoing a software solution to a potential group of end users is something I like to call “Edge Case Bias”.

This is when your users provide feedback considering exceptional use cases that are rare and which usually have simple workarounds.

This sort of feedback usually sounds like “Nice solution! This solution works under the contexts A, B and C but *sometimes* we have situations like Z and this will not work then”

This bias towards edge cases by potential users is quite common but should not be just ignored mainly due to two reasons.

1. The edge case may not be an edge case after all
2. Ignoring the feedback may leave your users with negative feelings

In my mind product management is not just managing the product per se but also “managing” the users of the product.

So when considering the “A,B,C and Z” example above a reasonable approach will be to ask your users to come up with rough numbers indicating the frequency which A, B, C (covered by solution) and Z (not covered by solution) occurs.

Once you get the numbers and find out that “Z” is very rare and has a reasonable workaround you can easily convince the users that changing the solution dramatically to accommodate “Z” is probably not the best way forward.

Of course if “Z” is a high frequency use case then you may have to do some changes to the product. But from what I have experienced in agile development this is seldom the case.