Christian Graf joined DCMN as CTO when his adtech startup, realzeit, was acquired by the company. After celebrating his one-year anniversary, I sat down with him to talk about what changed for the tech team, and get the story on what’s coming next.
Not only did you join DCMN when realzeit was acquired, but you inherited the tech team and became our CTO. What did the team look like when you started a year ago?
When I first arrived at the company, I met a team full of very talented engineers working in a structure that wasn’t allowing them to develop to the best of their abilities. Responsibilities weren’t always clear, and expectations between the business side and tech side were a little blurry, which caused a lot of friction.
Of course before taking action, you have to listen first. I asked everyone in the team what their pain points are, and what problems they were facing. Then comes the tricky part – If I took those answers verbatim and made decisions on that basis, I would have ended up somewhere very different. People tell you what their personal pain points are, but those might be symptoms of bigger problems. You need to dig down to the bigger issues that these stories are pointing to, and solve these rather than just their symptoms.
Once you found the root of these issues, how did you go about making improvements to the structure the team? What changes did you make?
The biggest change was creating interdisciplinary teams. We put groups of people together that share a common goal and have all of the resources and skills they need to deliver a product – a whole product, not just individual components. In this kind of structure, you create a sense of ownership. By giving people a common goal, you remove interfaces where “the blame game” happens. Now suddenly everyone feels responsibility for getting things done. [ctt template=”5″ link=”7ucex” via=”yes” ]By giving people a common goal, you remove interfaces where “the blame game” happens. Now suddenly everyone feels responsibility for getting things done. [/ctt]
We also took it one more step further than most companies, bringing tech and business people together within the teams. There’s no blueprint for this, and figuring out the exact details of this approach will be an exciting challenge and our main focus for the coming months. We already see positive dynamics unfolding and I look forward to seeing how it progresses.
These cross-functional teams act like mini-startups and make sure there’s a very short distance that information has to travel, while reducing topics that aren’t relevant to you. When you get a lot of input day to day, it can quickly feel like annoying overhead if much of that is irrelevant. But if you put the team in a structure where just the relevant information flows naturally, you make the whole thing feel like it’s not overhead. It becomes organic.
How about the development culture specifically? What did you focus on here?
An important change here was putting more of a focus on testing and code quality. There’s a big difference between perceived speed in product development and actual speed. If you start adding integration and end-to-end tests to your product, it often looks like you’re slowing down because you’re not building features. But what you’re actually doing is investing time into a long-term benefit, the quality of your product.
Through the focus on testing and quality, the team started to see the increased stability of the product and started to adopt it and care for it – and they have less fear of making complicated changes, because when you test, you can try things out without worrying that it will break the product.
Avoiding “religious” discussions (e.g. the tabs vs. spaces cliché), is crucial. You’ll always have disagreements about these things that are nothing more than opinions. Essentially, if you agree on one and follow it to its best-possible conclusion, you can arrive at good solutions with either. So you need to steer discussions away from these kind of opinionated topics, and have a certain agreement on what you perceive as good engineering, and what kind of decisions you need to make in order to go forward. [ctt template=”5″ link=”vWFN0″ via=”yes” ]Avoiding “religious” discussions (e.g. the tabs vs. spaces cliché), is crucial. You’ll always have disagreements about these things that are nothing more than opinions.[/ctt]
This interdisciplinary, cross-functional approach ended up gaining momentum and becoming an inspiration for a new model of teamwork across the company. What was that like?
The decision to finally roll out the interdisciplinary teams was a huge highlight for me this year. You could feel a big burst of energy in the company when it was rolled out and that was such a satisfying and rewarding feeling.
The sense that something needed to change in the organization was already there when I joined. It was clear that we were falling into this typical “bureaucracy trap”, where you try to solve communications-flow problems by adding more and more processes. And that ends up slowing everything down.
We saw we needed to break this false assumption entirely and build totally new structures to solve this problem. We didn’t have all the answers, but we worked on this for months and months. Reading the literature, it all seems so obvious and immediately makes sense. But applying the concepts to a complex organization in real life is an intensive process.
My experience in tech was a motivation to push for this in the DCMN teams as a whole. I had some practical experience with interdisciplinary teams and agile methodologies, which hopefully helped us to avoid some mistakes and sent us in the right direction.
Companies like Spotify and Netflix were inspirations for this. But even most companies that have interdisciplinary teams still have line managers who are responsible for making decisions on the business level. We ended up going even further, removing the line manager entirely. We thought that if we put people in interdisciplinary teams, and if they have the whole overview and are able to make the best decisions for the project, why give them managers? Why only go halfway? So we said, go all-in and let them make the calls themselves in a peer-to-peer way.
So if there are no bosses, what does your role look like now?
This change in structure poses a lot of challenges to people in leadership positions – you really have to redefine your own role in a way that you’ve never been taught. Not in the industry, and also not anywhere else at a company. It’s totally new territory.
In the beginning, I think I tried to force some technical changes too much, just because I thought it was a better way of engineering – but the pressure on those changes might not have been so necessary, and there were more important things to focus on. Just because things are done differently doesn’t mean they are done worse, or that they need to happen immediately. But in retrospect you’re always smarter. I’ve certainly learned a lot.
So now, I see myself as a consultant. I try to use my experience to help people to ask the right questions themselves and make them feel comfortable running the right experiments. It’s hard to say what a normal day looks like for me, because every day is different. I take a topic (whether it’s a technical topic or team topic) and start to dive into it, understand the structure of the topic, pick things apart, bring some order into it, augment it with some experience and knowledge and then give it back to people to actually work with it. And of course it’s important to make yourself available and approachable for help – I really want to be someone who is there for support when anyone from the team has a question or needs something.
How do you plan to keep developing the team? What are your hopes and challenges for the rest of 2018?
The existing tech teams are growing, and now we need to grow out more and more independent teams. That also means we have to start more collaboration and knowledge exchange between the teams. If you separate the teams completely, you basically have a handful of independent startups, but no exchange between them. Then there’s no point in being part of a bigger company.
The big question now is how to make the most of having the resources of a whole company behind these smaller entities. I would say we have this to some degree already, but we have to bring this to the next level. We are already working on this and I’m excited to see what the results will look like.
As the tech teams grow and more products are launched to the public, it’s going to be even more important to put effort into increasing our reputation as a tech company. We already created the role of product evangelist last year to take care of communications and be a voice for the tech team. Showing off tech successes outside but especially inside of the company plays a big role in self-esteem and the value and standing of tech as a part of the whole organization.
Interested in joining the DCMN team? You can find our latest job openings in tech and more at our Careers page.
