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.

“In the end, we’re not here to write the best code possible – it just has to be good enough to solve the business problem.”

Today’s guest, Paweł Morawski, is a Development Team Lead. Before he reached that position, he was also a Graphic Designer, a Project Manager, a Full Stack Developer, as well as a Senior UX/UI Designer – all over the span of a several-year-long career at DNV.

With such a versatile skillset, Paweł offers rare insights on aligning product delivery with business objectives. He told us:

• how to help engineers focus on business value and not just features, 
• when to involve engineers in product development to maximize business value, 
• how to combine long-term roadmaps with agile development.

Meet Paweł.

About Paweł

Say hello to Paweł

Peter Urbas: Hello, Paweł, thanks for joining us. You’ve been a Development Team Lead at DNV for over three years now. Can you tell us about your role?

Paweł Morawski: One of my responsibilities is taking care of developers, UI designers, and DevOps engineers. I’m also in charge of product delivery. I focus on maritime and energy projects, plus internal projects supporting our IT services.

Because of the matrix structure of our unit, I spend most of my day working with people that aren’t my direct subordinates. On the other hand, when I have one-on-one meetings with my direct subordinates, I don’t necessarily know what they do on a daily basis.

You’ve spent 15+ years at DNV, starting as a 3D graphic designer, then full-stack developer, UX designer, product manager, and finally, development team lead. Was this your plan all along?

It wasn’t planned. I just took opportunities for growth when I saw them.

I joined DNV after the 2008 crisis, and my first project was the R&D of a solution for maritime surveyor training. With a degree in physics and computer simulation, I already had a background in programming, so it was easy to transition from a designer to a software developer.

As a manager, I do my best to help people grow in a similar way.

Until I encounter strong resistance or see that someone’s new role clearly doesn’t match their skills, I push people to try new things.

You’ve touched almost every single role in the team, so you probably have a deep understanding of all the work involved in your projects.

Exactly. I don’t think this happens a lot. Most managers only have a background in one specific role.

Even within my different roles, I had many different responsibilities, which helped expand my knowledge. For example, as a developer I often took on the role of a QA engineer as well – though it’s worth noting that QA was easier to do back then.

This diverse experience didn’t just help me become a better leader. It also gave me credibility in front of my team. People, especially senior engineers, always know if what you say is nonsense or not. Having so many different experiences to draw from in our discussions helps me earn their trust.

Product delivery today

Ofiniti, a startup originally developed at DNV, recently became an independent product company, partially to improve its agility. For a success like this to happen, tech leaders need to align product delivery with business objectives.

Do you think that engineers need to be involved in product ideation from day one for this to happen?

I don’t think that they always need to be involved from the start. Engineers can quickly jump to technical details and focus on potential issues even before they become reality.

At DNV, the first step is to validate the idea with potential customers.

Once we know something makes sense from a business perspective, that’s when engineers come in so we can scope out an MVP and deliverables.

How important are they at this MVP conceptualization phase? 

Very important, but not every engineer is keen on activities like mocking, designing, or interviewing. Some would rather just go through the requirements and start building. Managers need to help them understand the importance of the pre-development stage. 

When you have the right culture, that’s when you get the full benefit of involving engineers at this point. They contribute fully and bring their best to the table instead of just checking off their to-do list for the day.

This is consistent with the idea of cross-functional collaboration that we talked about at length in the CTO vs Status series.

How to convince developers that they shouldn’t just code, but contribute to the whole product vision?

They need to be sold on the idea that there’s value in spending a full day talking and putting stickers on a board.

Some engineers are introverts. Even if you sell them on it, they still don’t feel comfortable with it. That’s why you should push them gradually. For example, task them with giving small presentations or have them join managers in demo meetings. These small steps help you build the right culture. 

Then, when the workshop comes, they’re comfortable and know how to overcome their inner barriers.

Strategy & roadmap

At the initial stage, there’s usually a roadmap and KPIs. One CTO told us that these might not always be viable technologically if you don’t involve engineers in ideation and that you can get pretty far into development before you realize it. How do you avoid such situations?

