Several years ago I spoke at a conference, well known for being diverse and inclusive. One speaker, in front of the entire crowd, made a cheap joke of PHP on stage. Instead of the expected laughter, there was an empty, awkward silence. Immediately afterwards, the host called out this unwanted behaviour in front of everyone.
I remind myself of this super-awkward situation when I prepare talks these days. As a speaker, I recognise I have a platform. With this privilege, I can encourage more inclusive environments.
“Diversity is being invited to the party; inclusion is being asked to dance”
Here are five actions you can take to be more inclusive as a conference speaker:
1. Use gender neutral names
When telling a story, I substitute gender neutral names. Unsure about what you can use? Check out these Babynames.biz, BabyNames 1000 and Name Playground. Feeling even lazier? Try these three names: Casey, Kris, Morgan.
2. Use gender neutral pronouns
Avoid using “he” or “she” unless you’re referring to a very well-known person such as Ada Lovelace, Marissa Meyer or Bill Gates. Opt for terms like “you” or “they”. No one is going to notice and it’s more inclusive.
3. Increase your font size and use pictures, not (just) words
Imagine you’re sitting right at the back of an auditorium and you have bad eyesight. Imagine you have people’s heads in front of you. Huge text is simply more visible from way back. Don’t practice sitting in front of your computer. Practice from the other side of the room. Pictures can underscore what you’re saying and add to the story.
4. Avoid cheap jokes at the expense of others
It’s very human for communities to form around programming languages. It’s rude to make a cheap joke at the expense of another community. Be careful with your humour. What may be funny to you, may be offensive to others. Avoid being crass.
5. Encourage conferences to diversify representation and be more inclusive
I’ve declined speaking opportunities because speakers were 90% white men. Don’t accept the, “But it’s a pipeline problem,” excuse. Point them to Jez Humbles post, “How To Create A More Diverse Tech Conference.” Point them to examples like Craft Conference, Lead Dev London and GoTo Copenhagen. Ask if they have a Code of Conduct. Inquire about they do to be more inclusive. Some conferences offer vegan meals. Others offer child-minding facilities. Some offer diversity scholarships and conference guides. There are even conferences with a stenographer for live subtitles! It’s impressive to watch, particularly at a tech conference!
Your action can have a positive impact
We have made progress in improving D&I in some parts of the world and in some communities. If you speak at conferences or events, use your platform to nudge our industry in a better direction. We need all the help we can get.
I’d love to hear what worked for you in the past. Leave a comment about what you have done to increase inclusion.
One of the greatest challenges for leaders in tech is keeping up to date with tech. I consume a lot of information these days. As a result, I want to share what I think is very useful for other leaders in tech through a newsletter, Level Up (http://levelup.thekua.com).
I will share articles and trends around technology, architecture, leadership and management. I love learning and I hope you learn something from it too. I aim to share relevant content for people playing roles such as Tech Leads, Engineering Managers, VPs Engineering and CTOs.
In my constant journey of learning, I stumbled across Will’s blog. Add it to your RSS feeds today (assuming you still use one these days!) If not, at least go back and peruse the great entries Will published. It was through his blog that I learned about his upcoming book and joined the waiting list. I bought it as soon as it came out and pleased to say I’ll be recommending it from here on.
Managing engineering teams is different from many other fields. Software systems interconnect via invisible API, data or tech dependencies. While the pace of software increases, so does the tech stack complexity. Any reasonable software product demands strong collaboration across many people. All these people often have very different backgrounds and skill-sets. Harmonising and optimising this ever-changing environment demands managers understand complex adaptive systems.
When I read Will recommending Systems thinking early on, I knew this was going to be a good read. You can’t manage modern software organisations with Tayloristic mental models.
What’s in this book?
The book contains five main sections Organizations, Tools, Approaches, Culture and Careers.
This section covers many elements of effective organisation of engineering teams. It discusses optimal team sizes, breaking points, varying structures and trade-offs. Many people underestimate the impact of the poorly designed organisation. Yet many people suffer within them. This topic is also close to my heart, as an advocate for the Inverse Conway’s Manoeuvre and the Target Operating Model (TOM) I recently wrote about.
This section is the largest in the book. It offers a broad range of concrete and actionable advice. This section covers everything from systems thinking, basics of product management, vision and strategies, metrics, how to deal with migrations and reorgs amongst many more.
This section highlighted the author’s variety and breadth of experience. Not all engineering management will find themselves in each of these situations. It’s useful to have tools to approach these situations in advance.
I like to describe this section as the author’s personal style to engineering management. It covers how to handle execution, personal philosophy’s, managing in growth and common traps.
Of all the sections, I found this the most opinionated. It may or may not suit you, the reader.
This section covers deliberate approaches to cultivating culture. An example is the opportunities you create and who you offer these opportunities to. Another example is reflecting on the representatives you have with your leadership team. A final example are the ranges of policies and the impact that has on the types of freedom.
In this section, I learned the concept of negative and positive freedoms. These are sometimes referred to as negative or positive liberties. Negative freedom is the freedom from external constraints, freedom of interference, or absence of external limits. An example of negative freedom is the USA’s right to free speech.
Positive freedom (or liberty) is the ability to act on one’s free will, or the absence of internal limits. Examples of positive freedom include personal growth and self-mastery. This article has some great examples of positive freedom.
This section covers everything to do with the employee lifecycle at a company. It covers sourcing, recruiting, interviewing, performance management and career growth.
My thoughts on the book?
This book will appeal to a broad range of people. Those considering engineering management will taste the different set of responsibilities expected in the role. Existing engineering managers will grow their toolkit and discover new ideas. Directors or VP Engineering will particularly benefit with concrete approaches to managing managers.
This is an opinionated book. The author offers approaches that worked for them across many situations. You won’t find a rule book or a guided how-to. Instead, you will find a wealth of experience packaged into actionable chunks. This may or may not be relevant to your current situation. It may or may not suit your own personal style. That is part of the difficult and challenge of effective management. An Elegant Puzzle offers you a head start.
What would I like to see done differently?
I understand how hard it is to write a book, and it’s rarely perfect. Two of my issues stem from reading the book in its digital form. Unfortunately the printed copy was not available in Germany, where I’m currently living. My first is the regret of not experiencing the beautifully designed front cover. I’m sure it’s a better experience in real life than on the Kindle. My second issue also stemmed from this, with some of the visuals being hard to read on the kindle. My final issue was the constant use of the word, “resources,” when I’m pretty confident the author meant, “people.” At least in many cases.
Highly recommended. Grab a copy now!
Agile methods and practices went mainstream over the last two decades. We’ve improved our architectural, technical and processes landscape. It’s time we pushed our management and leadership practices even further. An Elegant Puzzle is a great addition to the field of engineering management.
I had the pleasure of sitting near Lara Hogan at the Lead Dev London conference this year. She hit off day 1 with her opening talk, “Navigating Team Friction” (highly recommended!). The conference coincided with the launch of her newly published book, “Resilient Management”. I’d pre-ordered a physical copy as these were only available in United States.
Who this book is for?
This book will appeal to all types of managers, regardless of industry. This means managers in product, design, engineering or others will learn from it. Many stories and examples will resonate stronger with those in technology, given Lara’s background.
What is in this book?
Resilient Management has five sections. Each section builds upon the previous. The book grows like your relationship as a manager develops with your team over time. These sections are:
Meet The Team
Grow your Teammates
Set Clear Expectations
The book provides clear, direct and actionable ideas for managers. Lara covers topics like:
Understanding individual’s core needs
Giving effective feedback
Making meetings more effective
Contrasting different communication styles
Clarifying roles and boundaries
Building your own support network as a manager
If you’ve heard Lara speak, you can almost hear her voice throughout the writing. Her people-oriented leadership style shines in each chapter. It’s not all warm and fuzzy though. The book offers many templates, coaching questions and links to worksheets. Each offers you an opportunity to kick start conversations or develop your own style. New managers will leave with many potential starting points. Experienced managers will have some new ways to start or engage conversations. I finished with a few new ideas and tools to add to my leadership and management toolbox.
Would I recommend this book?
Absolutely. Resilient Management is an accessible book full of practical and actionable tips. Its thinking models and tools will grow and improve your own management craft. Get a copy here.
A few weeks ago, I published an article about how we grew Product & Tech (P&T) at N26 during hypergrowth. I introduced the idea of a Target Operating Model (TOM). The first article focused on the why and what of this tool. In this article, I will share how we’ve evolved the core “building block” of P&T at N26.
From nominal teams to stable Product Teams
When I first started at N26, we had a set of cross-functional teams. This meant that we had people from Product, Design and Tech all sitting together (yay!) We had some organisational smells we wanted to address.
One such smell was a person moving from one team to another on an almost weekly basis. It also felt like a team’s focus would change on an almost weekly basis. Teams were rarely stable. The result was a lot of activity, but not a lot of outcome.
Our first TOM formalised the expectations of a Product Team. Each Product Team had an ideal size (up to 8) and a product area to focus on. Each team then focused on the evolution and support of that product area. We mapped out the complexity of our product set, to our team size and realised that we had many gaps to fill
A large goal of our first TOM was to bring sustainability to product development. We needed to move away from relying on a handful of individuals (common in a startup) to a more sustainable model. Comparing our rate of hiring to our current needs, and needs for the future showed a huge gap. We kicked off an initiative to improve our recruiting, onboarding and retention approaches.
Part of this model revisited responsibilities of the informal leadership of each team. Instead of having a Product Owner and Tech Lead, we added in an Engineering Manager at a Product Team level. We wanted Tech Leads to focus on managing and aligning technical complexity. We also wanted to provide people with the environment and people support. When a Product Team was small, this was manageable As a Product Team grew, Tech Leads could not focus on both areas well.
From Product Teams to Product Groups
As we filled empty roles in Product Teams, we addressed what we wanted to. Engineers felt less overwhelmed. People could take holidays without worrying about being a single point of failure. We had deeper conversations around architectural direction. We also started having conversations about individuals’ career growth. People had more consistent 1–1s and feedback.
As we grew and changed, we noticed some new trends and organisational smells. As an example, some Product Teams reached the boundary of a reasonable team size. We needed to start splitting teams to minimise communication overhead. Some Product Teams also demanded a stronger focus on skills. As an example, our Payment Product Team was more integration heavy. Our Onboarding Product Team needed more front-end skills. Each Product Team needed more flexibility in how they structured themselves. Sometimes a product area needed a short-lived task force. We wanted to push more self-organisation downwards.
As a result we introduced the idea of a Product Group in our second TOM. A Product Group has 30–40 people from a cross-functional mix of Product, Design and Tech. A Product Group still had ownership over a product area. A Product Group had more autonomy to shape their own team structures and ways of working. We also made sure Product Groups knew company or global standards.
This meant that it was perfectly ok to have a Product Group with 5 teams. Or to have a Product Group with 3 teams and one small task force. Each Product Group had more flexibility to better fit their product area at the time. We expected Product Groups to be explicit about their choices and trade-offs. To aid this, the second iteration evolved the role of the Engineering Manager. Rather than being at a team level, the Engineering Manager moved to a Product Group level. This non-trivial decision deserves its own article, so I won’t discuss it further here.
From Product Groups to Product Segments
Our organisation continued to grow. An internal sample of different Product Groups showed more heterogeneity. Product Groups continued to ship product. Product Groups had more capacity to breath. Product Groups had more capacity to deal with more complex topics. Product Groups handled unplanned work better, minimising impact to other Product Groups. Product Groups had more people with relevant skills for their product areas.
The number of Product Groups continued to grow. We noticed that some Product Groups should co-ordinate more with some other Product Groups, but weren’t. As our business grows, domain complexity grows. We wanted to find a way to keep inherent domain complexity highly cohesive but low in coupling . Product Groups alone were not solving this. We also knew that some areas needed further domain knowledge and specialisation. Hiring needs started to differ.
To address these issues we introduced the idea of a Product Segment in the latest version of the TOM. Product Groups working towards the same goal sit within the same Product Segment. Product Groups within the same Product Segment should better communicate and align their plans with each other as they should be more related to each other (highly cohesive). Hiring plans will now be made on a Product Segment basis.
Reflecting on our journey evolving our TOM
Our latest TOM is still recent, so it’s early days to see it’s impact. When designing software architecture, you consider explicit trade-offs as part of decisions. This is also true if you consider organisational and team structures. No organisation or team structure is perfect. You need to ask yourself, “What are you optimising for right now?” “How are you maximising autonomy and alignment?”
Building Evolutionary Architectures tells us to design software systems for constant change. Organisational systems are no different. A company rapidly growing needs to optimise for different issues at different scales. It won’t help you to copy our structures if you don’t share the same issues. Gather input and reflect deeply to consider what you need to optimise for. Evolve, document and communicate the TOM best suited for your situation.
In this article, I will share its origins, its purpose and where we found it useful. I plan on sharing some details about our current model in a different post next month.
What’s the problem?
The CTO role is one of the most misnamed roles of all C-level roles. Its responsibility vary across companies and industries. When I first joined N26, I described my role as being the shake-up CTO. Imagine a snow globe where the snow had settled on the ground. The snow represents a company’s habits and processes optimised for finding a product market fit. Super useful abilities in a very early stage start up with lots of unknowns. Pivoting a product until customers rapidly sign up.
As more and more customers join, they give feedback. The rest of the business continues to grow as well. More ideas on product enhancements or improvements flow in. During this stage the core business does not change. The biggest challenge at the stage is quickly trying new ideas *whilst* not breaking anything. Growing both speed and stability are key factors here.
Early stage habits and processes break down. Daily changes in direction leads to a lot of activity with few outcomes. Two people making a decision face-to-face excludes gathering input from others. Verbal communication results in missing context for other parts of the organisation.
Imagine a world where customer numbers double every six months. Or where the number of employees doubles every twelve months. Would your organisation be able to sustain that?
What’s the solution?
Our snow globe needed shaking. I wanted to keep useful habits and processes. We also needed to establish other habits and processes that would better scale. I needed to transition our company from startup to scale up.
To do this, we could tackle this one issue at a time. Wait for an issue and react. Or we could copy what other organisations do (e.g. let’s do with Spotify does). I wanted to address our issues and our context. I wanted to do this as intentionally as possible. I also wanted to do this in a way that scaled, not one issue at a time. This gave birth to our TargetOperating Model (TOM).
What is the Target Operating Model (TOM)?
The TOM provides a shared view of how Product & Technology (P&T) should work in the next 6-12 months. The name fit well for what I wanted to communicate. Let’s break it down.
Target – The TOM doesn’t focus on where we are now. It focuses on where we are heading as an organisation.
Operating – The TOM doesn’t compete with our product roadmap. The TOM focuses on how P&T works best in the anticipated context.
Model – A model is never perfect. A model is an approximation. Our TOM works with the Pareto principle (80-20).
I versioned our first Target Operating Model (1.0) as I knew we would want future evolutions. As we evolve our product, we would also evolve our operational model.
Important elements of the TOM
Like a good Architecture Decision Record, the TOM outlines the organisational context. We included the current state of the organisation. We highlighted what’s working well in the organisation (what we should keep). We also summarised current pain points across the organisation. We also included some discussion about where the entire company was heading.
After outlining the situation, our TOM focused on what was next. The TOM introduced a few principles for decisions, not only the decisions themselves. I find articulating principles useful for highlighting why we made certain decisions. The TOM introduced new roles (skills, capabilities and responsibilities). The TOM also set expectations for changes in existing roles. Many people often ask, “What’s in it for me?” or, “What’s changing about my role?” and I wanted to provide people clarity on this.
An important part of the TOM is new terminology about structures. I’m a big fan of DDD and the idea of a ubiquitous language. For example, “Do people have the same mental model when you describe a team?”
The TOM also provided visualisations how how our organisation would “look” different. Visualisations provided a way for people to link different concepts together. Imagine the visualisations as the new patterns that settle, after shaking the snow globe.
We also added gaps and next steps in our TOM. A TOM won’t every be comprehensive. As the old saying goes, “Perfect is the enemy of good.” A TOM cannot address all pain points so we found it useful to acknowledge known gaps. Next steps provided answers to the question, “What will change and when?” and, “How does this impact me?”
What was the result of using the Target Operating Model?
I introduced the first Target Operating Model over 18 months ago. As of this article, we’re now on our third iteration (TOM v1.2) and more than five times the size we were back then. Nothing grows at the same rate in a hypergrowth environment.
Given that, the TOM has been a useful tool. The TOM provided a shared vision about where we were heading. Hypergrowth creates a lot of uncertainty. The TOM created some certainty in a very turbulent environment.
The TOM provided a shared basis to have useful conversations. The TOM set expectations about change, even when you couldn’t predict when change would happen. More importantly, the TOM provided transparency across the entire company. It wasn’t information held by a select few. Everyone had the opportunity to understand, reflect and a chance to demonstrate leadership and a step towards the desired direction.
I recently came across Diversify Your Feed. It reminded me of a tool I forgot, called “Proporti.onl.” Both tools estimate the gender distribution of people you follow on twitter. I was interested to see how my twitter feed did.
What a surprise and disappointment!
There are many reasons to support diversity. A 2018 study from BCG found that diverse management generates up to 38% more innovation revenue. The analysis went further to find four key diversity factors that influence this too:
Country of Origin;
Career Path; and
Inclusion matters as much as diversity. After all, there’s no point in finding diverse sets of people if your environment excludes them from contributing. I also realise there are many other types of diversity other than gender. I can imagine writing a tool to categorise other types of diversity may be much harder.
I wasn’t expecting a 50-50 ratio for men/women for my twitter. I was surprised that my twitter account scored really really low! Here are five steps I took to diversify my own feed. I hope they serve you well too.
1. Collect data on your feed today
Run “Diversify Your Feed” and “Proporti.onl” to see how far off your feed is. You influence less the followers you have, but you can control who you follow.
2. Find inspiration from tech conferences with a diverse set of speakers
Many modern tech conferences recognise that diversity and inclusion are important. Many support blind CFPs, or specifically ask if people identify with a minority group. Others reach out to proactively build a diverse speaking group. Many try to support and inclusive environment with tools like a Code of Conduct.
I searched for terms like “inspirational women twitter”, “women in tech 2018,” and “great women leaders list.” I’m sure you’ll find others too.
4. Look at their “Followers”
People are often connected to people like themselves. Twitter makes it very easy to look at people’s followers. Look through a person’s followers list for inspiration. Using this approach helped me find connections I would never have before found.
5. Take action and follow them
I used to have specific rules when following people. For example, I had a rule that I would follow someone I either worked with before, or least met them in real life. Don’t let rules like these hold you back from being exposed to more diverse ideas and opinions.
You can unfollow people if your feed becomes too noisy or less relevant.
Give people a chance. Follow a broader selection of people today.
You may wonder what applying these rules did for me. The result? See below:
What’s your tip to diversify your feed?
With a little bit of data and a few concrete tips, I am exposed to more diverse thoughts and people. I hope these tips help you as well.
Leave a comment if you have additional resources or tips!
The XPand Conference (Amman, Jordan) invited me to speak on one of my favourite subjects. It’s the first big tech conference for Amman, organised by Propeller, a local investing and accelerator company.
About the conference
The organisers wanted to accelerate building a strong tech community. They accomplished that as well! Amman seemed to have many startups and smaller tech companies. Expedia has an office of about 100 people there as well as some tech giants like Microsoft, Oracle and IBM.
About the attendees
I detected a heightened energy with the audience. Everyone was young and engaged. People interacted with each other throughout. They had a great gender diversity as well. From what I could tell it was almost a 50-50 split. Speaking to someone from Expedia, they also have a similar gender split in their office. Impressive!
I spoke early on the first day. After that, I found myself inundated with many questions. Many people said the talk resonated with their own personal experiences. Others shared how they were transitioning through this mindset shift. Moving from Maker to Multiplier. Many other non-engineers told me my talk resonated with their own leadership paths.
When I stepped outside, people approached me with questions or comments. People were very engaged and wanted to interact. People found no question too small or awkward. I found it very humbling and a testament to the local culture. I was very pleased I could offer some target questions to reflect or coach. I was happy I could offer advice or share my own experiences.
About the tech scene in Amman
Although I didn’t see too much of Amman, I was very impressed by the city, its people and growing tech scene. I was also grateful for the invite to help share my knowledge and contribute to Amman’s tech scene. I am especially grateful the organisers arranged for me to visit the ancient site of Petra.
It’s a moving and amazing experience, one I am unlikely to forget. Thanks to Tambi for the invite and Mohammad for the amazing logistics.
It’s an understatement to say that N26 is experiencing hypergrowth. In August 2017, we had 450,000 customers. We now have more than 2.3 million customers, with many more joining everyday. We’ve almost quadrupled the number of people in tech in that very same time.
It is my first experience of working in a hypergrowth company as a permanent employee. Although the US has its large share of hypergrowth companies, Europe has very few. In this post, I want to share some lessons learned and insights.
I’m sure I picked up this analogy elsewhere, but I can’t find the reference. Regardless, the imagery stuck with me.
“Working in hypergrowth feels like you’re building the spaceship as its flying”
Hypergrowth can feel chaotic. The organisation doesn’t grow at the same rate, so you feel where bottlenecks emerge. At the same time, a few weeks later, the constraint is often resolved and moved to a different area. Hypergrowth means constant but rapid change. Upon returning from a week’s holiday, many people ask, “What’s changed?” They know that somewhere a team structure, process, or decision has changed.
Hypergrowth means uncertainty. I am comfortable stating what I think may happen in three or six months time. I’m also used to being wrong. I try to put statements about the future into context, explaining possible alternatives.
Hypergrowth demands new capabilities and skills. I read how an organisation grows exponentially faster than individuals. I’ve seen this first hand. Skills take time to develop mastery. An organisation requires that skill now. Although you can wait for people to learn all the required skills, I’ve learned you need to support both. Allow people to grow, but also bring in expertise to learn from. This is why I am a big fan of pair programming (or pairing in general). It’s a great way of transferring experience across people.
Why work in an environment like this?
You may be reading this and wonder, “Why on earth would I want to work in an environment like this?” Here are five reasons why it’s worth it:
New problems to solve – Engineers love tackling new problems. Our product changes all the time. We improve the security build into our product. We look at ways to scale our systems and improve our ways of working.
New skills to develop – New problems and a changing environment forces people to build new skills. I have seen so many people grow in many different ways.
See a business “grow up” – Every six months, it’s like working with a new company. At the same time, you have personal relationships across the business. This means you’re now always starting from scratch. What started out as a single person may now be a whole team. What was once a whole team may now be an entire department.
Ability to have a big impact – Our founders have a broad mission. It’s exciting to work on something that millions of people use. It’s also great to be a B2C product where you get to use your own product too!
Everyone can be a leader – Some people may get hung up on titles. Like I wrote in a previous blog post, everyone can be a leader. There are always opportunities to show acts of leadership and have immediate impact.
How we support people
Although everyone owns their personal career paths, I’ve tried to support people as much as I can. I run an explicit Tech Lead Development Program. This gives people explicit expectations and tools about how people in or heading towards a Tech Lead can improve their impact. Leaders build other leaders. We’ve been deliberate in how we structure our Product and Tech teams. I introduced a Target Operating Model. The Target Operating Model represents a written down mental model of how we’d like to work. This often incorporates new roles, structures and explains the why and the what. Although we experience hypergrowth, it doesn’t mean we do so without trying to shape it.
We listen for feedback throughout the organisation. The leadership team takes a company wide pulse on a quarterly basis. Tech teams use retrospectives to take on improvements. Organisational smells outside of influence of a team get escalated and we try to deal with them as much as we can.
I tried to create as much transparency as possible. We have a shared product roadmap. As a company there are updates about events announced at the start of each week. We end the week with company wide celebrations.
Is this for you?
I will admit that this environment is not for everyone. Our environment may be suitable if:
You are looking for new and interesting challenges; or
You love an environment with constant change; or
You want to work in a place which tries to manage this intentionally; or
You are looking to rapidly grow and show acts of leadership.
We are always looking for new talent to add to our culture. Join me on our mission, to build the bank the world loves to use. Look at our open roles and apply now.
A book for Tech Leads, from Tech Leads. Discover how more than 35 Tech Leads find the delicate balance between the technical and non-technical worlds. Discover the challenges a Tech Lead faces and how to overcome them. You may be surprised by the lessons they have to share.
Subscribe to Level Up: A curated newsletter for leaders in tech