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.

Your developer’s motivation comes from what they bring in

One way to challenge the status quo is to change your organization’s approach to employee motivation. Everyone wants to increase productivity and deliver challenging projects faster. But perhaps they’re viewing the problem from the wrong perspective.

Mediatool’s CTO Ludwig Magnusson believes that you can’t motivate software engineers directly in the same way you can increase the test coverage of your app or introduce new technologies. In this interview, he shares:

• how he avoids wasting time on changing requirements, feedback, or internal disagreements,
• the hiring tactics he uses to find truly passionate and driven people,
• the evolution of his team and project management practices at different stages of the company’s growth.

Sounds good in theory, right? Let’s ask Ludwig how to put that into practice!

About Ludwig

Interview with Ludwig Magnusson

Jakub Piłucki: Hello, Ludwig! For starters, I wanted to congratulate you on closing a really big investment round of €7M for expansion in the U.S. It looks like you’re going to be even busier next year?

Thanks. And yes, we’re going to be busy, but that’s how it’s always been for Mediatool. 

We’ve been building our campaign management platform for brands and agencies for over nine years now. Back in the day, we got an angel investment. We grew the company to eight people and broke even.

Then we got VC investment. We went from eight to 25-30 people in two years. That’s when we determined that enterprise customers are best suited for our product. We’re targeting big international companies. It means that there are fewer deals coming in, but each one is of considerable size.

Productivity killers

I’d love to know how you ensure that there are no productivity killers that could derail your product development plans by demotivating your team. Let’s start with changing requirements. Your people work hard on a feature and then, there’s a U-turn. What’s next?

It was quite common back when we started and had just three developers, which were the founders.

We had been crunching and then something new came up suddenly. I panicked. I felt like I needed to stop everything I did and get right to it. I don’t want my current developers to have this kind of experience. I set up our teams with that in mind.

First, you’ve got the Agile/QA team. It handles the incoming requests. They go from one task to another quickly. These include bug fixes, minor improvements, and sometimes larger improvements but nothing that should take more than three days optimally.

There are feature teams that do the heavy lifting in longer sprints. And they should NOT be interrupted. Priorities should not change. They’re given a project, and they’re given the time to finish it and during that time they should be shielded from any changes.

Aren’t they interrupted when they have to wait for feedback though? I know teams for which the review process can take more time than the actual coding!

Feedback can take a lot of time, especially when you work on something new. There’s always this pioneer client for whom we need to develop a new feature, something we haven’t done before.

Our answer to this challenge is a thorough preparation. First, development teams meet with the client. We talk and show sketches. We get the feedback very early. Then we continue to return to the client with early versions of a feature. We have a proof of concept and then refine it gradually.

We deal with internal feedback similarly to avoid waiting for too long at a time.

I’m curious about these internal conversations in particular. Not everyone is born a team player. The experience of working with some people can make one stressed. Then again, it is hard to pass up a good developer. Do you hire them and work on their collaboration skills later?

There have been two major cases of defiance during my time at the company. Neither of these two individuals works for us anymore.

Teamwork skills are very important for us when searching for new people. To land a job at our company, there are two requirements. You have to be technically competent and you have to fit it in the team.

We’re lucky to have found a good way to evaluate people and it’s very much based on a hunch or gut feeling. It’s not really a process but it works for us.

Once, my mentor gave me a piece of advice that stuck with me to this day. We were going to hire a bunch of new people. And as I was interviewing candidates, I picked up on minor details about the possible candidates. Then I asked my mentor: “Am I being paranoid here? I am dismissing people that are good just because they’re not perfect?” And he said: “No. Go with your gut feeling. If it feels wrong, then don’t hire them.”

That’s what I do. We have hired mostly junior people and brought them up in the development world. Early on, we also tried to hire more senior people, but we found some of them to be hard to please and perhaps a bit too comfortable. 

There was one senior guy with 10 years of experience we liked at the beginning. I wanted to make him a team lead and give him two juniors to mentor. He seemed excited, but he quickly grew somewhat comfortable, and we eventually went our separate ways.  Another senior insisted for things to be done his own way.

It isn’t to say that it never works for us to hire seniors. In fact, as we grow, we need to hire more of them. But you have to dig deep to make sure that it is the right person. Don’t make a hasty decision based purely on their impressive experience. A bad fit will hurt the productivity of your team.

What else will? Any other productivity killers you have worked on or planning to work on defeating?

The big consensus culture here in Sweden. I am really starting to dislike consensus.

When something doesn’t work, we used to bring everyone in to discuss it. That’s not good. Everyone is not an expert on that issue. Everyone will not have an opinion. If there are people who have a strong opinion on the subject, then yes, bring them in.

And then people want to vote on the best solution. Most of the time, it’s not the way to go. Choosing the best solution should involve meaningful discussion by people who have the right expertise.

And I’m not saying that this person is always me. Sometimes there are other people who understand a given subject matter better. Let them decide and pick the best solution, not the most popular one.

Ludwig’s best practices for motivation & productivity

