Its my fault

A few days ago a very talented member of my staff reached out to me in a very disconcerted way saying that she made a big mistake that could impact a very important ongoing project. 

She chose to place emphasis on the fact that the mistake was hers and hers alone. She also made a deliberate decision not to point fingers at her team, external circumstances or anything beyond herself. 

The truth was that I was pushing for a very tight deadline, and mistakes are inevitable. In fact if we are not making mistakes it probably means we re not pushing hard enough.

What I heard from my staff:

  • I am aware of the mistake,
  • I have taken ownership of it,
  • I know what to do to fix it,
  • I am already fixing it,
  • I have learned from it.

The outcome: A few hours later the error was fixed and the innovative product she and her team had been working on was launched to the market successfully. 

Check it out here:

Being Technology Agnostic as a CIO

One of the biggest mistakes I have done in my career is falling on the tech bandwagon and making decisions based on what I thought the inherent value of a specific technology was. 

The raw truth is that technology is nothing but a vehicle to get somewhere. Sometimes throughout your journey you will need to take a bumpy old dirt road while other times you can take a brand new highway to get to where you need to go, in both cases they usually point towards the same direction. 

Many organisations never fulfil the full potential of the technology they already have purely because they are not ready from a cultural or operational stand point to execute. In most cases technology is not the problem, its just a distraction. 

I remember when running my digital agency when quoting for a project, most of the work and cost would fall into back-office development, very rarely the customer experience would be the main priority, as if the technology was always more important than the outcome it is supposed to generate. 

Things I ask myself when becoming too excited about any technology:

  • Whats the skill set gap and ask myself how long would it take and how much would it cost to change technology?
  • Does the technology have a proven record, any success cases?
  • If something goes wrong, do I or my team have anywhere to go?
  • Is there any documentation? Is it kept up to date?
  • Whats the effort if I chose to move away from it?
  • Is there a simpler way to achieve the same outcome?

Fundamentally every technology that is considered to be cutting edge today will be seen as legacy tomorrow. As CIO, technology, no matter how sexy it may appear to be is the last thing on my mind when creating a product strategy for my business.

Shared Risk Management

I wrote this post over 4 years ago while working for Laterooms. The idea was to publish it in Laterooms engineering blog but for some reason or another it never happened. The intention was to document the way we managed risk in an Agile environment and how the technique we describe and experimented with impacted delivery.

Problem Statement 

Our team was finding a great number of unmitigated issues mid-sprint that had not surfaced during sprint planning, not because the planning sessions were not being rigorous, but because risks were not being identified and mitigated ahead of time.

We needed to get a better understanding of what types of issues and to what degree they were affecting our progress. Up until this point, as a Product Owner I had owned our RAID, logging all of the risks and issues, qualifying them for impact and trying my best to mitigating them to the best of my abilities.

The more we got entrenched into Scrum, the more I realised this was an agile anti-pattern, no individual person is able to identify and mitigate a wide range of potential risks that affect a product team. Identifying and mitigating issues had to be made a collective goal, shared and owned by the entire team.

Qualifying Risks and issues

The first step was to make sure all of the risks and issues affecting the team were logged, by collaborating with the team, using our Systems Context diagram to map out all of the different systems surrounding the team we quickly realised that we had a lot more risks that we initially thought.

We now needed a way to qualify the risk and issues, so we decided to use a common scale that would allow us to overlap risks and issues with velocity, providing the a full picture of how RAID impacts the teams progress.

Improved Visibility

Our Risks and issues board is visible to the team at all times, we booked in a weekly stand up where the entire team goes through the risks inventory and assess the impact and probability of each risk.

When Risk Management becomes a shared activity, it is owned by the team and becomes part of the organic process. Teams get used to looking at the information radiator and begin to use it as an indicator of what is ahead.

We use our risk board similarly to what the Dashboard of an airplane, our dashboard gives us a visibility of any potential risks ahead of our journey giving us time and space to make informed decisions on what to avoid any potential obstacles/dangers that lie ahead.

We then surfaced the risk board in a burn down chart where X is the effort required to mitigate the risks, y is the estimated loss should the risk convert into an issue. The key objective is to use this tool to prevent risks from becoming issues that would inevitably hurt delivery. 


Unsurprisingly, shared risk management clearly showed that we have a lot more issues impacting progress than we thought. Most issues have dependencies that have been identified, since we now know ahead of time are, and how they impact velocity, we now know what areas we need to focus on.


  • Made all of the issues impacting the teams progress visible,

  • Surfaced risks that would have gone unnoticed,

  • Able impact of issues and unmitigated risks on Velocity,

  • Highlighted recurring areas where dependencies emerge,

  • Improved sprint Planning – Less unknowns,

  • Increased the efficiency of the mitigation of risks as they are identified when the probabilities still low. 

I highly recommend that you checkout the Laterooms engineering blog, particularly if you are interested in the implementation of Elastic Search
For further reading Elastic, the iCarAsia Engineering team has a great series of posts that cover how use Elastic Search to improve our consumer experience.

The Subtleness of Leadership

It is commonly said that a leader is born, not made, he possesses innate qualities that make him stand out and incite others to follow him, and while I truly believe that there is nothing that is unachievable, as paradoxical as this might sound, I have found that there is some truth to this.

It cannot be acquired through education: There are specific traits that are commonly found in people that are recognized to be leaders. These are not necessarily acquirable through education or even experience, and are usually very hard to pin point. They range from self-confidence, to charisma, character, and sometimes an undefined quality that somehow, despite everything pointing to the opposite direction, just makes someone stand out inspires people.

It’s can’t be given: Leadership is not a position nor is it a role, it cannot be appointment and it’s not a result of a promotion. A leader is born by an organic decision within a group, most of the times informally, other times it’s a conscious decision by a group to elect their leader.

In a highly technical team, you usually find that it’s not necessarily the most technically gifted member that will be the leader, usually it’s the one that understands the dynamic within the group and excels from it by recognizing his peer’s talent, cultivating it, and keeping group cohesion.

It must be driven by example: Respect is conquered, is not a given right, and it does not come with any role or position. If a team of developers has to work late to deliver a project the next day, it is the obligation of the leader to stay with the team , it doesn’t matter if in theory he isn’t adding anything to the project by being there, the reality is that his presence makes him part of the team.

Soldiers will follow to battle a commander that is leading besides them on the battle field, in the end, its not relevant if he is drawing swords or not, his presence is what truly matters and what inspires them