What was the Challenge?
Hypergrowth land is fun. Things change all the time. My challenge as a CTO was to shake-up the early-stage startup “snowglobe.” It was to transform “start-up” habits into a “scale-up” culture. It was to prepare and launch into hypergrowth. I took on this challenge because I saw the kernel of engineering talent that I could nurture and support.
What Changed?
Looking back at the time I’ve been there (it feels like ages in startup time!), so many things have improved. It’s hard to count all changes as the company constantly evolves. Here are some of the changes I’m proud to have influenced:
- Clear priorities – It’s easy to fall into reactionary mode and want to switch gears all the time. As the old saying goes, “If everyone is a priority, then nothing is a priority.” Engineering is always the bottleneck. Ideas are cheap. Ideas are easy. You have 5 ideas. I have 5 ideas. Engineers have 5 ideas. To maximise our opportunity, we needed to be clearer about where to focus attention. We now have a better planning process that enables clearer trade-offs and decisions.
- Almost 4x tech growth – When I first started, I looked around asking, “Where are all the engineers?” Our ratio of tech to non-tech was way off! We worked hard with the People team to change our recruiting strategy. We improved our onboarding process. I spent a lot of personal time writing articles and speaking on our engineering culture. The result? Tech is almost 4x the people compared to when I started. We also managed this while continually delivering value to customers too.
- A clear Target Operating Model – Change is hard. What helps is a shared picture of how we wanted to scale Product & Tech. You can’t have more people working on the same problem. You need to create a clear focus. You need to encourage high cohesion and low coupling across people and teams. We established a shared Product & Tech Target Operating Model. This model visualises and explains new structures, processes and how they fit together. Each iteration aims to addresses organisational smells and maximise Autonomy and Alignment. We’re working on our 3rd iteration of this now.
- Product versus Portfolio Management – We have individual product area priorities. We also have cross-cutting projects. We now can focus on ensuring the bottleneck or critical path has full support and attention. We can manage both product and portfolio priorities well.
- Fuller life cycle ownership in teams – When I arrived, we already had cross-functional teams. Not all teams were responsible for the full “life cycle” of a product. Sometimes back-office or operational processes belonged to a different team. The separation lead to queues and bottlenecks. Our teams are on a journey of integrating more responsibilities. They continue to extend the definition of done to remove hand-overs. We build security and quality in from the start. Teams can better respond to customer issues, incidents and build new or on existing products.
- Technical governance practices that scale – As we grow, we also focus on alignment where it makes sense. Organisations can only support a certain amount of variation or entropy. Alignment helps. We adopted a lightweight RFC process and iterated on our internal Tech Radar. We built decentralised support structures like Technical Working Groups and an Architecture guild. These work without relying on the same individuals to make decisions.
- Three Product and Technology Hubs around the world – We’ve moved from being completely centralised in Berlin to operating three successful P&T hubs in Barcelona, New York City and Berlin. We transitioned major product ownership to one office as it grew. The team evolved and released completely new features and services in record time. We’ve maintained speed and throughput, and quality remains high.
- Rapid growth of individuals – As a I leader I invest in people I work with. I’ve mentored, coached and trained many individually personally. It’s wonderful to see how it’s accelerated people’s growth. People have better ways to deal with imposter syndrome. Engineers have more impact and influence through stronger leadership skills. Better yet, I know they have done this with an explicit support.
- Diversity, inclusion and culture – I remember one big change I first made was removing a degree requirement for engineers. I created the #diversity slack channel. I sponsored the celebrations for International Women’s Day. This lead to a wonderful support of CSD in Berlin. Watch this amazing video! I know we’re not perfect but we are improving. Our gender ratio in tech can still improve. We have, however, built an inclusive culture where everyone in Product & Tech can express ideas in safety.
What’s next?
The CTO is one of the most confusing roles. Some call it a chameleon role. Companies have different requirements of the role. It changes rapidly in the same company (particularly one going through hypergrowth). There are just many different explanations. As our company grows, the needs of the CTO role grow and change.
As a leader, I found myself asking others (and myself), “How does this scale?” I’m constantly looking at ways to scale myself too. To scale with the growing set of responsibilities, we are splitting this role.
The CTO for our company, in our stage, demands a more operational, management and inward focus. I will step into a new role called, “Chief Scientist.” This new role takes a more outward focus and still guides the technical direction and growth of the tech team.
Our “Chief Scientist” role focuses on three areas:
- Representing the external face of technology
- Supporting and enriching technical decisions
- Accelerating the growth of people in our technical team
I’m look forward to refocusing my attention and energy. These areas not only bring significant value to the company, but also play to my strengths. Here’s to embracing constant change, evolution and experimentation!
PS. If you’re interested in joining me on building the bank the world loves to use, check out our open opportunities.
Congratulations Patrick. It’s great to see your growth and accomplishments through the years. Good luck in your new role as Chief Scientist.
Congratulations on all your achievements!
Regarding naming and roles: Germany drives me crazy. It keeps confusing the classic VP of engineering (people person) with the classic CTO (technical leadership) role. In German startups, CTOs often perform both jobs (clearly two separate people are warranted once you are past the initial stages). I should blog about it.
Thanks @Sanjoy! Really appreciated
@Dirk Thank you and I think you hit the nail on the head with that comment 😉
You are an inspiration. Cheers!
First off, congrats on your donning a new title. As someone who has enjoyed and learned from your talks, I’m sure you would do good justice in what you intend to do.
Out of curiosity if I may ask, how would you differentiate these titles one from another – “CTO, Chief Scientist, VP Customer Success, VP Engineering, Chief Solutions Architect, Director Engineering”? From my experience of reading JDs for these titles from companies around the world (thanks to LinkedIn) for many many years now, I see titles as just that fancy-dress competition thingy that a company presents to attract talent. To me personally, what matters is what one gets to do at work and how much of it one enjoys. But that is may be just me. How do you see (and wish to see) these titles??
Hi Warrior Of Peace!
Many thanks for leaving your comment. I think for your other question, this requires a much deeper answer and requires probably several blog posts. I would say that the the VP Engineering/Director of Engineering role has a relatively common understanding (at least in the Valley). I’ve not run into too many Chief Solutions Architects.
Here is a partial answer https://dirkriehle.com/2019/03/11/cto-vs-vp-of-engineering/
Good article! It reminds me of a rather old one about the same topic, but with a different approach:
https://www.linkedin.com/pulse/20140615184118-4928723-the-differences-between-a-cto-and-a-vp-engineering/
Hi Patrick, firstly I found this article really useful in considering the changing priorities of a growth business. When it comes to hiring; I often find myself taking briefs on positions under the titles VP Engineering, CTO, Director of Engineering with seemingly interchangeable duties. What would you say are the ‘killer questions’ which one can ask to separate out the responsibilities of these functions?