There are general best practices, and then there are secret recipes for improving motivation and productivity that each CTO develops on their own. Are you willing to share some of them? Which area is most important to you?

I’d like to go back to the issue of hiring. But even before that, I’d like to start with myself.

Back when I studied engineering at the university, I learned all the theories behind building scalable applications. I found that to be very interesting and it became my passion.

By the end of my four years at the university, I was so sick of the theory I just wanted to practice already. Today, when I interview people, I’m looking for the same hunger for programming.

Another story. I used to have a summer job at Sony Ericsson. I overheard another dev talk to his mom about his work. She wanted him to explain what he actually did. It was something like memory allocation and optimization. He couldn’t explain it to her in layman’s terms.

Today, I’m looking for people who love building all of these complex and difficult products, while at the same are able to talk about them in simple terms. This shows that they are having fun. Those are the hungry people, the people I want to do stuff with.

Most of these people are very young. These days, many people hire juniors. Few of them have engineering backgrounds. You don’t need to be an engineer to learn coding anymore. Many people learn coding and then a framework such as React. We use React so they can come in here on day one and they make themselves productive by building components. But you must also teach them about code structure and reusable code, the single responsibility principle, all those things I learned in the university. When they can see their skills improve, they become motivated.

It also motivates me – bringing in those young people and teaching them stuff. That’s big. Our positive experience with this practice is one of the reasons we haven’t hired that many seniors as of now.

Can you really build up your team by hiring juniors only?

Those we hired years ago are basically seniors today. But at the rate we’re growing, we can’t just keep hiring juniors. We are looking for people who can come in and be team leads right from the get-go.

I would like to assess them in a somewhat similar way I described above but from a senior perspective. So instead of reporting on just themselves, they would report on how their team did. Instead of being concerned about a button, they would be concerned about the entire feature. I’d assess how their work affects the product on a weekly basis.

Let’s go with work planning now – how to go about it in a way that promotes motivation?

If I could say just one thing, I’d say: keep meetings few and to-the-point. And know exactly why you’re having them.

I know some companies that spend as much as 50% of their time on meetings. They even have meetings to discuss what meetings they should have.

As for Mediatool, we have a full team meeting on Mondays that lasts half an hour during which we discuss things in-depth. Then, we have a 20-minute demo for the entire company on Friday. Anyone from any team can share their wins and woes. A setup like this keeps the meetings productive and the people involved, without overwhelming them.

Meetings are also a big part of communication. But there’s more to it. What’s the role of communication in motivating people?

One aspect of communication I strongly care about is project knowledge. There are a lot of things to know about the product, a lot of details. You can’t learn it all right away. You will fail to understand everything and you may become overwhelmed. Especially that you don’t need to know everything from the start.

What we do when we bring in new people is keep them contained in one specific area for a while. Juniors in particular are given a specific task or feature for starters. They do either frontend or backend at the beginning. When you’ve mastered that, you are ready to move on to the next feature.

Over time, you will learn the essential things that are prevalent in all aspects of our application. You will gradually gain transferable project knowledge.

Teaching our platform is a big challenge as well. I can document it all but I don’t think people will sit down and read through it. Learning from practice and looking into the docs when needed is more stimulating.

We documented the coding patterns that we use, how the data flows through the app, things that are common to all features etc. We also have a general introduction to every employee, not just developers. It teaches you the basics of how the app works, how the data is structured, how the access rights work and so on.

Besides teaching them how the platform works, you must also motivate them by promoting their self-development. Am I right to assume that you do more to that end than sending them the titles of your favorite motivational speakers?

I used to have one-on-one meetings with all developers. I’m now outsourcing more, so I am moving towards only having them with team leads. Then, the team leads connect with their teams.

But the point is to keep the conversation going. What’s the next thing for you to learn?

How do you want to grow your skill set? What would you like to work on now? And we also have lunch-and-learns every Friday during which we watch videos together.

And then, there are code reviews, which also provide a good way to learn from each other. It’s something that comes very naturally to us.

So we aren’t really doing anything original to motivate our people to grow. That’s because we don’t have to. You see, it all comes down to hiring. Like I said, I try to attract people with the kind of drive I had at a young age, people who want to build stuff. If I can succeed at that, the team will crave self-development naturally.

What about tools? From what you’re saying, it seems they don’t influence motivation that much, but maybe they still have a role to play?

Tools – as in communication platforms or to-do list apps – probably not. As for tools as in frameworks or methodologies, they are very important.

We always strive to fit the approach into our team, not the other way around. We’ve gone through many different methodologies as we continue to grow. What worked before wouldn’t work now. 

First, there were four of us, then eight, then sixteen. Early in the summer, we hired four people, and now, we have two full-sized feature teams working in parallel. Originally, we had a kind of top-down approach. Features came from above, and then we broke them down into user stories and further into tasks. We estimated everything thoroughly. Eventually, as the team grew in size, I realized that I didn’t want to spend so much time on administration. 

I was looking for a way to make teams more self-sufficient. The Shape Up methodology from 37signals (Basecamp) came in handy.

