“Developers want to be product-oriented, but you’re not letting them” – an interview with Wojciech Zawistowski

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.

If you aren’t a giant but aim for greatness, you can’t cut anyone out

Sometimes managers treat developers as little more than tools that turn other people’s ideas into code. That’s not how things should be.

After all, developers are the ones who understand the full potential of the technology behind the product. They can come up with competitive advantages by turning user feedback into new ideas and implementing them. They can also spot new trends that could take you to another level. But first, you need to let them do that.

Wojciech from Contractbook believes that many CTOs don’t, because of the many temptations that exist in the product development process.

The three big temptations include:

• Cutting out developers from decision-making for short-term gains such as releasing faster.
• Making detailed and long-term plans, losing the flexibility in the process.
• The temptation of some higher-ups to divide and conquer, which kills cross-functional development teams.

He will tell you how he designs an environment that removes these temptations – one in which developers freely test their ideas and shape products that delight users. In short, he will tell you about fostering product-oriented teams or POD teams.

About Wojciech

The making of a product… oriented developer

Jakub Piłucki: Hello Wojciech. I recently read your work in progress – the Definitive Guide to Succeeding as a Professional Dev

You’re writing that “being a great software developer is not about coding skills. It’s about helping your team, product, and company succeed.” Are you putting that into practice at Contractbook?

I help developers at Contractbook understand that the product always comes first.

Being a better developer is typically associated with being a better and faster coder. But this is a fraction of what developers do and how they contribute to the success of a company.

What makes a company successful? A successful product. And companies don’t just succeed once with their product. They need to succeed consistently over many years. To do that, they have to understand the users and how their needs change over time. Then, they need to scale it from a small startup.

Some companies have a very technical IP (intellectual property). Their developers can focus on coding, making the technology great. Something like OpenAI comes to mind. But most companies don’t have innovative technologies. But they might have an innovative product. That’s true for Contractbook.

When I started at Contractbook, there were 25 people, 10-11 of which were developers. We scaled it to 160 people — including 60 product team members. There is a big difference in how you experiment with the product when you have one small team as opposed to 6 product teams.

At this scale, you can’t micromanage everything as a CTO. You win by deeply understanding customers and their problems. This requires the collaboration of every person on the team, including developers. Developers should contribute to the product and the growth, sustainability, and evolution of a company.

Part 1 – finding the competitive advantage

You advise developers on how to build products at four stages: competitive advantage, growth, sustainability, and evolution. Let’s talk about how CTOs can help developers take part in shaping the business value, starting with the first stage.

First of all, the competitive advantage needs to be ingrained into the company’s culture.

For developers, to develop an advantage like this, they need to work with customers. But how can a developer work with the customer when they are far from them?

The developer is not in a close relationship with the customer by default. For developers to be in this position, a change needs to happen at the top level of the company. The sales team, customer success, and product managers are close to the customer. As a CTO, you should get your developers there too.

So what do developers need most? They need permission. It sounds funny, because one may assume that being product-oriented is inherently good. But ‌it still needs to be worked into the setup.

At one company, we, the developers, had internal customers — not even external ones. We sat next to them. The management always pushed us to deliver quickly. This internal team was like a second-class citizen. We asked: why not talk to them and understand what they do and how they work?

The manager said: it doesn’t make sense because it will take your time. They can figure it out themselves. It’s cheaper for them to find some kind of workaround in the existing user interface than for you to spend time polishing it and understanding data flows.

In such an environment, developers can’t be product-oriented.

At Contractbook, developers don’t contact a random customer to ask about a feature. To get accurate insights, they contact a particular customer who is a good fit and interested in a given feature. To find them, developers collaborate with the customer success team, which is in close relationships with customers.

To find a competitive advantage, you need on-point customer feedback?

Yes, but not every customer wants to be contacted. Filtering who to contact is important. You need people with whom you have good relationships.

It takes time to select them, pair them with developers, and experiment and iterate. But you can’t be product-oriented if you don’t have time to do this.

