BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News The Importance of Leadership and Management in Hypergrowth

The Importance of Leadership and Management in Hypergrowth

Leia em Português

This item in japanese

At QCon New York 2019, Patrick Kua, chief scientist at N26, shared lessons learned sowing the seeds and fertilising an environment to cultivate high performing teams in a startup fintech company. In the first article Cultivating High-Performing Teams in Hypergrowth Kua explained how N26 deals with hypergrowth and team autonomy. This article explores how to manage technical managers in a fast growing company.

Kua mentioned that one thing he has learned as a software architect is that a lot of choices at an architectural level are about tradeoffs, and the same thing can be said about social and technical organizational structure.

Technology choice is key for enabling high-performance teams. Kua said: "When I first joined, I found myself repeating, ‘Why do we hire bright intelligent people, who are willing to learn and want to solve problems, only to turn around and tell them what to do?’". As a manager he tries to create the best environment by setting context, the constraints on what "good" looks like, and that includes good tooling that allows people to solve problems in the best way they know how to.

Kua also runs an internal tech lead development program at N26, which people who are existing tech leaders or seniors will go on. A lot of the skills that are required to lead a team are actually quite different and orthogonal to what an engineer normally is focused on, said Kua. For senior software engineers, many people see the tech lead role as more of the same role (making technical decisions, writing lots of code). "As I published in my book, Talking with Tech Leads, people find out very quickly it’s a significantly different role," said Kua.

InfoQ interviewed Kua about managing technical managers, technology choices, and growing leadership.

InfoQ: What are the decisions that managers of managers are responsible for at N26?

Patrick Kua: Managers of managers are responsible for thinking about team structures that enable collaboration instead of creating conflict; what groups are responsible for which product and to be as autonomous as possible while minimising dependencies on other teams to get their work done. This is a key responsibility of managers of managers. As Grace Hopper said, "You manage things and lead people." Managers of managers work to manage the system context to enable what people need - this is often about clarifying the purpose, ensuring there is a clear prioritisation and decision making process and ensuring that teams can plan capacity for work in a well-balanced way. The planning side is very hard in a rapidly changing environment!

InfoQ: Given your previous role as a CTO, I was wondering if you could comment on how much impact the technology choices you make at N26 have on the culture?

Kua: One of the interesting challenges at scale, particularly in a rapidly growing company and a rapidly changing industry, is that tools change all the time as well. And people obviously have preferences for different tools, so part of the art is trying to keep up-to-date with tooling but also trying to not have too much variation in tooling. I have a theory about entropy, and how much an organization can sustain entropy, and every change might add more entropy which can tip it into an overload.

We want to really equip our engineers with good tooling so they can focus on solving business problems and customer needs. We’re a very modern bank. Actually, we’re more like a tech company that works in finance, rather than the bank that you might traditionally think of. We do hundreds of deployments into production each week, which is unheard of in a very traditional banking environment. Normally you’re lucky if you could deploy every three months. This allows a really nice feedback loop for a team, which helps build a really strong engineering culture of both connecting a person’s output to a customer need, and immediate impact as well.

Then obviously, the tooling around that is key. Some concrete examples are that we use modern cloud infrastructure, and everything is build with infrastructure as code. It means that we can actually spin up new environments and services or scale things really rapidly if we need to. We have a very strong continuous delivery pipeline and continuous delivery culture. We’ve worked hard to shift quality and security left so that it’s owned by all teams and built in from the start. This also means we don’t rely on the armies of people traditional banks rely on, with checklists and processes. In that older world, it’s easy to fall into a negative reinforcing loop where you need more people to check the people with the checklists, and this results in unnecessary bureaucracy. We’ve focused our efforts on automation, and integrating quality and security into our ways of working. Our engineers get really fast feedback. It gives them more context and it helps people fail faster. That helps to build a really good engineering culture.

InfoQ: How do you go about growing leadership?

Kua: In the tech lead development program, I run a course where we talk about the expectations of tech leaders. We go through different goals and equip people with tools to help them get better at meeting those goals. The program also creates a community of people in a similar role who can then reach out to each other and ask for support when they’re dealing with a very difficult situation.

Existing tech leads or senior engineers who might consider this would be selected to join as part of the review cycle. It gives people an opportunity to consider if this role is for them, or to give insights into what skills and experiences may be needed to fill this role effectively.

I often talk about a Trident Model of career development- Technical Leadership, Individual Contribution (IC) and Management. Throughout the course, we focus on how people who might typically be focused on IC work (e.g. senior software engineers) need to shift their thinking to be more focused on skills required for Technical Leadership at a broader level (e.g. in the Tech Lead role).

Rate this Article

Adoption
Style

BT