Instead of collecting hard requirements, you create what they call a shape, which is a rough outline of what you want to achieve. How you achieve that is up to you. Then you have six weeks to deliver the goods. If you run out of time, you downsize the scope.

 It challenges the common approach in which you create a list of tasks to complete in a short sprint. The unfinished tasks are moved to another sprint. Then, they mount and mount.

Shape Up is our way of getting rid of the scope creep, which is a situation when you’re supposed to finish a project for the sake of finishing it.

It’s also a way to give teams more self-control. They get to decide what to do next based on changing circumstances. I found this aspect of the approach to be very motivational. It takes away micromanagement and makes people want to do their best.

Have you considered measuring how much of a difference these methodologies make? Recently, we published a big observability strategy guide. One of the three pillars of an observability strategy it talks about is productivity. Do you think that measuring your team’s performance is a way to motivate or rather intimidate developers?

You can do it the right way, and you can do it the wrong way.

We did that before for the Agile team. They estimated all their tasks. And then we had a dashboard where everybody saw how many tasks they did this week, and how many points they scored. If they were above a certain threshold, a certain sign appeared on the dashboard. Making it show was a source of excitement for all the teammates. It wasn’t all that scientific or rigorous, but it succeeded in making them focus and commit to a specific result all on their own.

Still, I wouldn’t overdo the analysis. I’m more about empowering people and giving them responsibility. From a manager’s perspective, I don’t want to track whatever a single person does on a detail level. It’s not the best use of my time.

I’ve seen attempts at thorough measuring of the team’s performance backfire on a company. It might make an employee feel like they aren’t trusted.

Definitely. What’s more, it’s hard to quantify development work like you could the performance of a salesperson. It’s not about the number of pull requests. It’s not about the lines of code. You can do tons of work with just a couple of lines and it may take you ages to do so.

If you do choose to measure things, make sure it provides some benefits to you. Because these measurements are part of your administration and as soon as you introduce more administration, you take away from the actual work. You better have a good reason for that.

The process

A CTO that’s reading our conversation might have just realized that they aren’t anywhere near creating an optimal environment for motivating their employees. Introducing new measures one at a time may not be enough. Do you think that they can make gradual improvements by introducing some kind of process?

I wouldn’t do something to motivate people. I would create an empowering environment. One that gives them more freedom, responsibility, and ownership. That should motivate them. If they don’t like an environment like that, you may have the wrong people. Again, we’re going back to the issue of hiring.

Another issue is your attitude as a CTO. I’ve always loved building products myself, but I also like building products through a team. If you’re in my position, if you’re responsible for a team, I think you need to learn to enjoy that.

Hire the right people, the creatively-hungry people, empower them through trust and remove unnecessary administration. That’s how you do it.

I’m not sure you can encapsulate this environment building into a process any further. You just need to remember that motivation is the byproduct of the environment, not the other way around.

Build an environment where your people can be motivated, and they will be. You can use the approach I outlined above or another one.

From what you’re saying, I think you may be moving toward a self-managed team. Is your team self-managed?

That seems to be the order of the day. The feature teams surely manage themselves. The Agile team is getting there too. They still report on a weekly basis. But the frequency picks up only if they run into some kind of trouble. That’s the way it has to be if you want to scale.

I can’t manage them all. They have to manage themselves. As long as you hire trustworthy people, you can be sure that they can do that.

Further reading & resources

It seems to me like you are the kind of person who learns by doing. But there must be some books or courses that you could recommend for creating empowering environments.

I’d definitely recommend Radical Candor which explains how to talk to your people. Another great one is Radical Focus. It’s about OKRs, and it really opened our eyes. We’ve had our ups and downs setting up OKRs and this book really helped me see what we did wrong. You might think that it’s somewhat broad for a CTO, but I think that one of my most important jobs as a CTO is to create a common ground between my team and other teams in the company — a company-level alignment. 

If you want to learn more about the Shape Up methodology, check out this book written by the 37signals team. It’s free to read. This approach really does help you create self-sufficient teams. If you value independence in your employees, their performance in the six-week cycles will help you verify the efficacy of your hiring process.

What’s next? 3 actions for you to take

What do you think about Ludwig’s approach to creating motivational work environments for software developers? Would you like to use some of his advice to overhaul your organization’s software developer productivity strategy?

Drive your software development team ’s motivation indirectly by:

1. Hiring self-driven people who love developing software and solving problems whether you look at their hands or not.
2. Focusing on objectives rather than tasks in your development process, letting your software engineer choose the methods to get there themselves. Encourage team members to be self-reliant!
3. Removing administrative tasks that cannot be proven to have a positive impact on your product development.

Good luck in creating a place that doesn’t require you to motivate software developers. And don’t forget to trust your gut feeling!

About Mediatool

Mediatool’s collaborative media management platform helps advertisers make the most of their ad campaigns by simplifying and streamlining the workflows for media planning, activation, and monitoring. The goal is to provide the best possible environment for building impactful campaigns and increasing ad ROI.