Cultivating organisational culture is much like gardening: you can’t force things, but you can set the right conditions for growth. Often, the most effective strategy is to clearly communicate the overall vision and goals, lead the people, and manage the systems and organisational structure.
Many software delivery organisations have technical and leadership career tracks, and employees can often switch between these as their personal goals change. However, this switch can be challenging, particularly for engineers who may have previously been incentivised to simply solve problems as quickly and cleanly as possible, and an organisation must support any transition with effective training.
Much like the values provided by Netflix’s Freedom and Responsibility model, there is a need for all organisations to balance autonomy and alignment. Managers can help their team by clearly defining boundaries for autonomy and responsibility. It is also valuable to define organisation values upfront. However, these can differ from actual culture, which more about what behaviours you allow, encourage, and stop.
In this podcast we discuss a holistic approach to technical leadership, and Pat provides guidance on everything from defining target operating models, cultivating culture, and supporting people in developing the career they would like. There are a bunch of great stories, several book recommendations, and additional resources to follow up on.
Key Takeaways
- Cultivating organisational culture is much like gardening: you can’t force things, but you can set the right conditions for growth. The most effective strategy is to communicate the vision and goals, lead the people, and manage the systems and organisational structure.
- N26, a challenger bank based in Berlin has experienced hypergrowth over the past two years. Both the number of customers and the amount of employees have increased over threefold. This provides lots of opportunities for ownership of product and projects, and it creates unique leadership challenges.
- A target operating model (TOM) is a blueprint of a firm's business vision that aligns operating capacities and strategic objectives and provides an overview of the core business capabilities, internal factors, and external drivers, strategic and operational levers. This should be shared widely within an organisation
- Pat has curated a “trident operating” model for employee growth. In addition to the class individual contributor (IC) and management tracks, he believes that a third “technical leadership” track provides many benefits.
- People can switch between these tracks as their personal goals change. However, this switch can be challenging, and an organisation must support any transition with effective training.
- Pat recommends the following books for engineers looking to make the transition to leadership: The Manager’s Path, by Camille Fournier; Resilient Management, by Lara Hogan; Elegant Puzzle, by Will Larson; and Leading Snowflakes by Oren Ellenbogen. Pat has also written his own book, Talking with Tech Leads.
- It is valuable to define organisation values upfront. However, these can differ from actual culture, which more about what behaviours you allow, encourage, and stop.
- Much like the values provided by Netflix’s Freedom and Responsibility model, Pat argues that balancing autonomy and alignment within an organisation is vital for success. Managers can help their team by clearly defining boundaries for autonomy and responsibility.
- Developing the skills to influence people is very valuable for leaders. Influence is based on trust, and this must be constantly cultivated. Trust is much like a bank account, if you don’t regular deposit actions to build trust, you may find yourself going overdrawn when making a deposit. This can lead to bad will and defensive strategies being employed.
Subscribe on:
Show Notes
Can you give an insight as to what your talk at QCon NYC on "Cultivating High Performing Teams with Hyper Growth" will be about?
- 02:45 I use the word "cultivating" because I joined n26 as the CTO, and looked as myself as the guardian for the technology.
- 02:55 Part of that is taking the gardening metaphor of creating the right environment to allow other people to thrive.
- 03:00 Just like a garden, you can't force plants to be successful, and there's interesting questions as to what sort of garden you want to have.
- 03:05 Are you, for example, designing your typical British garden with winding ways, or something more modern, and that's the mentality I have around building an organisation.
- 03:20 My philosophy is that you lead people, and manage the systems and structure.
- 03:25 For me, I wouldn't be joining each team individually - we're quite a large organisation, and we're going to grow even further.
- 03:30 The idea behind is that we need to cultivate an environment so that other people in the team have the best chance of success at being a high performing team.
Can you give us some insight as to how much n26 has grown since you've been there?
- 03:55 N26 is a challenger bank, based in Berlin, so we have a German banking license.
- 04:00 This means we operate in the EU, and in late November we launched in the UK as well, and we'll be in the US over summer.
- 04:15 We're aiming to grow quite a lot; but being a bank isn't easy, as there's a lot of regulation.
- 04:20 Regulation is good for a reason - it helps you protect things.
- 04:30 We have a lot of things to do with lots of different markets, and we want to try out different hypothesis.
- 04:40 The more people we have can develop more products in parallel or work on more infrastructure and help us scale will really help.
- 04:50 To give you an idea of where we have come from, I joined in September 2017 - almost two years ago - when we had 450,000 customers.
- 05:00 Recently, we announced that we have 3.5 million customers across Europe - so that's quite a growth.
- 05:10 When I started, we had around 350 people - now we're about 1300 people.
- 05:25 For technology, we had to grow that even faster than other parts of the business.
- 05:30 You might expect for a tech company there is a healthy ratio between different parts of the business.
- 05:35 Anyone who has ever tried to hire engineers knows that it's a difficult market to hire in.
- 05:40 We were able to hire project managers, business people, much much faster than engineers, so we had a disproportionate ratio between people who had ideas and those who could build it.
- 05:55 One of the benefits I had was to manage expectations on the leadership team to scale in an appropriate ratio.
Can you give any tips or tricks for how you recruit?
- 06:30 My philosophy about recruitment is that you can offer certain things: the business that you are in, or the opportunities that you can provide.
- 06:40 Today, everyone has the option of lots of different things you can have.
- 06:45 For me, recruitment is a two-way street: it's letting people know what you offer, but also finding if the people are a good fit for that.
- 06:55 You have to pay competitively for the market, but I don't think you win people over by being the best, because anyone else will be able to offer much more.
- 07:00 What I think is more unique is about trying to create something that aligns with their own personal goals and interests.
- 07:10 What I talk about with my training courses is you're always trying to find what opportunities people want to allow them to grow, and to try and match that as much as the environment can do in your area.
- 07:25 You should be very transparent in recruitment what the opportunities are for growth or impact, and it will attract those that want that.
- 07:45 It has also shaped the processes.
- 07:50 Hyper-growth can seem like it's chaotic, but it allows people to step into leadership opportunities, because there are so many things that need to be taken care of, and you need everyone to pitch in and own that topic.
- 08:05 It's a great opportunity to shape the process and have the opportunity.
Have you looked into the individual contributor/management tracks?
- 08:35 One of the things that I'm going to talk about is the operating model, with different roles and how people grow into them.
- 08:45 As a company overall, as you go from early-stage start-up to a more mature is what they call a levelling framework.
- 09:00 This allows us to understand that the head of one department is the same as the head another department.
- 09:05 What happens in a start-up is that people tend to adopt random titles, and then you're talking to a Director or VP and no-one understands what these mean.
- 09:15 As an organisation - not just as technology - was trying to get an understanding of what the levels are between departments, and once we'd agreed those levels, then we could map that to technology.
- 09:35 We've defined a couple of tracks; the Trident model (IC and Management) - but a lot of people who talk about high levels in IC are Principal Engineering, Architecture, Technical Leaders.
- 10:00 In a Trident model, we talk about management - people hiring, culture, delivery of projects - versus technical leadership across the organisation.
- 10:20 We have a Principal Engineer, who gets technical decisions across many teams in the organisation.
- 10:25 It's not a pure IC, because they're not doing anything themselves, they're trying to co-ordinate technical agreement amongst groups to get consensus about a direction.
- 10:40 We're slowly developing the IC track - a company of our size doesn't need many levels in a company of our size.
- 10:50 We have introduced a Staff Engineer, which is a seasoned expert which will mostly stay individual contributing; writing code, doing tasks, but 70-80% of the time is doing something.
- 11:10 Often the tasks will be in complex areas, highly performance intensive or super complex or interacting services.
- 11:30 This is high-value/high-impact, but still as an IC.
- 11:35 This is where we talk about three tracks; they're not exclusive - it's healthy to have people move from technical leadership to management and vice-versa.
- 12:40 What we have defined is that management need to have a basis in engineering - they don't need to be the best developer, because they're not going to be making the best decisions - but we have other experts that will create the technology.
- 13:05 They need to understand the software and the whole lifecycle.
- 13:10 You have to think about inter-team dependencies, and communication, and they're different skillsets from engineering.
- 13:30 That's not true for all people: there have been people who have transitioned, and they've got the strong basis of being a technical lead.
Leadership problems are difficult to debug.
- 14:10 In a team level and an organisation level, things are unpredictable.
- 14:25 You can catalogue patterns, but you cannot predict how someone will act.
- 14:35 Archetyping will help build potential strategies for difficult conversations that might happen.
Have you got any recommended books about transitioning from technical to management?
- 14:55 The manager's path by Camille Fournier is great.
- 15:05 I'm pleased about this journey because there's a lot more relevant and are highly recommended.
- 15:20 A recent book "Resilient Management" by Lara Hogan has just come out, and I would also recommend "An Elegant Puzzle" by Will Larson, and "Leading Snowflakes" by Oren Ellenbogen.
- 15:45 I have also written "Talking with Tech Leads" - from moving from being an engineer to being a technical leader.
How do you go about establishing a vision and values in a company like n26?
- 16:20 We have had company values that have been from the beginning; but there's a difference between what's stated and the culture, which isn't something you write down.
- 16:30 It's about the behaviours that you allow/encourage, or those that you stop.
- 16:40 It's about leaders and managers encouraging that behaviour, introducing new behaviour - and that's the culture; it's hard to codify that.
- 16:50 Talking about the freedom and responsibility - what we talk about in our operating model is talking about balancing autonomy and alignment.
- 17:00 With autonomy, everyone's autonomy is bounded at some level.
- 17:10 We have expectations in an organisation, and we have boundaries everywhere.
- 17:20 The managers need to set where the autonomy is bounded, and where they can exercise their autonomy.
- 17:25 We were very explicit in our target operating model, trying to give a lot of freedom and autonomy; but importantly, where it is and where it is not.
- 17:35 As an example, my freedom as a CTO was limited with the technology organisation: I can give input into buildings, but that's the accountability of our office managers.
- 17:50 I can influence, but it's not my autonomy.
- 17:55 That's the same thing at the team level; we wanted to make sure that every group had a purpose and a goal, and how they would like to achieve that.
- 18:10 I believe in outcomes rather than methods: when we talked about agile in our organisation, we're not prescriptive in Kanban or Scrum or XP; we want people to demonstrate good principles of agile.
- 18:35 We want to be prescriptive about the outcome, but how it's achieved is not prescriptive.
- 18:40 As an example, all people have some level of automated tests.
- 18:45 If they want to do test driven development, that's their team choice, but if they want to test after that's fine as well.
- 18:50 It's the same with pair-programming: we expect code to be code reviewed, but if they want to do pair programming in their teams, that's fine - but it's not a standard across the organisation.
Could you give any insight into how to influence your peers or in the management chain?
- 19:25 There are so many books on this topic, and this is probably a whole podcast in itself.
- 19:30 I've had a lot of benefit influencing as a consultant for Thoughtworks for 14 years, and one of things things you learn as a consultant is that you don't have the authority to do anything.
- 19:40 You're always leaning on the borrowed authority of your sponsor, so you're always having to influence.
- 19:45 One of the things I teach on my tech lead training is that your influencing skill will be stronger or weaker depending on your trust with people.
- 20:00 I talk about having a piggy bank of trust with each person, and the bigger your piggy bank of deposits of trust are, the more when you ask a favour you'll be able to take out of that.
- 20:15 If you have an empty piggy bank, then you have to go overdrawn, and you might get defensive behaviours or resistance as a result.
- 20:25 My biggest advice is to decide how you can build up trust with everyone every day, for every single interaction, before you need to influence.
- 20:40 One observation I've had with people who have transitioned into leadership - particularly people who are very critical in a negative way - it's not always about the message that you're projecting but how you're projecting it.
- 21:00 If complainers move into a role of leadership, and that's their style of communicating, it doesn't build up a lot of trust between people.
- 21:10 When you're a manager or a leader, you're expected to not only present problems, but be able to help solve them.
- 21:20 Everyone can come up with a problem; but what do you do about it - that's one of the hardest things in transitioning.
Is there anything you've learned since your "Talking with Tech Leads" book was published?
- 21:35 It was published in 2015, which in IT years is a long time.
- 22:00 The content is still valid; what I've done since is doing some ad-hoc training for different organisations, and run one internally as well.
- 22:15 It's about influencing, architecture, infrastructure, conflict resolution and so on.
- 22:30 One thing I've learned since running it many times is that the shock of moving into it is true.
- 22:40 One of the things as an industry that we don't do is recognise that it's a different role with fundamentally different skills with little overlap.
- 22:45 There's a whole bunch of skills as tech leads that we don't prepare people for the first time.
- 22:50 There's a big shift in expectations between engineers thinking that they're going to make all the decisions; actually, not any more because you have a whole bunch of people who want to solve problems, and they won't want to work for you if they aren't getting to make those decisions.
- 23:10 You have to take a leadership approach, which is a different position.
- 23:15 You have to develop leadership skills, architecture skills, and could be quite a big leap for some people.
- 23:25 I describe that is probably the biggest leadership hurdle for technical people who are moving into a leadership role.
- 23:30 If you consider marketing, or people team, they naturally have to work on conversations and influence building as part of their daily job.
- 23:40 Those skills naturally translate into a leadership role as they step into that job.
- 23:45 If you think about working in a software team as an engineer, influencing and conflict resolution are not necessarily skills you're going to get rewarded for.
- 23:55 Hopefully collaborating as a team member will still be good, but that doesn't necessarily translate into leading.
- 24:05 We're often rewarding engineers for how they solve the problem, for how elegant their code is or creative problem solving.
Do you find yourself "Building Evolutionary Architectures" based on your original book?
- 24:45 I talked about this early on when I got to n26, and we try to encourage making our system constantly changeable.
- 24:55 One of the exciting things about moving from a consulting role to a startup, is that everything changes.
- 25:00 The industry that we're working in is changing, the technology is changing, and our product needs to respond to customer feedback.
- 25:10 We need to change our product, our service and organisation need to adapt to those changes as well.
- 25:25 That works quite well with the building evolutionary architectures philosophy.
- 25:30 One of the things that we haven't been able to do is implementing a lot of the automated fitness functions that we were talking about.
- 25:35 We have a number of things embedded into our continuous delivery pipeline, but one of the challenges in any organisation is figuring where you invest in technical infrastructure and balancing product development.
- 25:50 That's a delicate balance to manage.
- 25:55 We've got practices that give us a lot of safety and feedback to allow us to change systems.
- 26:05 We could do more on automated fitness functions, but you could always do more.
