The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

“[…] every six to 12 months my job completely changes, and that’s required for personal growth”

The grass is always greener on the other side. Somewhere, right now, the CTO of a product company wistfully stares out the window, dreaming of the independent and exciting life of a consultant.

In another place, a consultant regrets the day she decided to do her own thing, and wishes that she could just focus on building a great product instead of managing sales, admin, and customer relations at her fledgling agency.

PensionBee’s CTO, Jonathan Lister has done both, so we asked him about:

• the main differences between consulting and product businesses,
• how to decide which path is the right one for you,
• how to use AI to improve productivity,
• how to excel at both consulting and product development.

Explore Jonathan’s unusual career and learn from his vast experience.

About Jonathan & PensionBee

PensionBee’s vision

Eric Ignasik: Hello, Jonathan. I know that you’ve been taking Japanese lessons – that culture fascinates me and I could talk about it for hours. But, right now I’m more curious about how difficult it is for you to find time for that considering your heavy workload.

I definitely don’t have enough time, but I’ve managed to keep a 422-day streak going on Duolingo. I’ve done about 25% of their content, so that’ll keep me going for a while.

Running a business is very stressful. I wanted to do something other than software engineering. Japanese seemed completely new to me, which was really appealing.

One of my favorite authors is Haruki Murakami. I found out that when he started as an author, he wanted to get away from the Japanese literary style so he wrote his first books in English and translated them back into Japanese. That inspired me to learn Japanese because it’d be great to read his stuff in the original language.

However, it turns out that his Japanese is particularly difficult. So far I’ve managed to wade through a short story.

You once said that PensionBee wouldn’t exist in its current shape and be profitable as a company without modern technology. Do you still stand by this today?

Modern technology makes that more of a true statement every day. When I say that, I’m trying to show that some businesses are not economically viable if you don’t use technology. 

Think of Uber, Amazon, or any company that’s relatively technologically advanced in that position.  Making that case in financial services isn’t always obvious. Financial services are labor-intensive and personalized towards more affluent people.

Using technology to broaden the market in which a business operates is exciting. It allows us to bring effective wealth management to a much wider range of people in the UK, and – since August this year – in the US.

Speaking of the latest technologies, do you think that the AI craze right now would also be a factor in putting the industry forward?

AI does a good job of helping people manage a large volume of unstructured information and does quite a few structured tasks on top of that. Research tasks are a great example, or helping software engineers code a bit faster because they don’t have to look stuff up all the time. 

AI might be able to generate genuinely new ideas in the future, but right now, it’s an opportunity to increase productivity by shortening the time it takes to turn an idea into a finished product – whether that’s a document, a software application, or something else.

It makes your imagination faster. In a lot of ways, that’s the bottleneck in productivity and in information management businesses. You’re not trying to manufacture something physical that takes a defined amount of time – you’re moving information to the right state. 

Have you implemented some form of AI, whether in terms of product roadmap or in terms of engineering tools at PensionBee?

For a while, I was skeptical, but we tried a few things out, like a business trial of the Google Gemini product, which was very disappointing. But every six months or so, the landscape seems to change. The generally available, reliable tooling seems to be moving forward quite a lot.

In the last few months, GitHub Copilot has been getting great reviews from software engineers. Many no longer want to work without it, so we’ve committed to using it as well. The ultimate metric with technology is adoption.

Another aspect is how to get AI into a product, whether that’s internal or customer-facing product systems. In financial services, the stakes are high. If you give people the wrong guidance, they might make a costly mistake.

Internally, we’re looking at customer service data. We get a lot of unstructured customer feedback: email, telephone call transcripts, live chat logs, Trustpilot reviews, NPS scores. It’s a large pool of information that we can tag and analyze manually, but that’s an enormous job. It would be a full-time job, but it’s not really economically viable to hire somebody for it.

With AI, you can dig into all of this automatically because you have the ability to interpret unstructured data and turn it into structured, labeled data. Then, you can do normal SQL queries and put dashboards in place.

In a similar area, we’re looking at how AI can understand some other unstructured data that we have, i.e. the digital footprint of executing business processes, and analyze that to look for bottlenecks and opportunities for improvement. That’s more of an R&D-style project, but still in that world of unstructured and structured data.

Overall, I think it’s fine that we’ve got computers that can suddenly be better at vertical applications. That’s a really valuable output from all of this research that’s going into AI. It is kind of frustrating as a technologist that the AI discussion in the media doesn’t embrace nuance very well. It’s either the apocalypse or utopia, but the reality in between is not really talked about.

Technologist… at your service

Your career path is quite unique compared to most of our guests on this series, and it has to do with you being a technologist, as you just mentioned. You’ve worked as a software engineer, you taught coding, but then you were also a technologist for hire as the Principal of Penrose Studio. What made you do consulting instead of going straight into a product CTO role?

