In this interview series on inspiring digital technology leaders, we take an inside look at how enterprise technology leaders make systems work in some of the largest and most complex business environments in the world. Meet the Individual, Understand their Challenges, and learn about Their Vision of the Future.

An Interview with Murtaza Kanchwala

Introduction

In this interview we hear about the challenge with balancing the need for good architecture and developing frameworks with the need for startups to move fast and get user feedback, and how the User Experience is the essential metric for product success. We also hear about a future where enterprises will build their businesses on complete stack cloud platforms, and will re-imagine the way they cooperate with data ownership and access to enable the power of AI and Robotics to help them compete.

Murtaza Kanchwala is a Startup CTO, with a technical background in large corporates, mid-size businesses and startups, working in enterprise architecture and product development, that has made him successful in bringing new and improved products to market in complicated B2B environments.

Murtaza has a practical approach to getting things done in the fast paced world of tech start-ups, whilst bringing his extensive experience with architecture in large complicated enterprises to help drive out the best practices that help start-ups become scale-ups, and to ultimately compete in the large corporate space.

Bitesize Takeaways:

Build a great culture, to build a great team, to build a great product
You have to move fast when working in startups
Intelligently cutting corners can aid short term issues, but isn’t sustainable
Get people invested in what you’re doing to make things really happen
Using a Framework can massively reduce your engineering effort
Most expensive failures come from team issues & poor estimation
Complexity of software makes support expensive, and changes difficult
Architecture upfront avoids major refactoring or even complete rewrites
Enterprises can be so complicated, even they don’t know how they work
Deliver smaller, incremental pieces of your solution to succeed
Architecture must be a core practice, not a gatekeeper or afterthought
The future will be cloud based, service oriented, platforms that all enterprises use to build their systems and business operations
Data Ownership & Sharing is going to be key for AI and Robotics

Meet the Individual

Q: Tell us a bit about what you currently do:

I’m a CTO currently building a startup in the FinTech sector. On a day-to-day basis I’m responsible for the product management and engineering team, and mostly involved with the Product Roadmap, the High Level Architecture, Sprint Planning and Development Quality.

Q: What motivates and inspires you to get up and go to work everyday?

I think it is essential to believe in the product and company you are building. And this comes from really caring about the User Experience — how are we going to change people’s lives with what we’re doing? This is what really excites me, and what I aim for the whole team to be excited about. We need to believe in the product to do it right, and we can only believe in it, if we know it will help our customers. We reduced our focus on firefighting and cutting code, and have put the customer experience question at the centre of our work. I also really enjoy the social aspects of building a team and seeing people enjoy where they work.

Q: Tell us about your journey to get to where you are today?

I come from a development background, with the likes of COBOL and C, and went on to implement ERPs like JDEdwards, SAP, Oracle and Siebel. From there I organically grew into a systems and solutions architecture role, where I was mostly technically focused. I later moved into Information Architecture, which I really enjoyed — both working with the data models and the more technical aspects of data migration. I then decided I wanted to move to a product company, where I joined a Logistics Software company. They had a legacy product, which was 16 years old, so I had to use all of my product management skills to make a success of it. I found that I really enjoyed this world, and decided I wanted to get involved with startups in the early days and build something from the ground up, which is something you rarely get to experience when joining later stage companies.

One key learning from working in startups is that you need to move fast, and don’t worry about whether you have the complete solution all planned out, or whether this will be the final result that gets product/market fit — you just need to get something out there ASAP to validate it. A startup is exciting, but also quite challenging. I found that after 20 years of working in large corporates where they focus on safe and predictable delivery, this new way of working was quite a change, requiring quite a different skillset.

Q: Which roles were the most pivotal in your career path?

There were three:

As a trainee programmer in my early days with a Media company in Australia, I was given a chance to revamp the whole debit/credit note system. It gave me exposure to a lot of things, how to talk to the business, how to manage requirements, even how to architect the overall solution. This was a great start to the early days of my career.
As an Architect at a Telecoms company, I’m particularly proud of the architecture of the asset management system, and the relationship management involved in dealing with the police force when designing and deploying the solution. Most pivotal point for me was demoing the software to a large audience of officers at the police headquarters. Despite being a bit nervous when I started, I soon got into the swing of it, and by the time I had finished I realised I had overrun into their lunch hour. The most rewarding part about this is that nobody had left… apparently the officers were so interested in what we’d done, that they were happy to give up some of their lunch break.
As CTO at a Logistics Software company. We developed a mobile application framework. The dream was that we could create a mobile application framework that helped us build complex workflow UIs with simple drag and drop and a couple of JSON configuration files. When we started building the prototype we did it in three months, and got the product out in 6 months. What used to take use weeks or months to change a flow on the UI, now took hours or days. This made customisation for our customers so much easier, and gave them a lot more options in how they adapted the app to their needs.

