Professional Background

Technical Career

My very first role was as an analyst/developer on a front office government and corporate bond pricing and electronic trading system. Next, I worked on the bank’s analytics library so that it could value bonds, swaps, FX forwards and options correctly for emerging markets. With these roles, I really developed my C++ and C# expertise, as well as gaining some early leadership experience as a technical lead.

Management Career

Once I was promoted beyond technical roles into management, I was typically managing one or two systems and 5-50 developers, and I found that solution architecture, product management and project management skills were particuarly valuable. I also discovered that I had a talent for aligning software development teams with their customers.

In later roles, I was managing departments of 200-300 developers and testers, and I was responsible for many systems. In these roles, I found that stakeholder management and financial & resource planning were the most valuable skills.

Entrepreneurial Career

I chose to leave the investment banking industry because I felt I was missing the opportunity to learn about blockchain, cloud computing and machine learning, and I also wanted to experience something different in my work life.

I was approached by a hedge fund trading crypto options to build a platform for them, so a friend and I put together a demo platform, which eventually turned into a startup company, DeQuantifi, which was subsequently bought by another crypto technology company.

Working on this startup and as a consultant gave me the opportunity to bring my technology skills up to date, adding crypto, blockchain, Python and AWS to my skillset, as well as learning about the world of startups and capital raising.

Professional Philosophy

The following principles describe my approach to work:

Any Agile methodology (read my post on Agile here) should in theory facilitate the early and frequent delivery of value, but the principle often gets lost.

I like to deliver a lighthouse project first, whether that is a PoC, prototype, or pilot. What is critical is that this deliverable must add business value, allowing you to build trust with stakeholders. In my startup, DeQuantifi, we designed our system to have a spreadsheet interface so that we can deliver a working spreadsheet early on.

It is also important to write a business case with the help of a sponsor for larger investments, making the benefits clear and helping to get buy in for the project.

Again, this should be part of adopting an Agile methodology (read my post on Agile here), but is often dropped in the rush to deliver a project. There are two main areas that should almost always be automated, which are 1) testing and 2) deployment. 

For testing, unless there are already comprehensive unit and functional tests, I advocate a risk-based approach i.e. implement automated tests for critical code and key features, and utilise data from production incidents to identify vulnerable components. At DeQuantifi, we use PyUnit for unit testing and integration testing, and Selenium for functional testing.

For deployment (DevOps), a common problem is the time and hardware taken to build and test the system, especially if these have not been a consideration from the start and the infrastructure is not cloud based. In this situation, I recommend running a reduced set of tests for intraday builds, and running the full set overnight. If hardware is a problem, create a minimal deployment of the system for intraday.

Your team will be loyal and motivated if you can help them with their goals. I do this in two ways.

The first is helping them with their career. I do career coaching with everyone in my teams, and I make sure that I take an interest in their professional and technical development, helping where I can.

The second is to move obstacles out of their way so that they can deliver. Common obstacles are lack of hardware, missing development tools, distractions, and unclear requirements.

Another principle that I adopt is to adjust my management style and level of involvement depending on the level of expertise of a team member in a particular area.

I always give time and cost estimates to stakeholders as a range, with the range reflecting the level of uncertainty. I then explain the range using a list of risks with some estimate of their impact and probability. In some situations, I’ve used a Monte Carlo simulation to model the probability distribution for delivery dates.

Whilst this addresses known risks, some provision must be made for unforeseen issues. I do this by adding on overall contingency for the project.

Many development teams prioritise by going through hundreds of user requests with all their stakeholders in very long meetings. 

I take a different approach. I agree a set of principles around how to prioritise and then we prioritise. We then discuss only the things that we can’t prioritise with the stakeholders. The same goes for risk and issue management of the overall project. Only if budget or timescales exceed the parameters agreed with the stakeholders will we ask them to help.

In a group decision making environment, decisions are often based on who is the most senior or the best at arguing. This is time consuming and doesn’t always lead to the best outcome for the organisation.

It is for this reason that I get decisions made using data where possible. For example, this is one benefit of creating a PoC, prototype or pilot project. It is also a benefit of creating a business case.

I also like to create a balanced scorecard for the systems I am responsible for, which leads to a more objective discussion with stakeholders about how well we are meeting their needs.

This is the single most important thing I think about when writing code. Even if another developer never touches my code, it makes it easier for me to come back to months later. 

The reason I like this principle is because it encapsulates many good practices, such as giving variables meaningful names, creating a clean conceptual design, writing comments, and being consistent.

If your code is easy to read, then you can focus on the conceptual design in code reviews.

You can also get some insight into my work style through my Myers-Briggs Type Indicator®, which is INTP. You can read more about MBTI here.

Personal Background

Early Life

I was born in Irvine, a small town in Scotland, to immigrants from Bangladesh. My father was working as a doctor in a nearby hospital. We soon left Irvine, so most of my childhood years were spent in Worsley, Manchester. I have one sibling, a younger brother, who is also a doctor.


I was educated at The Manchester Grammar School and Clare College, Cambridge University, where I studied Engineering.

Family & Hobbies

I live in North West London with my wife, baby and dog.

I love travelling, and I’ve visited some interesting and exotic places such as Uzbekistan, Borneo and Nepal.

My wife is German, so we travel to Germany a lot, and consequently, I’ve developed an interest in German art and history.

I’m also a keen photographer, collect wine, and enjoy hiking, having grown up on the doorstep of The Lake District.