People getting into technology today have more structured paths into technology roles. Every business wants to hire software engineers, and there are plenty of product companies where you can get your first experience.

When I was starting out, in 2005, I joined BT (British Telecom) on a graduate programme. Others were explicitly going into software development roles, and I went on a kind of management training course instead. I didn’t see myself as a software engineer, but I was still very interested in using technology within a business.

After a few years at BT, I ended up retraining as a software engineer by joining a small team and learning JavaScript. An amazing and rare opportunity to learn how to be a professional programmer within a tiny corporate team.

I left BT two years later and became a freelance JavaScript developer among the East London Tech City crowd. In 2009, that area had a lot of startups. We’d recovered from the dot-com crash and the startup economy had started to flourish. I was walking into a really interesting crowd where I could get contracts as a developer.

After doing that contract stuff for a bit, I’d started doing some projects with a designer/self-taught front-end engineer friend of mine. We ended up just having enough of a pipeline to start an agency.

We got more people involved and started to employ contractors, and that became Penrose. For a while, I had to balance that with my second job in a coworking business, Shoreditch Works, which is another area where my career path stopped being normal again. It was supposed to help expand our network and get more contracts, but the workload was too much. It became unsustainable, and we had to focus on the agency.

Kind of like Silicon Valley in London – the tech scene, the coworking, it all sounds exciting.

I saw a lot of early-stage product development happening. It colored my experience of building stuff. We became really good at building the MVP of a project with a shoestring budget. We did that through lean product management and agile development, just being really focused on getting the most out of every pound.

By the time the agency was around six years old, I met Romi, the CEO of PensionBee. That was really the transition point from agency style to product mode.

Shaping the product mindset

So, meeting Romi was the key event in your transition to a product-oriented role? 

After I met Romi, we were contracted to build the first year’s worth of product for PensionBee. But she was raising a seed fund, so we had to wait to start the project. While waiting, my agency partners decided to close the business down, and I joined Romi full-time.

She was very credible as an entrepreneur. And the pension market was very large, with few people doing anything vaguely modern in it. Pension companies are old-fashioned. There are good people in them that want to modernize things but institutionally, Aviva, Scottish Widows, Legal & General, they’re not moving with the agility of a startup.

I believe there’s 1 trillion pounds sitting in pension investments in the UK. Enormous market to look at when your business combines people’s pensions into a plan. If you had five jobs, you probably had five pensions. I personally experienced the problem of pension fragmentation, so had my friends, family, and everybody else we talked to. We can put them in one place, physically moving your cash to a plan managed by PensionBee.

What are the big differences that you found, say, in the first six months at PensionBee? Is there anything that stood out, any big changes you had to make?

I joke that every six to 12 months my job completely changes, and that it’s required for personal growth. At the beginning, I had a good idea of what I was doing because we planned it out and I’d done similar stuff before.

However I never had to take responsibility for the information security of a regulated financial services business before. I had to level up there, so I went to an information security expo and some CTO meetups and threw myself at the mercy of people with more experience. I just picked their brains until I figured out a good way to approach information security and manage being in a regulated environment.

What are some other opportunities that joining PensionBee opened up for you?

At the agency, my colleagues and I were frustrated because even though we had developed a good strategic perspective on product development and technology and how it could address business problems, we didn’t get to use it. That wasn’t what we were being hired for. We didn’t market ourselves for that.

We’d have opinions about stuff, and then the people paying the bill would say, “Why are the software engineers telling us what to do with our business?” So, we came up with the idea of CTO-as-a-service. I was the CTO, and the rest of our team was the delivery vehicle for technical leadership.

Funnily enough, our first client for this service was PensionBee. I think it was a useful insight – a technology leader who’s a business partner supported by a mixed discipline execution team is a strong thing to sell to companies that don’t have that yet.

General advice – finding the sweet spot

Is consulting easier than running your own company or being a CTO? At the end of the day, as a consultant you have less accountability for the results of your decisions.

My feeling is that they can be very different things. In the product world, you’re on a treadmill – chasing profitability and sustainability, always looking towards the next growth milestone, there’s no slowing down.

That’s a very different lifestyle and set of expectations for somebody who starts a consultancy. I basically started one as a lifestyle business. It was a way of having more people around me and a more stable client pipeline. 

Since you’re charging for your labor, you can do as little or as much as you want, depending on your financial goals. But if you want to scale the business, you’re looking at hiring extra people, growing your client pipeline to pay for them, and then maybe making a profit.

The agency model can be very nerve-wracking. One person who ran a big, successful digital agency in Shoreditch once told me, “We’re only ever three months away from going out of business.” That was a shock – how was one of the biggest agencies constantly afraid of running out of clients? You’re fighting from project to project to keep the clients coming back or to find new ones.