How to make time for developers?

As a manager, you need to set expectations. Suppose you want your development team to meet deadlines or follow precise estimates. In that case, they won’t have the time to iterate, and this is a prerequisite to being product-oriented.

So we said: “You have control over the team setup. You decide if things should be separated or cross-functional and who works on which subset of the product. You can divide the product into technological slices or user flows.”

We are moving a bit from the environment to processes, but processes do matter. You don’t have to design them all yourself. There are scrum masters or engineering managers. Different people shape processes. Still, as a CTO or VP of Engineering, you have a ton of control over how you want your team to work.

One thing developers can collaborate on with other departments is product metrics. 

The whole product team needs to focus on product metrics. You need to make sure new features will have an impact, and that you don’t just churn out widgets one after another.

At Contactbook, we really wanted to be product-oriented, and we decided to make an MVP of a key feature.

The mistake was that we planned detailed road maps. But it’s hard to plan a road map if you don’t know what features you’re going to need. And if you have a proper map, it’s hard to iterate. We built a stripped-down version of the product. We thought it was an MVP. But then, we added yet another feature because it was on the road map. It was hard to go back to the previous version and act on the feedback.

We needed to change our mindset, create an actual MVP, and iterate it based on real feedback and metrics. That’s what it means to be agile and improve continuously.

This example also shows that you can’t just collect metrics. You need to ensure developers are aware of them at specific moments, so they don’t waste time building features nobody needs.

What metrics are you using at Contractbook to be more product-oriented?

We switched to the OKR framework. This gave our team a business goal and metrics. It changes thinking. We also have custom scoring, which shows how well customers interact with our app. What specific metrics you choose depends on what problems you solve and for whom.

The metrics have a relationship with OKRs but are also independent. You can use them as part of OKRs. And, like I said, making sure that the team has them available at key moments goes a long way.

Technical metrics, such as velocity, matter, but they don’t bring the product closer to meeting customer expectations.

Is it the CTO’s role to introduce metrics that make sense to a developer?

It depends on your company setup and the managerial structure.

At Contractbook, we have a CPO role. It’s not necessarily the CTO who introduces metrics. It may be the CPO.

The change comes from the top. If you want to have cross-functional teams, in which product managers work together with engineers, then the engineering leader needs to work closely with the product leader.

This sets a good example and enables knowledge shaping. As a CTO, you can push for it. I did it by championing courses, book clubs, and the idea that metrics primarily explain the performance of the product, not just the technology behind it. I also had my developer work with people such as designers or product managers who have greater product experience.

At Contractbook, we have regular all-hands meetings. We are transparent about our metrics. They aren’t just for the sales team. Everyone looks at them and gets a full explanation. Product metrics are presented by the VP of Product while financial metrics are clarified by the VP of Finance.

Part 2 – The growth stage

The company found its competitive advantage and started to make money. Developers can help ensure that good times continue. Do you think that modularization of the architecture makes a difference?

It does, but modularization is a means to an end.

Modularization of the code base helps scale things because if five teams work on the same code area, it gets hard to manage. It’s helpful to split the app into smaller chunks or domains so teams can work somewhat independently.

Teams being self-sufficient is a fundamental step towards company scalability. Because such teams aren’t delayed by the need to synchronize with too many dependencies. 

It’s definitely the easiest to split the codebase across technical boundaries into features, layers, or cold components.

This often goes against being product-oriented because it makes it harder for a team to understand a user flow, business feature, or use case.

Technical components are like vertical slices of the application. On the other hand, user flows are horizontal slices, because a full user flow often goes through many different features, layers, and components to achieve end-to-end user value.

Then you’ve got a dilemma – how to split the app so it’s easy to understand for developers and give an understandable overview of user flows to enable iteration and metric collection.

You can design the code base from the start so that it is technical but also maps well to business use cases and flows. But when you iterate and the business flows change, you need to reshape it. This is a continuous process.

