Culture (mis)fit


“Culture fit” is probably the most overrated and overhyped requirement during talent acquisition.

Does this mean we are looking for clones of ourselves and colleagues to join the firm?

Can such talent really bring unique value and new dimensions to the organization?

Probably not.

Why don’t we actively seek out “Culture misfits” who have different opinions and ways of thinking from the current culture?

Isn’t it possible that combining these “misfit opinions” with existing thought will create more value for the company?

Misfits are not (and should not be) jerks, they simply have strong and different opinions on how things can and should be done. This promotes divergent thinking within the organization.

This brings us to the subject of diversity. In my mind diversity should not be limited to demographics (gender, age, ethnicity etc.)

Companies should focus more on cognitive diversity than demographic diversity.

Demographic diversity in an organization should ideally be a by-product of striving for cognitive diversity.

The goal of diversity should be to fuel innovation and value creation through diverse thinking.

So don’t just look for  “normal ones”, also look for the “crazy ones, the misfits…”




General, Strategy


Speculation is something I highly recommend as a form of personal/career development exercise. It has the ability to sharpen your thought process and drives you to come up with your own future view of the world.


At the beginning you would probably suck at it, but with practice you will be amazed at how good you can get at it. After all speculation is free! (at least initially)

So what should you be speculating about?

Well, like me you could:

Speculate about the economy (e.g. what is the biggest FDI area in the next 5 years?)

Speculate about your industry (e.g. who will win the cloud wars? AWS, Microsoft, Google?)

Speculate about other industries (e.g. when will autonomous vehicles be the norm?)

Speculate about the next disruption (e.g. when will all major banks trade Bitcoin?)

Speculate about your company (e.g. where are your next customers likely to come from?)

Speculate about your career (e.g. what is the impact of Data Science to your career?)

…and the list goes on.

Some personal guidelines I follow on speculation:

  • Speculation should be un-emotional, just look at the current context and figure out where something is heading.
  • Try and figure out how your speculation of a certain area would affect you
  • If your speculation is strong, adjust and adapt yourself to take advantage of it
  • Be judicious when making big changes/bets based on speculation (remember sub prime loans and the financial crisis?)


General, Technology

User Experience and the Locality Principle

Designing a great user experience (UX) for complex business software is non-trivial to say the least.

Screens with complex functionality along with large amounts of data in such systems do not make things easier.

One of the key elements of good UX is making it easy for the end-user to find “things” in the system that is relevant to her.

This is where I think the Locality Principle comes into play.  It’s a well known principle in computer science and has implications in memory access optimization.

So what does this principle tell us? To keep things super simple have a look at this video which explains the gist of the principle.

Now how do we apply this concept when designing user experience (UX) in business software?

End-users of a business software system would typically work with (or “reuse”) a relatively small set of data (and screens) during a given time period. (e.g. during a business week). Therefore the information they search for and work with during this period should be fairly predictable.

If we can build some “intelligence” (short of AI 🙂 ) into these systems to identify  information access patterns of users in the system, we could use that “intelligence” to suggest the next possible interaction on the current UI for a given user. This would alleviate the need for the user to “find” the next screen to work with in the system and make it easy to “jump” between screens.

It must be noted this is more richer than “Recent Screens” functionality, which merely puts the last used screens of one user in a stack. Think something like Amazon Recommendations instead.

So the idea is simple, we should leverage the principle of locality in UX design to figure out the next information requirement (e.g. next screen) based on users previous UI interaction patterns


Management, Strategy, Technology

What’s the Chorus of your Product?

After listening to a song you like what part of the song plays over and over in your head?

What part of the song do you keep on singing in the car to work or in the shower?

What part of the song do you hum to your friends when telling them how great it is?

It’s the Chorus!

The chorus of a song gives it a unique identity. It is the most important ‘feature’ that makes it different from other songs. It’s USP.

So what can the software industry learn from the music industry?

Let’s first have a look at this fascinating video (starts at 0:15) of how Sia comes up with a new song. (in fact it is the inspiration behind this blog post)

The cool thing to note here is how she mainly focuses on identifying the chorus and getting it to sound awesome, even without any lyrics.

So if you are building a consumer (or even enterprise) software product make sure you identify it’s Chorus, the feature that makes it unique. Then focus most of your effort and resources on it to make your users fall in love with it and talk about it with other potential users.

It’s amazing how we can stimulate product strategy in our own industry by looking at other almost unrelated industries. The key is to not isolate your knowledge to your own  industry alone but widen it to other industries and try to draw parallels that will help with your own strategy.


Strategy, Technology

‘Time to Value’ should be the new ‘Time to Market’


It’s fascinating how the software industry has built and leveraged technologies that could deliver software products of good quality at amazing speed.

The key technologies (in my opinion) that enables such speed are:

Cloud – Fast and Reliable distribution channel for software.

Microservices – Smaller units of software that can be developed and deployed independently and ‘quickly’  by two-pizza teams

Containers (e.g. Docker) – Making sure that the software (primarily microservices) have a reliable and consistent environment to execute.

Software vendors should now focus on how fast their customers can start extracting actual value from software instead of how fast they can get their software products to market.

Time to Value should be the new Time to Market!

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.

Architecture, General

Architects are trade-off evaluators

Most software problems have a finite set of solutions to choose from. An important role of an architect is to understand the trade-offs of each solution and decide on the best solution for the given business case.

Image credit:

For example, one solution to a given problem could be less performant but may result in a clean and maintainable codebase. The job of the software architect in this situation would be to determine whether performance or maintainability is the most important aspect for the problem at hand. The compromise reached should always be in the best interest of the software product.

It is important to document the reason for picking a particular solution along with it’s trade-offs for future reference. Software people are notoriously forgetful of their design decisions after a few days 🙂

As the saying goes, there are are many ways to skin a cat, the architect should find the best way to do it given the resources while achieving the end goal.