“Your job as a CTPO: uncover what’s invisible; remove what’s arbitrary” – an interview with Hans J Skovgaard

The CTO vs Status Quo series is about drawing attention to how CTOs challenge the current state of affairs in the company to push the business towards new heights … or to save it from doom.

The Chief Technology Product Officer gets product development going

CTPO – just the acronym is enough to capture your imagination. To be responsible for both technology and product is to wield a lot of power. Some say that it’s too much, and that one person can’t handle all the duties of a separate CTO and CPO.

Hans J Skovgaard thinks that companies that focus on efficiency and delivery speed can benefit from combining these roles. A good CTPO can use their diverse knowledge to make an organization go fast by:

• identifying and getting rid of development roadblocks,
• removing arbitrariness from internal processes,
• promoting cross-functional teams.

Hans is going to tell you how he does all of that. He also remarks on his path towards becoming a CTPO. If you ever plan to follow his footsteps, make sure to stick around!

About Hans & Penneo

Taking on the role of a Chief Technology Product Officer

Jakub Piłucki: Hello Hans. I just read Penneo’s H1 Report. It looks like the recent economic downturns didn’t do much to stop the company. It grew the ARR by 300% in Belgium. What’s more, Penneo got onto the EU Trust List of companies accredited by the Union’s electronic signature regulations. Congrats!

It seems like you’re going to be busy in 2024?

The continuous digitalization of societies always gives us a lot of hope. The same will be true in the upcoming months.

We’re trying to answer two questions. The first one is how ready the target countries are for our product in terms of digitization and legislation. The second one is if we can grab the market share before our competitors do.

The countries in the Nordics and the Baltics are digitally mature in terms of governmental readiness. But if you go to Germany, you’ll find out that they still sign many contracts with what they call the wet ink – a pen on a piece of paper. And that’s the actual contract we talk about and not a copy of it.

The timing of our expansion into Belgium has been a home run for us. Some other countries such as the Netherlands or Estonia are promising too but the local competition is stronger.

CTO + CPO = Who is a CTPO?

Your role as a CTPO — making sure that Penneo can succeed in these markets — is something I’ll return to. But first, I wanted to ask: who is a CTPO to you?

A CTPO to me is a more specific role than a CTO. The latter can be a person with three people or fewer reporting to him. It could also be the head of a large engineering team. The CTO label has a broad meaning to it.

I’ve noticed a consolidation of engineering and product development. When the CEO needs to resolve all kinds of conflicts, they often try to align them with one head of both teams. 

When you get hired as a CTPO, you need to understand where your problems are. They could be in either the engineering and product departments or in both. They could stem from their collaboration or a lack thereof. The symptoms may look the same – being a little behind on schedules and not having a clear vision of what to do. You need to determine what causes these symptoms.

So being a CTPO role is about developing a holistic, high-level view of the engineering-product relationship and a good understanding of the market the company is in.

I heard that most CTPOs come from a technical background, but they tend to focus on the product in their day-to-day work. Perhaps, this is a sign of times. It’s easy now to rely on cloud providers and other third parties for technical needs. But creating an innovative product is more challenging than ever. Is a CTPO the answer to that? 

Technology still moves faster than ever before. So if you are a CTO and want to lead a technologically innovative company, you’ve got a full-time job.

As a CTPO, you need to have enough understanding of technology to know what’s possible and what’s not or what’s realistic or not. Then, you look for business opportunities and decide on the course of action.

You can have a smart engineering team that does stupid things that bring no value. You can also have a good product strategy but fail to execute it. A CTPO is the answer to the need to put these two pieces of engineering and product together to create value.

Challenges

Some technology executives say that many companies choose to combine the roles of CTO and CPO to save money. Others say that any CTPO worth their salt is expensive. What do you think about that?

Realistically, a CTPO earns about twice as much as one engineer does. So I don’t think the salary argument holds, at least not for the four startups I’ve been in. But you still need to prove that you’re worth that much.

When a CTPO comes into play, the team is typically not so small anymore. I’m used to having 20-40 engineers in the organization as a starting point. That’s when you start facing scalability problems. Whatever you used to do in your basement stops working. What one person does can destroy the work of three others. You get to a point where you just need to have better processes.

A good CTPO is invaluable because they can introduce those processes across different areas.