One prerequisite is that KPIs need to be defined with the development team – but this is not the complete solution. With the technologies we use, we usually have some vision of what we want to deliver, but it might turn out too complex later on.

Workshops focus on the business part, but the development team also needs space to digest the technical details.

I believe that domain-driven design fulfills this role. Prior to implementation, you evaluate the details on paper, and you notice more this way. Once you draw the required architecture and components, you can identify red flags regarding things like cloud costs.

You also need to give engineers space to verify initial KPIs after some time. If you start the workshop and want to have KPIs by the end of the day, they don’t get the freedom to mull over the technical stuff for a few hours.

So you need to give engineers space strictly for aligning the technical requirements with the business requirements?

Yes, that’s one solution. The other is involving the right people. 

Experienced engineers who have worked on multiple different projects will have an easier time identifying issues. If the development team doesn’t have such experience, you can tag in someone who does just for the workshops. 

There may be another solution, but I need your help with it. How do you develop a roadmap with a clear long-term perspective but also enough flexibility to adapt to changing business needs?

Combining roadmaps with an agile approach can be confusing for some people, but it shouldn’t be. The key is to focus on the value you want to deliver – for example, acquire X users in one quarter – instead of features that need to be implemented. A good roadmap is built on value-based milestones.

It’s hard to estimate the implementation of specific features early on. You can make rough implementation estimates with reasonable accuracy, but only three to six months into the future.

Focusing on the value gives you flexibility in what you implement to achieve that point. It’ll be easier to find shortcuts or low-hanging fruit, like focusing on one customer segment instead of many.

How do you usually define this value?

By understanding why you’re doing something. That’s the first question to all stakeholders: why are we doing this? Then, we can define objectives: “How will we know that we’ve done our job?”

Business experts should come with something in mind. It can be quantifiable – for example, reduce the cost of an internal process by X amount by digitizing it.

Sometimes, the goal has to do with marketing. For example, we offer advisory services, and software can be an entry point to them. In this case, the value of a product would be to help upsell advisory services.

Ultimately, it depends on the specific business case. Do your best to define it, even if it’s difficult. This gives engineers a clear idea of what they’re contributing to.

In big organizations, you have multiple stakeholders and just as many stories around a project. As a delivery manager, part of my job is gathering all of them and aligning them into one single story that satisfies everyone – especially the actual users of the solution.

Metrics

As a development lead, how often do you speak to individual team members about overarching goals, and how do you instill ownership of them? 

The one place where business goals and engineers meet daily is the backlog. For engineers to feel ownership, it must be used to its maximum potential. There are other ways, but the backlog is my top priority.

The backlog must be meaningful to developers – they need to know what’s behind each user story. At this level of granularity, you see a tiny part of the work, and it can feel disconnected from the main goals.

I usually approach it from the top down, breaking down big goals into epics, features, and user stories. This way, the backlog represents the entire vision behind the product.

Delivery managers can also use sprint goals and proper language. “User” is a faceless term. Instead of saying “user,” you want to show a specific person who will be using the software.

Execution

Let’s talk about the most common conflict in product development: tech people and business people usually don’t understand each other. Developers don’t get why a feature is necessary, product managers might not see why it will take two months instead of one week to deliver. 

It seems that people are often too focused on their own areas of expertise and forget that the success of the whole team depends on them. How do you help everyone realize this?

Let’s take demo meetings as an example – this is the point where, at least in our approach, most stakeholders meet with the development team. Sometimes, only one person from the development team presents all the tech updates. I think that’s a bad approach.

I believe that everybody needs to present their work. It doesn’t matter if they’re uncomfortable, introverted, or unfamiliar with business jargon. This way, when they’re building something, they know that they will have to sell it to the business side later.

Roles that are invisible to the business, like DevOps and QA, need to be exposed. Whoever is responsible for the team should showcase those roles and give everybody screen time.