I heard something similar from a fintech CTO. It’s hard to find the alignment between technological and business demands in a high-velocity environment.

Yes. Those technical and business aspects need to go hand in hand with each other, to bring value to customers and enable process scaling.

It’s not just about technical scaling but about long-term sustainability. The app evolves not only because you add more features. The market also shapes its development as customers come across new problems. You need to adapt. You can’t just design one good architecture and stick with it forever.

At Contractbook, we went through many setups, from technology-oriented to flow-oriented ones. Your ability to change them fluently, without doing a big refactoring every year, is what makes your product sustainable.

CTOs are also looking for ways to speed up development. How do you help your developers do that?

I’m not sure if development velocity is that important. I will challenge this.

If you really want to be product-oriented, the key to winning is not building faster but iterating to discover things faster. If you build something that doesn’t bring value to the user, the fact that you did it fast doesn’t do you any good. You can release code every day like this. It won’t bring you success.

What you need is a fast discovery process. You don’t know what to build from the start. You need to discover it. Even users will not necessarily tell you what to build. They may simply not know that.

Users have ideas about how things should look, but the interface they say they want may differ from what could really help them. You need to dig deeper and get to the root of the problem.

First, you need to iterate to understand what challenges users have. Test several solutions. Make hypotheses: this, this, or this may work. And then, it’s time to test.

Working like this is a huge mental shift for developers to overcome. They are not always expected to create great production code. Instead, they help your product manager build quickly and deal with the prototype or do a spike with the proof of concept to see if something is feasible technically or viable commercially.

There are different techniques, like the concierge or the fake door, used to test products. They are worth getting deeper into for developers who want to be product-oriented.

No matter how well and fast you build the production code, you will always build a simplified prototype faster.

So just like at earlier stages, developers need a proper environment to help the company grow.

The environment is also about collaborating with designers and product managers. Designers create prototypes and mockups, but developers can help test and roll back features. They also know how to release a feature behind a feature flag or just for a subset of users. This is called canary deployment and allows you to get to a representative audience sample without having to show a potentially flawed feature to most users.

As a CTO, you can help with both the culture and architecture. I talked about the cultural aspect before. Releasing behind a feature flag is architectural. You also need proper tooling in your application.

And then, there are metrics. I talked about them, but I need to add one more thing.

I said that you need to have the right metrics at the right time. But when the company grows, you also need to know where to find them. Companies have different methods. Sometimes, the CTO has the data, sometimes, it’s within the product, or in the hands of operations or finance. No matter where it is, engineers need to collaborate with whoever has it.

It seems that each company needs to develop a unique environment. But how does it work at Contractbook?

At Contractbook, we split responsibilities. We have a data team, which handles some metrics because they have better access to them. A lot of them are core metrics. But then, there are some common metrics as well.

So it’s not that a single team responsible for a single user flow or a feature has entirely unique metrics. Some metrics are broad and can be used by the engineering team as well as commercial or financial teams.

We built our first AI-based feature some time ago that imports docs and extracts their data. It had new metrics assigned that were different from the kind we normally track. We wanted to track usage, the quality of data extraction, and the cost, because AI can be costly. Those metrics were owned by a specialized team and not the one responsible for the whole app-wide data layer.

Our guests, Mika Peuralahti of Smartum, Ludwig Magnusson of Mediatool, and Majid Garmaroudi of Northfork talked about product-oriented delivery in the context of setting up self-managed teams. Do you like this idea?

I do. We intentionally recruit people with a high level of autonomy and a sense of responsibility. This is again a broad topic because a part of it comes inherently from a given person, but also a part comes from the company’s culture, your expectations as a CTO, and many different things that motivate the team.

At Contractbook, the customer success team passes the praise from the users to developers. This is one way we foster ownership. When you are a developer on a traditional team, you are often in the shadows. You rarely hear from colleagues or customers that you wrote great code.

When the entire team is product-oriented and cross-functional, you get praise for the feature rather than the code. As a result, you feel you own the feature. It’s no longer just something the manager told you to make.