Q: If you were to do anything other than what you do now, what would it be?

Mentor engineering and technology graduates in their final year before they join the real world
Use Technology to help the special needs individuals of this world live their day-to-day lives
Probably get into teaching
Learn about forensic computing and LAW

Understanding Their Challenges

Q: What do you personally spend most of your time dealing with?

Since I’ve been working in startups, I spend a lot of my time making sure that the day to day of the sprints and delivery are working fine, in somewhat of a SCRUM Master role, as well as researching technologies, strategies, architectures and of course competitors. When I was working in more mid-size organisations I would spend more time looking at strategy and board alignment/engagement, as well as team management and motivation.

Q: What is the most important thing you focus on to make the organisation successful?

The most important thing is fast delivery of the product to the user, whilst ensuring that the quality of the product is also a priority — is it stable, robust, fast for users — and not far behind is the ability for the operations team to manage it once it is released.

Something that we really find difficult is getting User Feedback — this is always a bit more challenging in the B2B world, as you need to get the right people, but this is not always easy. We try to meet them face to face as much as possible, and run through their day to day activities and see where they are having difficulties, or where they have ideas to improve the product to make their lives easier. We’ve tried using community forums, but these are not as effective. This is a particularly difficult challenge for startups, as more established businesses have a larger community to leverage.

Q: What are the most expensive mistakes you have seen made in organisations, and how did they happen?

The most expensive failures have come from problems with the team and time management. It can also be software if not managed properly.

For example, a huge mistake is hiring the wrong people for the wrong job. You usually start off thinking that you have the right team, but it is often quite late on when you realise that you haven’t and by then problems are already snowballing.

The estimation process is usually a problem, and is more often a problem in mid to large size companies because startups tend to be more agile / adaptable to changing environmental changes, so you get feedback on whether you are on time faster. In bigger companies, you commonly have a larger monolithic process in place to create and manage the estimates which are disjointed at different levels of the planning, and more often than not have no appropriate checks in place to ensure that things are happening as they are supposed to. So quite late on you realise you are not really on track, or that the devil in the detail has increased work efforts on certain tasks, and you are not going to make it.

I’ve experienced these problems in all the companies I’ve worked in. There are different types of team issues. One is the right skills, one is the right culture, the other is the right person. The most important thing is fitting in with the company’s culture. If you don’t have the right skills, you can always train them, but if they just don’t fit in with the culture it will always be an issue. Also important is that the person needs to be flexible and open to change so that they can adapt to things going on around them.

Q: What drives the complexity in your Enterprise Systems?

From startups to enterprises, the main problem is the understandability of the software and the delivery process — no processes, a lack of documentation etc. We run fast and cut corners, then when we start scaling up, and new people join the team, they don’t know how things work and can’t get up to speed easily. This takes a lot of time to remedy and limits how quickly we can scale or change the teams without creating problems with the software.

The challenge for Enterprise Software is mainly the complexity of the architecture, which ends up mostly affecting how easy it is to operate, maintain and change it over time.

One cause that is common for larger Enterprises is when companies select large brand name software (e.g. Oracle, SAP, IBM,etc) just because everyone else does — because it is well known — rather than based on their real requirements. It is very common for people in the same domain to follow each other — e.g. where Ruby becomes a the cool thing at some famous startups, everyone starts using it for their startup regardless of whether it is actually the right thing or not. This leads to all sorts of problems with the technology choice not being fit for purpose, and missing opportunities with other solutions.

Q: Do you think it is important to ‘do’ architecture?

I think it is very important to have architecture, even though this is often secondary or non-existent in startups — they just want to get on with building the product for validation and early market entry. Mid size companies also tend to focus on features and getting products out over designing things properly. In larger organisations it is more often set-up as a gateway of sorts where projects’ work needs to be filtered through, and that’s often where the problems occur — as it is usually slow and obstructive, but often doesn’t give enough clear guidance for projects to make things work. Even so, it is important for all companies, and absolutely essential at larger scale organisations.

Q: Do you think that the lack of architecture in the early stage companies, leads to problems when they grow?

Absolutely. I’ve seen many examples of this. It doesn’t mean that the lack of architecture is impossible to live with, especially with small startups, as most of the time they are looking to build a product that customers will buy and therefore investors will invest in, and to do it quickly. And only then will they plan what to do with it to make it viable in the long term, which almost always means a major refactoring, and usually a complete rewrite.

If you are going to grow and do more complex things then it helps to do architecture upfront, as you can support new features and requirements down the road more easily and it helps to avoid complexity.

Q: What are the most frustrating challenges when designing, building and managing enterprise systems?