Before I joined DNV, I used to work in companies with up to 10 people. Everyone knew what was going on at all times. In a company like DNV, with thousands of people, knowledge is scarce. People might not realize that once you commit to something, you still need to sell it in order to get paid. Showing people how it all works is very important.

It’s easy for developers to focus only on technical issues, software patterns or clean code.

In the end, we’re not here to write the best code possible – it just has to be good enough to solve the business problem.

The technical lead is responsible for teaching engineers when to lower their quality standards. While this can be difficult for some people, the focus should always be on the value for end users, not perfect code.

Of course, I am not encouraging anyone to do poor work. I am simply highlighting the risk of over-engineering things and losing sight of business value.

That’s how you close the gap between development and business. When devs focus on value, they’re already focusing on the same thing as business experts, and the gap closes naturally.

I wonder if this is easier or harder to achieve with interdisciplinary developers – the kind that have skills from across the board, but because of those skills, they may also have a tendency to keep to themselves a lot.

When you have interdisciplinary teams, how do you ensure alignment and set constraints for such teams so they know what matters for the business goals?

Alignment can come from different sources. Some constraints arise from things that are provided by external teams to the software teams. For example, setting up cloud infrastructure needs to be aligned with a specific IT team. 

We also need to be aligned when it comes to technology stacks because it’s good to have the same stack in all projects. If you give too much freedom, you can end up with technologies that only one person on your team knows. Then, you have a product that most people can’t maintain because of this skill gap.

Nonetheless, we try to give as much freedom as possible to the team outside of necessary constraints. Especially with senior people, you want to give them freedom because their broad skills are what you’re paying for. Let them utilize their potential.

What methods do you use to foster that kind of alignment on a daily basis and create this culture of individual responsibility for high-level business goals in the team? Are weekly stand-ups or workshops enough? How do you approach it?

Business goals should be visible all the time in all Scrum ceremonies. If it’s needed, we do workshops – either within the team or with somebody from the business involved.

Expose business goals as much as possible and give them a face by creating personas.

For example, in one product, we just have personas based on real customers hanging on the walls, so the team is always reminded of their needs and pain points. UX/UI designers usually create this, but not necessarily – the business can work on it, too, because personas are also used in marketing.

Without these methods, you end up creating silos, and silos are a risk to the product that should be mitigated.

What other reasons do you see for the business vision and the product reality drifting away from each other?

Any major adjustment in requirements or change of ownership is a huge risk to the product vision. Any shift can make it harder to maintain alignment, but ownership changes are the most difficult.

If somebody new joins on either side – technology or business – this person needs to be quickly familiarized with the context. If you replace “user” with a specific persona, they need to understand what that name represents and the idea behind it.

General advice

Given everything we’ve discussed, what’s your final advice for team leaders and product managers who want to ensure that their everyday efforts have the most direct impact on the bottom line?

Expose business goals as much as you can to your team. 

On a daily basis, team members will be focused on their responsibilities and working in Visual Studio, Figma, or whatever their role requires. It’s easy for them to forget why they’re doing something, so you have to keep reminding them.

Resources

Are there any resources, such as books, podcasts, or anything else, that you would like to share with those who want to learn even more about this crucial task of aligning delivery with business?

There might be no obvious choice, but two books helped me format a mindset that focuses on value and planning work toward achieving it. With such a mindset, it’s much easier for development teams to make goals easy to see and understand.

First, there’s Melissa Perri’s Escaping the Build Trap, and then there’s Jeff Patton’s User Story Mapping. Both are highly recommended reads!

What’s next? 4 tips for CTOs to align technology with business

For Paweł, everything starts with a strong reason for building a product, defined through business value rather than features that need to be implemented. To ensure that all product stakeholders are always on the same page, his advice is:

• help engineers grow by pushing them into new responsibilities,
• teach technical teams how to balance code quality with a focus on solving business problems,
• expose business goals as much as possible at every step of the project, and replace anonymous “users” with specific customer personas,
• treat your backlog with extra care, and make sure it’s meaningful to engineers.

Aligning technology with business doesn’t happen overnight – you have to work at it every day.