It’s a different mindset. If you enjoy working on a product, you might not like it when you have to become a salesperson in order to find clients that will keep your agency going.

Let’s sum things up. I’m sure there are lots of software engineers and novice tech leaders interested in the consulting part who started in the product space and want to do consulting next. Many people are drawn to it. From your perspective, would you say that this is a good way to explore your career? Or should people think twice and consider the challenges?

I think it can be a really valuable and fun experience to a younger person. In my mid-20s, I would often work from Europe. I’d join my friends on holidays and work from Spain, France, or wherever. You’re in charge of your own hours, which is a really nice quality of life to experience.

Building products comes with a lot of satisfaction – solving a difficult problem as a team and being able to put something out into the world is a lot of fun. But you’re also exposed to many complexities that come with building a product and the company around it.

You have to know what you want. If you want to start an agency, it should be because you’ve got an amazing insight into why people will come and buy from your agency.

If you’re a natural salesperson, even as an engineer, an agency can be profitable very quickly, give you a good quality of life, and never require funding. It’s accessible, there are lots of problems to solve. It has an interesting set of options for exit – if you build a successful portfolio of customers and they’re fairly reliable, that could be acquired as a book of customers.

At the same time, with a consultancy, you’re on your own and assumed to already have the skills. In a product company, there’s more focus on personal development and learning from seniors. You get more structured learning. That’s super valuable for juniors.

I didn’t do a lot of that so I’ve had to learn a lot on my own. Certainly for our more junior engineers, I can see the value of structured learning in a supportive environment, even for mid and senior level. My own approach to learning these days is to go and meet everybody that has solved a similar problem to mine, and learn from them.

But is it easy to transition between consultancy and product work? Or do you risk losing your consultancy skills if you work too long at a product company, and vice versa? Is there a point where you have to pick one and just stick with it? 

People with agency experience, particularly if it’s a creative agency, are very deadline-focused. That can be a good thing. It creates a hustle culture to get the thing shipped, which is very valuable in an early-stage business.

When you hit product-market fit or try to scale, you need to examine your technical debt, which can come back to bite you in the future by slowing you down or preventing further scale. In my experience, someone with an agency background could have useful skills here and provide a fresh perspective.

I think you also have to ask, “Are the business models complementary?” I just don’t know. Apart from 37signals/Basecamp, I don’t know many examples of consultancies that have successfully transitioned into product companies or launched a product on the side.

It’s challenging to go from a business model that’s all about a margin on labor to one that’s more about “take the capital, lose a load of money, hopefully gain market share, eventually become profitable.” They’re just completely different ways of thinking about capital allocation, resource allocation, strategic planning, and the type of work that you do. I’m not sure there’s as much overlap as people might think.

Resources

Our final question is about resources. Are there any learning resources, books, podcasts, websites, blogs, anything else that you would recommend to present and future tech leaders, consultants, and technologists?

The Phoenix Project – it helps you think about the flow of work through a technology business. Technology leaders need to bridge business needs with technical realities and demands, and make sure that the technology is serving the business and not the other way around. 

Domain-Driven Design – this one is all about how software architecture and business architecture basically need to be the same thing. It was such an eye-opening idea when I read it a few years ago. And it fits in really nicely with stuff like team topologies and distributed systems architectures, it gives you a strategic way to look at it.

Another fun thing to do is read basically anything that was written between 1960 and 1980 related to software. It’s probably better than anything written after 1990. That’s when people were really considering the big picture and the impact of computer systems on society. Alan Kay is just a wonderful thinker – he envisioned the iPad decades before it was created.

There’s a good YouTube video from Doug Engelbart called “The Mother of All Demos” from 1969. He’s showing his online connected system and he manages to show the mouse, the GUI, real-time video conferencing, collaborative multiplayer text editing, document word processing, the internet, all of this stuff at the same time.

What’s next? 6 actions for CTOs to take

Building a product is stressful, like running on a never-ending treadmill towards constantly changing goals, but being a software consultant can also be nerve-wracking in its own way. You have to know what you want and choose the road that aligns with your goals otherwise neither will bring you satisfaction.

If you opt for the agency route, remember:

• you need to know exactly why people should come to you instead of your competition,
• figure out how to sell your biggest strengths like Jonathan did with his CTO-as-a-service offering,
• hustle in order to deliver projects quickly, which helps a lot if you join an early-stage product company later.

If you’re focused on building your next software solutions:

• look for a business with a great leader, a solid idea that resonates with you, and a large market opportunity with low competition,
• be ready to learn complex topics quickly because your job will keep changing as your company and a team of software developers grow, so
• take advantage of all the opportunities you get to learn from senior team members.

With that, you can even give both a try, just like Jonathan did!