Not knowing enough about how a particular enterprise works. Even having worked in a number of large complex enterprises, there are always things that enterprises do that are hard to understand unless you’ve been working in that exact organisation for a reasonable amount of time. So it is easy to make assumptions about how these businesses work which turn out to be wrong, because of some arcane undocumented process or practice that people follow in the day to day operations — and often is not understood well by their management team either.

The second thing is security. Enterprises want everything to be perfectly secure, and like to define a lot of standards to follow, which make it quite challenging for vendors and projects. But very often they don’t follow their own practices, so when you come to implement the security measures, the reality is very different, and this complicates the delivery. The main challenge is the lack of understanding of security and the realities and trade-offs that it brings.

Q: What has most helped to drive the success of your change programmes?

Buy-in from the business and the board / management team is essential. It is also really important to have the team on board too — they need to become invested in what you are doing and why you are doing it, otherwise it will probably fail.

One example is the Logistics Software company. It was hard to get the buy-in initially as they didn’t want to use the technology I was suggesting, and weren’t sure about the approach when I first suggested it, but with continuous work to provide evidence and guidance on how we could achieve it, things started to move forward and we managed to successfully deliver the solution. Without that buy-in, and the work to help them come to the same conclusion, we would probably have failed.

Q: What has most negatively impacted your change programmes?

The most significant negative impact I have experienced has come from sales. When the project is tied closely to the sales, and you can’t deliver to the needs of the sales promises, it can massively affect how the business perceives the technology products and delivery team, and can create problems for the whole business.

Q: How do you prevent or handle that?

When we fail we always go through a review of what went wrong, and as a team we can see how we could do better, and for me personally, how I can avoid making the wrong decisions again.

Based on those learnings, I think the best way to mitigate such risks is to create small chunks of the big solution, and see if those small chunks can generate sales and revenue. Then ask the sales teams to view these small chunks as products and to put a dollar value against them, so you can see what their priority would be. When we understand the dollar value, we can have a sensible conversation about where to focus, which will return the most value. If it is not about sales at that point, you can do the same for users — and measure which releases would gain you the most users. I think this really helps mitigate big failures, by creating smaller, more manageable pieces of work.

Their Vision for the Future

Q: What are the 3 key changes that Technology Leaders should focus in the modern world?

I think the most important things to focus on for Technology Leaders is Culture, Team, and Architecture

Culture has to come from the top. It has to come from the leadership, and has to be part of how you actually behave — so you need to lead by example. Google and Facebook show examples of how this can be done from the top to the bottom of the organisation. Even if you have a team working with you, you still need to be the face of the culture.
Teams: don’t make hiring focus only on the technical skills. You don’t need to worry so much about these. You and the team need to get on with the candidate, and get a feeling that they really care about what you are doing. Only once you’ve got this good team fit should you worry about skills. You can implement this approach through social activities in the interview cycle, where the person feels part of the team — e.g. we interviewed one candidate and invited him for drinks with the team to get to know him. You can then determine if it is a good fit for both of you. Because once you’ve done that, you get a kind of marriage between the individual and the company.
Architecture: In smaller companies, you need to get someone who is experienced enough to be able to drive the right architecture implicitly as part of the engineering. In larger organisations this needs to be an embedded practice, which is given enough autonomy and power to really change the organisation, not just push paper around. In one large company the chief architect decided to use Google Apps for the company, and they ultimately fired him because of it. A couple of years later they realised this was one of the best decisions the company had made during that time. The problem was that there was a lack of trust and autonomy — non-technical managers overriding people with technical knowledge and experience. Particularly in corporates, we so often see the architecture team wasted because they are sidelined and not given enough ability to really do things, which makes everyone think that they are ineffective, further reinforcing the problem.

Q: What is one thing about the future of technology that you believe in, but most people generally don’t know, or disagree with?

I have (and have had for a long time) a strong belief in AI and Robotics. Which I really believe is going to have an effect in our day to day lives at home and at work. We have this in our lives now, for example the Amazon Echo sitting next to you at home. I still strongly believe in this, and despite it becoming more popular in recent years, I still see a lot of people ignoring or dismissing this, even today.

Q: What do Enterprise Systems of the future look like?

Enterprises won’t own hardware anymore, everything will be in the cloud. The entire technology stack will be based in the cloud, consumed as services, and based on platforms that will be the foundation of our world. Enterprises will also become more agile in the way they operate — they will become faster at making decisions, and changing the way they work.

Data is also going to be key — especially with AI and Robotics. I think enterprises will be more open to exposing their information to providers, to give them more value on their data. I think the ownership of data will change in the future. Processes will also change — these will be more agile and flexible, and you will need more control of these processes over enterprise boundaries.

Murtaza kindly provided his time, knowledge and insights in this interview as part of my research for an up-coming book: Mastering Digital: how technology leaders, architects, and engineers build the Digital Enterprises of the Future

You can contact Murtaza on LinkedIn.