A CTPO thinks of career paths for their engineers/PM’s/UX. To do that, they evaluate the team and ensure the best salaries go to the professionals who deserve it rather than to ones who negotiate well. So you need to come up with a way to measure how much value people produce for your company and set up a salary system that is not arbitrary but fair.

The development process is also what a CTPO improves. You need to identify the queues you face. If there’s a queue in manufacturing, you can see a pile of stuff. But in software development all queues are invisible. Everybody is hitting the keyboard and looks like they are doing something. In reality, they may be waiting for somebody and doing some pseudo work to kill time.

Also, as someone in charge of both product and engineering, you can help get things done better than anyone. Almost any company has worked on long lasting projects that ended up shelved. Some companies become warehouses of semi-finished goods. And we all know that when software is put on a shelf in an unfinished state, if it ever comes off it, someone will say it’s designed wrong and redo it.

It seems that CTPO can do a lot of good with the power they have. One of our previous guests believed that the rivalry between a separate CTO and CPO could be beneficial for a company as long as they were equal in power. What’s your take on that?

I agree in principle. If there’s a CTO and a CPO, they need to be on the same level for the technology-product debate not to get skewed somehow.

But a lot of companies go through unique circumstances. In some, the engineering department may be stronger because the founder was an engineer. Microsoft is an example of a technology-driven company. For similar reasons, the product department may be stronger in some instances.

In a small company, I think, you should either have a CTPO or a balanced mix between a CPO and a CTO. I’ve been in an unbalanced organization before. One group got the latest information before the other. The manager of the first one was part of the leadership forum, the other one wasn’t. That’s not a formula for success.

A CTPO may work hard on being balanced and not having these biases. It seems that each CTPO candidate comes from either the tech or product background anyway.

If they have a product background, can they talk to developers and have their respect? Or can a tech CTPO learn to talk to sales or marketing easily? 

I think that most CTPOs have an engineering background like me. I also have an MBA from the IMD Business School in Switzerland. So I’ve been trained in business, but I think it’s really hard to train the technical part of a product person.

Some product people do have engineering backgrounds but if you have very commercial experience, it’s hard to get the respect of engineers.

If you are a CTPO without at least somewhat relevant technical understanding of things, you’ll easily get into the “you don’t know what you’re talking about” situation.

So you can get in trouble if you don’t have enough technical knowledge. But you can also fail due to the complexity of a big organization. Perhaps it’s all too much for one person to handle. Then again, organizations such as LinkedIn or eBay actively sought out CPTOs. What’s your take on that?

You could say: “What do you do if you have a 100,000-person company?”. Nobody can understand the complexity of that. That’s why you divide and conquer.

When I worked at Microsoft, we ran an engineering team. There were about 300 engineers. That was the fourth-largest project at Microsoft. So even at big tech companies, you can still divide the work into understandable chunks.

If you are in a 30-people startup, you’re a small company. You can have much bigger teams than that, but If there’s one codebase, everybody needs to know what happens and how it affects everyone, it’s rare to see a project with over 300 engineers. There are maybe only 100 people working on Excel today despite the widespread use of it. 

With or without a CTPO, it’s hard to run a team that comprises more than 300 people and remain effective. In theory, you can throw thousands of people at the same task. But the chances that anything good comes out of it are bleak unless you have a very efficient way of dividing the work into understandable units that are empowered and have the freedom to drive in their own direction with few dependencies.

The daily grind

Let’s talk about how the role of a CTPO differs from the one of a CTO or a CPO. I picked several areas, some normally assigned to the latter, and some to the former.

First comes the nitty-gritty of being a CTO:software development, infrastructure, and operations.

You need to start from what you know and go from there. 

To give you an example, I’ve been working a lot with on-premise software. Then, I got into the company where I am now that uses Amazon a lot. I have never worked with AWS before. The first thing I did was to find someone on the team who knows AWS really well.

I don’t need to know everything, but it’s my responsibility to cover all areas of expertise required by my business. There are things I’m experienced with, such as Artificial Intelligence solutions. For other things, you need to find people who understand them well.

CTOs also structure development teams. How does your product focus influence your decisions in that area?

To set up the organization is your most important responsibility.

