Disruption Insights: Build Rapport and Treat Direct Reports Like a Sparring Partner

Rodrigo is an empathetic leader with more than ten years of experience in the industry. His current responsibilities as Director of Engineering at CLARK, a digital insurance manager from Germany, span from shaping his department’s vision and achieving goals of the business, through mentoring and coaching engineering managers, to communicating with non-technical stakeholders.

We all know that well-defined goals and KPIs are crucial for the efficient organization of technical work, but we believe there’s more to that. Disruption Insights series aims to uncover how household names manage their tech teams and how it translates into business opportunities.

🎯 Engineering challenges

Exciting engineering challenge right now

We’re currently working intensively on building up the newly-founded and Europe-wide CLARK Group. The CLARK app is built on top of the German and Austrian market, with German and Austrian customers in mind, in accordance with the applicable law regulations. But, as the company keeps growing, it entails a whole new list of projects for the tech and product-facing teams.

In such a complex project, you need to think about the infrastructure, the platform, what providers and services we use at the moment, which ones we’ll need to use, and whether they’re allowed in the countries we may want to expand in.

Combining all these moving parts successfully is a huge challenge.

Other aspects that make this project challenging are: the data security protocols of the product, the way the application is organized, what its components are, and how they serve the different needs of international users. Some of them might be fully reusable, and others might not. We also need to keep in mind the scalability aspect. Building something completely new is not efficient, so we have to plan our work to scale the existing solution leveraging most of the work we’ve already done.

The last important component in this process involves finding that balance between being able to offer everything each country’s user needs and, concurrently, leveraging the right technologies.

💻 On the tech side

KPIs and missions essential to your role

The main metric I look at as Director of Engineering is how frequently customers are coming back into the application, how long it takes for them to come back, what actions they perform when they come back, and what kind of strategies we have to follow to win them back.

In terms of KPIs, most of them are connected with customer retention and frequency of use. We also monitor what customer channels we have and strategies we can adopt to keep the retention at a healthy level. We want to connect with customers regularly, but we also don't want to be annoying. We want to make sure our marketing efforts reach customers at the right moment, once they’re ready to start using our product.

Success in the software development process

There are several factors I look at when assessing a software development process. The bottom line is to deliver the expected results within a feasible time frame. Delivering the best solution is irrelevant if we deliver it too late. There are several metrics we can track to strike a balance, but the one I consider essential to my work is cycle time.

Speed is key, but so is the quality.

We want to make sure our customer is having the best experience possible, so it’s important to track incidents and defect escapes so that we identify the areas where we need to up our attention. The efficiency of the process is equally important – have we wasted a lot of time? Have we engaged many engineers to get the solution out? Or was it something that we could have developed with a small group of experts?

The experience of engineers measured by eNPS also plays a vital role in the assessment. Are people working on this particular project satisfied and do they feel engaged? Is the technical work interesting to them? Or do they have to deal with a lot of manual work or high overhead to get things done?

Approach to testing, implementation, and eventual rollback

Testing is a central pillar of our work at CLARK. A lot of new engineers join our teams regularly, and they don’t know what's happening with the project on the business, tech, and product sides. We’re talking about a product that was developed seven years ago. It’s a complex solution and while some parts are already extracted into separate components, others function in bigger chunks. That’s why testing is crucial for maintaining quality and the efficient pace of work.

Tests are an invisible entity that keeps everything together. Our goals include making sure our coverage is precise and all aspects critical for the business are properly covered. We try to make testing really efficient by applying the proper test pyramid on our test setup as well. Tests have to be pretty fast so that engineers can see what causes problems and fix them even faster.

This connects back to continuous integration and delivery. We aim to optimize these processes as much as possible.

Obviously, we don't want to test every part of the development process to the most extreme, but making our test infrastructure excessively brittle is not an option, either. We manage to find a balance here, and as we have five to six releases a day, the testing part is essential to keeping the product’s top quality and maintaining users’ trust.

Tackling technical debt

Technical debt is a part of the tech reality of every company that operates for two or more years. Especially in cases like CLARK’s, where we started as an extremely-fast growing startup, and we’re now moving to the scale-up phase. So, with the beginning of getting things out fast, delivering value, and learning from experiments, an organization may come up with solutions or approaches that – in the long run – are not necessarily maintainable and well-thought.

Tackling such a state of things is about striking a balance between discovering elements that are stable enough for certain features and deciding what to improve until we reach the point where we deliver as planned. To achieve that balance, we have a mix of strategies in place. Teams are expected to tackle technical debt regularly.

Each team is responsible for their own domains and experts should decide what parts of tech debt of their domain they need to work on next. They make those decisions taking into account the areas that are most critical for the product and the areas that are most frequently changed by the application. We also have platform teams that focus on cross-team and cross-code improvements. They improve the testing infrastructure and some components that are usable in different domains.

🤝 Internal cooperation

Organization of your units or departments

Our department at CLARK has a relatively clear and flat structure with three layers. The smallest unit we have is a team, and we adopt a cross-functional strategy to organize our teams. Each team is composed of Engineer, Engineering Manager, Product Manager, Product Designer, and QA Engineer. Each team is pretty much independent and responsible for a certain domain within a product or a platform, and they decide how they’re going to approach their goals.

Teams’ KPIs reflect improvements required for the business.

Each team is moved into different business areas like engagement or monetization. Every area is managed and guided by Director of Engineering and VP of Product. Then, above us, is the CTO.

Do’s and don'ts you’ve learned while scaling tech teams