When you hear from the user that they love the feature, and that it changed the way they work, it’s hugely motivating.

But there are some boundaries because you need to have some standards. It also depends on the size of the team and stage of the company, and how quickly you scale.

So being self-managed isn’t always the right direction?

I lean towards as much autonomy as possible. I would even be okay with different teams working on different technologies. We experimented with it.

But it may sometimes go too far because of the way the architecture evolves. If you allow for too much freedom, it may be difficult for you to restructure and refactor your architecture to meet your product needs.

I think that the final say in this should not come from me as a VP of Engineering.

When the company started to scale and we got more teams, we introduced constructs such as frontend or backend guilds. They made decisions on their own within the team and remained highly autonomous. However, there is a subset of decisions that need to be unified across teams. I don’t make these decisions. Representatives of all teams get to reach a consensus.

So the teams still feel a lot of ownership because decisions come from them.

Part 3 – The sustainability stage

At some point software products become so big that developers encounter sustainability issues. Can the CTO help prevent the accumulation of technical debt by educating developers about it early on?

I would say again that it is about cross-functional collaboration and permissions.

It may sound strange because technical debt is usually associated with technical aspects of the code. But if you deconstruct it, then to maintain the codebase in good shape, developers need to have permission and sufficient time.

If developers feel that you value deadlines more than clean code and you cut every corner possible to release faster, the quality of the code will deteriorate.

It’s not always a bad thing because there are stages, especially at the startup when you need to cut corners. As a CTO too, you will have to decide when and where you can do it because developers may struggle to get a holistic view of the product.

It’s a hard balancing act. But if you want the code to be at least somewhat well-engineered and sustainable, you need to provide time for this. You might have to compete with the VP of Product‌.

In many companies, there is tension between the group that pulls towards code quality and one that pulls towards building and releasing faster.

Sometimes this tension can work because if those two groups are equal in strength, this constant tug of war can be an efficient way of getting the best of both worlds.

But collaboration is better.

At Contactbook, we intermixed the product roadmaps with the technical ones. We have one dedicated infrastructure and platform team that does technically oriented features, but we incorporated those features into a regular roadmap.

I have a good relationship with our VP of Product, and we can prioritize together. There are times when we need to iterate quickly on the product, and he’s able to convince me that we need to cut some corners. There are times when I can convince him that we need to pause feature building and give developers more room to refactor code.

Part 4 – The evolution stage

Many companies pivot due to ever-changing market circumstances. But when they change technologies, developers need to pivot too if they want to stay in the organization. Do you have experience with managing that?

On a personal level – not to such a big degree. It’s an evolution. In our case, migrating from JavaScript to Typescript. I wouldn’t call it a change in technology. We also introduced AI. That’s not a migration either because it’s not like you code in JavaScript and then you code in AI. It doesn’t make sense. AI introduces something new on top.

I believe that adaptability at both the product and technical levels supports a successful introduction of new technologies. To accommodate AI capabilities, we created a learning space called the AI Lab. Then, we gave one AI-based feature to our regular team, and they adapted well.

Adaptability looks different depending on the size of a company. I talked to Google engineers about it.

They invest a lot in tools. They have dedicated teams that can train other folks. They build internal frameworks. Sure, they hire dedicated people too, but there’s also more freedom for the developer to switch to a different team if they want to work on something else.

At a small company, when you have 10-20 or 40 developers, it’s hard to hire a dedicated developer every time you experiment with something new. In such an environment, people need to adapt. Your job is to provide them with the room and time to do it.

Startups are about constant adaptation at different levels. It’s even more true for processes than for technology migration. How our processes changed when we moved from a feature-oriented setup to full product discovery was an even bigger shock for developers – a brand new way of working.

It appears that the evolution stage favors developers who are open to changes. Can a CTO instill such a mindset in their teammates?

It starts with hiring and then, like always, it’s about creating a proper environment.

Some people inherently don’t have the right mindset.