When you start as a CTPO, you need to learn who is who, who contributes to what, why you have these specific roles and what history is behind them.

Once you understand that, you can determine which direction you need to push the product in, and what capabilities you’ll need 2 years from now.

Then, it’s time to build. You’ll find out just how hard it is to optimize your team’s structure for the tasks ahead. There are many things to do. The board always wants to get everything done as soon as possible. They can try to get you to say that you can fix something in six months. The reality is that by the time you decide on how many people you need, how you set them up, and how you train them, release something, and see the first commercial results, 18 months could pass.

How does this relate to your recruitment strategy?

In most companies I’ve joined, the first thing I’ve done is to change our recruiting policy.

For every wrong person you hire, it takes six months to realize they’re underperforming. Then, it takes another couple of months before you either fit the person into a new position in which they could be more successful, or part ways with them. Hiring the wrong people is really expensive for an organization.

Let’s talk about product-oriented iterative methodologies. How do you encourage developers to be more than just coders through your choice of processes?

First, you involve them early on. That means that they get to use all their creative skills and all their ideas to maximize their potential outside of just coding. Then, you have them work together with product experts.

The best scenario is having an Agile team with a Product Manager, a UX expert, and an engineering team, and with the developers being involved in envisioning, prototyping, development, and testing.

There are a couple more things you can do to support product-oriented developers.

Don’t let them get bogged down by tight requirements written in tiny details. A developer may have an idea of how to do this ten times better. If they can’t at least try it, something is wrong.

Make sure that your engineers meet real customers. Developers make choices for your customers every day. If they understand how customers work, they will make better products. This may sound like an obvious thing to say, but let me show you the importance of it with an example. 

What if your engineers were consumers themselves? This is sometimes possible. When you are in the gaming industry, your engineers are likely to also be gamers. They will comment on things they don’t like and brag about how they can do better. Such developers will likely build something special.

Penneo creates anti-money laundering software. That’s not something engineers often do in their spare time. But they can improve their understanding of how customers work, and find out about their fears and goals, things they like doing, and things they hate. That way, they can be more like those gamer developers. They will make better choices intuitively to help fix the daily lives of the customers.

The product’s vision is something that the CPO typically lays out, while the CTO worries about how they are going to keep it scalable. Does not having to compete with anyone make roadmapping the product easier?

You may expect the same challenges in terms of the trade-off between doing new things and maintaining the old ones.

Again, It’s different for every company. That’s why I don’t like the term technical debt as it can mean pretty much anything to anybody.

For example, you designed a system for one million customers. Now you have five million customers and it doesn’t work that well anymore. That’s not technical debt. That’s a scalability challenge. 

As for technical debt, your job is to be able to determine the value of fixing something. Let’s say you’ve got a library that is old and has a vulnerability. Is it a good idea to fix it or should it be replaced altogether? How much time will it take? All technical debt issues are about comparing the value of fixing an old solution with the value of introducing a new solution. You have to decide what’s better.

As a CTO, you might be inclined to be the one who takes care of the technological means when others talk to the customers. As someone with a technical background, did you have to start thinking about the needs of the customer? How did it affect your thinking about product development?

During my career, I changed the way I looked at things. When I was a CTO or Lead Architect, I focused on technology a lot. I was not very observant of the needs of customers.

Over the years, I was able to change that through business practice and education. I gained a better understanding of what drives value in a company and how you make a company work when the “infinite” venture money runs out.

How to become a CTPO

You mentioned some events that helped you become a CTPO. I’m sure a lot of our readers may see themselves in a role like this someday.

So how did you start on the path? Did the opportunity just appear before you or was combining the roles of CTO and CPO something you strived towards on purpose?

I started as an engineer with a strong focus on technology. My first job was for a startup built around a very specific piece of tech.

At a certain point in time, I realized that being good at technology is what’s required to be a CTO for a small team. But if you want to move higher, you need something more. You need the ability to get a team of 20-30 to produce good stuff efficiently.

It doesn’t matter how good I am. I can only be as good as two people but never as good as twenty people. Rather than working harder, I should focus on making those twenty people effective. I needed to be a manager. That was my revelation.

Then I decided that If I wanted to go that way, I needed a good education in management. My MBA education in Switzerland was eye-opening. When I went back, I started getting CTPO roles, because then I had both an understanding of technology and business.