In terms of don’ts, especially in the startup context, an organization has to be very careful about the speed you grow your teams at. When you have a lot of new people joining, it will take time for them to get on board.

It's important to have solid foundations in place for them to ramp up in a healthy, efficient, and productive way. Sometimes the needs and the pressure of achieving strict goals require growing fast, but it also necessitates caution.

Instead of making compromises here and there, it’s worth having a proper onboarding process, enabling the team to acquire the product knowledge, or get to know how the development is set up, how easy it is to set it up, and how maintainable it is.

Moving to don’ts again, you don't want to be creating entirely new teams, composed of new joiners, completely from scratch. I'd rather grow an existing team, expand their scope to a certain level, and then split them off with people who are experienced enough to carry over the team’s work.

Another thing on the list of don'ts is hiring people randomly, based only on their skills.

You should also think about how they work with others and compose a team that consists of people with different profiles. There are processes you can put in place, but some leadership experience is also required to successfully hire and build extraordinary teams.

Assessing candidates' soft skills and their fit for a team

As I’ve already mentioned, to recruit engineers that will create a cohesive unit, it’s best to use a mix of leadership and management experience with the right processes. At CLARK, we have internal processes for conducting interviews, we use several tools, and have a toolbox of recruitment exercises to assess candidates’ soft skills. It’s the manager’s role to choose which tool to use, depending on how they feel the person performs in certain situations.

There’s also the experience part I already referred to. As a manager, you interact with many team members so you can spot certain traits earlier, even in the recruitment process.

There are traits you can identify just by asking the right questions.

If someone is, for instance, very shy, their answers are going to be shorter so you can easily spot this characteristic. On the contrary, when a person is very self-confident, they're always going to react very quickly and give extensive answers with lots of details. They won't be afraid of speaking about their experience. So, if you are looking for that type of a person to join your team, you’re one step closer to hiring the right fit.

🧩 Hiring and team management

Making engineers satisfied and happy

The most essential thing to ensure engineers are satisfied at work is to maintain a connection between managers and employees. Managers should endorse frequent communication and listen to their direct reports carefully. It may sometimes be tiring to be constantly present, available for team members, and engage with them on a deeper level – yet it pays off.

Managers are responsible for running projects, communicating with stakeholders, and focusing on reporting, but this is what every manager does. What distinguishes an exceptional manager is how they connect with their team, i.e. understand their needs, weaknesses, and strengths, as well as look for different ways to help them.

Treating my direct reports like sparring partners and giving them support and independence is the most effective management approach for me. In the end, we are all humans, so it’s important to make a deeper connection, have frequent one-to-ones, and build rapport.

Thanks to that, I quickly realize when something is wrong. I can tell if people aren't happy or what they are happy with and take action accordingly. Often when there’s no understanding and connection between a manager and their direct reports, problems are identified when they are too big to be handled easily.

Skills and traits you look for in engineers

There are three main things which form the core foundation of what I’m looking for (outside of tech skills). I want to work with people who are motivated, transparent, and consistent players.

The tendency to be transparent can be spotted even during an initial interview.

Sometimes it just requires asking a question that is too hard to answer. If they are able to say “I don’t know”, it’s enough for me.

Instead of looking for rock stars, I’m looking for consistent players. I may search for a rock star on rare occasions when I feel a team needs one, but in most cases, they’re not a team’s foundation. By “a consistent player” I mean a stable person, who knows how to manage work-life balance. Such people tend to keep progressing and improving in time, becoming more and more productive, while working on their problems. They're transparent, so I know what's going on, I can help them, and I can be sure I have all the information I need to make informed decisions.

Leadership style you prefer

I try to come from a place of giving people lots of autonomy with little control and direct guidance, so my approach is more on the autonomy side. I truly believe that it’s the best approach because it enables you to see the people’s potential. It also doesn’t lead to team stagnation, curbing their development and growth, and making managers extremely busy.

Sometimes the results of this approach may not be fully in line with what’s expected, but it creates room for failure and constant learning. When I start working with someone, I always tell them that I appreciate independence, and it’s better for them to try and make mistakes than to always ask for permission.

💡 Looking into the future

Bets on the future of software development

I’ve seen a lot of movement in software development with new, highly specialized products or services hitting the market more and more often. These solutions usually address the needs of niche clients.

There’s also a lot of room for in-house development, but I feel that these almost bespoke, well-tailored solutions have a huge potential to change the way software is developed, making externalization easier and more secure.

It's something that we are trying to do internally at CLARK. Before we decide to invest in a certain development process, we answer the following questions: What do we really need and what is our business goal? How can we focus more? What is exactly the core of our business? Do we need to develop this resource internally?

The future of development teams organization

The most crucial innovation and certain challenges will still be kept in-house, especially in product companies. However, interestingly enough, the presence of freelancers is growing, especially those with vast networks, so I think we're going to balance between those external services and in-house development, trying to define where the definite line lies. Generally, we are moving from building every solution in-house to using external services yet keeping this precise distinction between what can be delegated outside and what must be handled internally.

Want to be a part of the Disruption Insights series? Shoot me an email at: paulina.burzawa@netguru.com

Read the first post from this series and more:

• "Zero Technical Debt Is Usually Not a Good Goal" with Bartosz Pranczke from Netguru
• "Promote a Quality Mindset Among Engineers" with Jenny Warnke from Delivery Hero
• "Pay Attention to Data Maturity" with Alexandre Lenoir from Spendesk