I’ve been a hiring manager at different companies for 8 years. Once, my friend and I interviewed a guy who said that the best thing at his previous job was that the manager always prepared a detailed plan. He always knew what and where to code. He was just filling in the blanks. We went speechless. Luckily, there are a lot of people who like experimenting.

As for the environment, you can’t just tell people to be adaptable and push them so hard that they have to do everything in their private time.

You help them by connecting them with people they can learn from and by facilitating good code reviews, which are also great learning opportunities. You should also provide structures such as a guild for exchanging knowhow, or some kind of internal book club.

Also, believe in your people.

When we invested in AI, I didn’t immediately open recruitment for AI specialists. Instead, I organized a hackathon for my team and asked around who was interested. It sends a powerful message: “You can do this. We believe in you.”

Part 5 – The process

We covered all stages of the organization’s growth. But perhaps you’ve got some universal advice that each CTO could follow regardless of where they are. They want to make developers more product-oriented. What steps should they take?

Having a cross-functional team is a must. You can’t have a product-oriented team if every group works in a silo and competes for resources.

If you have a cross-functional team, you should involve everyone in this. The product manager has more affinity towards interviewing customers, but they should invite developers too. Some of them may not like it, but they should at least watch a recording. They shouldn’t feel that there is a magical product discovery process and they just get to implement it.

You can’t have the pressure of deadlines and overly detailed road maps. You need to have the capacity to experiment. And when you experiment, you won’t know what the result of the experiment will be. You must prepare for both success and failure. You also don’t know if you can solve user problems in two or six iterations.

You shouldn’t be backlog-driven. The majority of companies I worked for in the past were so. Developers have a list of features to implement. But if you want to be product-oriented and have a discovery process, then you don’t have a list, you don’t know what to build yet. You have hypotheses.

You should use a mind map or a tree. Specific planning techniques that can help you be more product-oriented include impact mapping or opportunity solution maps. You have several problems to evaluate. For each problem, there are multiple solutions. The team chooses what hypotheses to test. This is relevant for your processes because it requires different planning and maintenance of the backlog.

Part 6 – Resources

Thank you for your insights, Wojciech. I’m sure you could tell so much more, but no interview can last forever. But perhaps you can share some resources to help other CTOs stay on their part towards a product-oriented future?

I am a book person, so I’m going to focus on books. And since we’re discussing products, all the titles I recommend revolve around product management and aren’t too technical.

• “Continuous Discovery Habits” by Teresa Torres

A great introduction to the concept of the designer, product manager, and engineer working together on the discovery process.

• “Escaping the Build Trap” by Melissa Perri

A title about moving past this whole linear road map-based process I talked about and focusing on building features instead.

•  “Impact mapping” by Gojko Adzic

This one will be a great follow-up to Perri’s work. It walks you through the process of moving from a linear backlog to a tree-based one. It’s concise.

• “Inspired” from Marty Cagan

It may seem intimidating at first, but it provides a holistic product-oriented management and shows how it feeds into different aspects of the company.

At Contractbook, we conducted meetings with engineers and technical leads about these books. They helped shape our product-oriented mindset.

You can also sign up for my newsletter, which tackles many of the same issues. If you want your developer to be more product-oriented, pass them the link. I’ll be obliged, maybe they will be too.

What’s next? 3 actions for CTOs to take

Your developers can shape more than just the invisible inner layer of the product.

They can be product owners, come up with new features, work feedback & metrics into their creative process, and help pivot, scale, and improve. Just make sure to:

1. Give them the permissions they need – to interact with customers, experiment, and iterate.
2. Involve them – by making them part of debates & cross-functional teams (POD model).
3. Believe in them – by starting any evolution with their input in mind.

If you do all that, you can successfully build product-oriented teams and include the voice of developers in your product strategy.

About Contractbook

Contractbook turns static contracts into a database for your entire organization, unlocking the full value of your data. Through centralized storage, insights, and full contract management capabilities, it empowers teams to build better, future-proof contracts.