I’ve worked for several big companies. Taking a small team and scaling it at a big organization is not that different from what you do at a small company. The amount of money available may be different. But the challenges you face are largely the same.

My experience with Microsoft was really important too. They had a ready-made solution or a tool for many organizational problems and state of the art software development methods. I took this toolbox with me when I moved to smaller companies.

Just to be clear, I’m not saying that you should run a small company like you would Microsoft. But when you have a lot of tricks up your sleeve and know when to use them intuitively, you can adapt to any situation. So whether it is Facebook, Google or others a big company can teach you a lot of things you can translate into small-business territory.

To sum it up, by getting both technical and business education as well as experience at both startups and big companies, you can become a very hot candidate for a CTPO position in smaller companies.

In which areas can you still improve?

It’s not about specific areas. In fact, I need to continue improving in all areas.

You know, I’ve been in the software business for a couple of decades. I worked with three generations of software languages. When I tell people that one of my first jobs was developing a Prolog compiler, they are like: “What is that!?”

And they are not wrong, because a lot of my past experience is not relevant anymore.

Lifelong learning is a must. There’s no way to master everything. Technology, trends, and processes change quickly. This is always true, but it’s especially readily felt in software development.

And as a CTPO, you are the one who is supposed to know. You are the one who is supposed to predict things. You need to be oriented towards the future, not the past.

To be or not to be…

All this talk about what a CTPO can offer made me realize that it takes the same qualities to be a competent CTPO and a proper product-oriented company. Perhaps just striving toward a product-oriented organization is a good enough goal for a CTO. Should a manager or CTO try to become a CTPO?

When I started as an engineer, I never thought I’d become a CTPO.

There were two defining moments for my career. The first was when I was an engineer. I became a manager of a team simply because I was technically the best or most senior of the team.

But then, a second moment came. I became a manager of managers. That’s a much bigger jump. That’s when you can no longer control all the details. You need to start relying on your managerial skills much more than on your developer skills.

I also have a passion for creating successful products. It has always been my desire: to create a kick-ass product. If I didn’t think I could make the world’s best product in an industry, I wouldn’t even start making one.

When you have this passion, you naturally think about what you need to make it happen: how to structure teams, gain knowledge, and understand customers better.

That’s what drove me. The position of a CTPO came along the way as I pursued these passions. I got the opportunity to lead organically. But my ambition has never been to be a leader but to make the best possible products.

Resources

Can you recommend some resources that could help CTPOs in the making?

For creating teams, I highly recommend Shine. It shows how much the success of a team depends on the character of its leader. It’s about emotional intelligence and understanding  your strengths and weaknesses.

You should also read up on Lean Manufacturing if you’re new to team management. The underlying ideas of manufacturing can broaden your perspective. You can then translate them into a language understandable to your people.

Manufacturing is also where all the Agile ideas come from. Agile is about continuous process optimization, empowerment to make faster decisions, and reducing waste. All the retros and artifacts can help do that, but only when you use them well. They are not the essence.

Choose your methodology according to the problem you face. If it looks like something that needs Kanban instead of Agile, then go for Kanban. It’s never about doing exactly what the book says.

What’s next? 3 actions for CT(P)Os to take

It seems that the best way to become an aspiring CTPO is to focus on growing your managerial skills. You can do it through formal education and by leading teams in larger organizations. The experience of scaling a team within a department of a big company will serve you well when you are in charge of the same duties for an entire small company.

You should also let go of the need to control everything. Instead, surround yourself with people who cover the areas that aren’t your expertise.

Whether you become a CTPO or not, you can use Hans’ advice today.

1. Remove the invisible product development obstacles

The mark of a true technology-product expert is the ability to notice what causes delays in development and remove them in collaboration with the team.

2. Don’t allow for arbitrariness to decide the fate of your company

People with the highest skills should earn the most. Avoid shelving projects by having short projects and a clear product vision. Look for other ways arbitrariness sneaks into your processes!

3. Promote product-oriented development

Developers can help shape product features and vision. But you need to include them in cross-functional teams and give them a chance to talk to customers. You can read all about it in the interview on product-oriented development.

You can work as hard as two people but you will never achieve that way as much as you could by efficiently directing a whole team!