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.
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.
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.
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.
My excellent colleague and great friend, Georgie Smallwood reminded me of this book. I read it many years ago, when I first stepped into consulting. A great and short business novel focused on characters going through change. You meet the little people, Haw and Hem as well as the mice Scurry and Sniff. Each represent a part of our own persona and how we view change.
A powerful story that is particularly useful in an ever-changing world.
A book full of tips and tricks with how to deal with social media. You can tell the company that employees Kawasaki was definitely a sponsor in this book. Take the advice with a grain of salt. It’s a short book, full of practical advice about how to use social media. The tips are obvious but could be useful for some. Although published in 2014, the book already shows it’s age (e.g. Google+ closing down in 2019)
A fascinating biography of a visionary person who I didn’t know too much about. Several points jumped out for me during this book. During Tesla’s lifetime, it seemed like there were a lot of innovations and research. Each finding resulted in many patents – very different from today’s open source world.
Tesla had an amazing array of discoveries, many of which are still not understood today. Many of his papers disappeared with his death. He also didn’t share many details with others, having had bad experiences with others.
The author portrays Tesla with a rich and vibrant character. Not only did he have the quirkiness of the inventor. He also had the flamboyance of a socialiate and showman. For someone in his time, and the number of experiments, he lived to quite the ripe age (87!)
This book gives you an insight into many of the amazing predictions Tesla made. It also gives you an idea of how much impact he had on society with the inventions he also created and shared with the wider world.
Careers ladders are all the rage in software firms. They create structure and shared expectations around different levels. Like any model, career ladders have pros and cons. Career ladders are a starting point for shared expectations across an organisation. However career ladders cannot be comprehensive, as people are unique, like snowflakes. People bring their different strengths and experiences to what they do. Everyone will do this differently. As a result, I like to explain that levels in a career ladder do not represent a checklist. Rather, levels reflect how people can have a different impact in an organisation in different ways.
In my most recent talk, “Talking with Tech Leads,” I explain how, some companies have a two-track career model. Two tracks are great, as they allow for more development and growth in different areas. Most of the research I did seemed to focus on two main tracks. In Silicon Valley they refer to these as Individual Contributor (IC) and Management tracks. I actually don’t think a two-track ladder is enough. This is why I present you the Trident Career Model below.
The Trident Career Model has three tracks. Each track represents where people spend most of their time or energy.
The Management Track
In this track, people spend a majority of their time (70-80%) on management activities. This still includes leading people, supporting people, managing structures & processes and organising. People in this track must still have some background in the topic they are managing.
Most importantly, their main value add is not necessarily through making decisions related to the specialist field (e.g. system architecture). Instead, they manage the surrounding system & structure to ensure people closest to the work have the best context and information to make better decisions. They provide enough support, time and/or budget to enable others to do what they do best.
Example roles in this track: Engineering Manager, VP Engineering, IT Manager
The Technical Leadership Track
In this track, people spend a majority of their time (70-80%) leading people on a technical topic. People in this track must have relevant hands-on technical skills and experience. They should have good but not necessarily the best skills in the team they are leading. People in this track draw heavily on refined leadership skills to be successful. Classic activities for this role (in the field of software) include:
Establishing a Technical Vision
Managing technical risks
Clarifying/uncovering technical requirements
Ensuring non-technical stakeholders understand technical constraints, trade-offs or important decisions
Growing technical knowledge and cultivating knowledge sharing in and across teams
Example roles in this track: Lead Developer, Tech Lead, Principal Engineer, Software Architect
The True Individual Contributor (IC) Track
In this track, people spend a majority of they time (70-80%) focused on “Executing/Doing”. Software engineers early in their career reflect this very well. This track still requires people to have excellent communication and collaboration skills. People in this track have impact through the deep/detailed knowledge or skills they offer. Most small companies do not need a deep IC track, as there is no need for specialisation. As an organisation grows, they may need more of these roles. The number of these roles will always be smaller than the other two tracks in a well-functioning organisation.
Example roles in this track: DB Specialist, Performing Tuning Specialist, Domain Specialist.
This model is indeed a simplification. In real life, the Management and the Technical Leadership tracks are not always so clearly separate. I know some companies where Engineering Managers also take Technical Leadership responsibilities, or where Tech Leads or Lead Developers are also expected to take on Management responsibilities. This is not necessarily wrong.
I have personally found that, at scale, it is often hard to find people who have deep skills and experiences at both of these areas, and that it can be useful to have a discussion around where someone’s focus, passion or development progression lies.
As the famous quote goes:
All models are wrong, some are useful.
George EP Box
I have found this Trident Model a useful starting point to contrast differences in roles or expectations. Considering using this model:
To develop skills in an area you may want to work
When building out your own company’s Career Ladder
To explain differences/focuses on existing roles and responsibilities
I hope you found this post interesting. Please leave a comment about your thoughts of the Trident Model of Career Development.
I took part in a three day course before Christmas to better understand Large Scale Scrum (LeSS). LeSS’ tagline is “More with LeSS”. I’m pessimistic about most “Scaling Agile Frameworks.” Many give organisations an excuse to relabel their existing practices as “agile.” Not to fundamentally change them. Bas Vodde (one of the founders of LeSS’) invited me to take part in a course just before Christmas. I took him up on the offer to hear it “From the horse’s mouth.”
This article summarises my notes, learnings and reflections from the three day course. There may be errors and would encourage you to read about it yourself on their LeSS website, or post a comment at the end of this article.
About the Trainer
I met Bas Vodde about a decade ago. We met at one of the Retrospective Facilitator’s gathering. He is someone who, I believe, lives the agile values and principles and has been in the community for a long time. He still writes code, pair programming with teams he works with. He has had a long and successful coaching history with many companies. He worked with huge organisations where many people build a single product together. Think of a telecommunications product, for example. Through his shared experiences with his co-founder, Craig Larman, they distilled these ideas into what is now called LeSS.
What I understood about LeSS?
LeSS evolved from using basic Scrum in a context with many many teams. I took away there are three common uses of the term LeSS.
LeSS (The Complete Picture) – The overview of LeSS including the experimental mindset, guides, rules/framework, and principles. See the the main website, Less.
LeSS (for 2-8 teams) – Basic LeSS is abbreviated to LeSS and is optimised for 2-8 teams. They have LeSS Huge for 8+ teams, and modifications to the rules. See LeSS Huge.
Practices & Rituals in LeSS
LeSS has a number of practices and rituals as part of its starting set of rules. Some of these include:
A single prioritised Backlog – All teams share a single backlog with a priority managed by the Product Owner.
Sprint Planning 1 – At the end of this, teams have picked which Backlog Items they work on during a sprint.
Sprint Planning 2 – All teams do this separately. Like in Scrum, Sprint Planning 2 focuses on the design and creation of tasks for their Sprint.
Daily Scrum – Each team runs their own Daily scrum as per standard Scrum.
Backlog Refinement – Teams clarify what customers/stakeholders need. Good outcomes include Backlog Items refined into sizes where teams can take 4/5 into a Sprint. LeSS encourages groups, made up of different team members, to refine Backlog Items. This maximises knowledge sharing, learning and opportunities to collaborate.
Sprint Review – Teams showcase their work to customers/stakeholders for feedback. The Product Owner works to gather feedback and reflect this in the overall Backlog. Sprint Reviews should not be treated as an approval gate. It’s about getting more input or ideas.
Sprint Retrospective – Each team runs their own retrospective. As per standard Scrum.
Overall Retrospective – Members from every team plus management hold a retrospective. This retrospective focuses on the system and improving the overall system.
Shared Definition of Done – All teams share an overall Definition of Done, which they can also update. Teams can build on the basis of the shared Definition of Done.
Sprint – There is only one sprint in LeSS, so by definition all teams synchronise on the same sprint cadence.
Roles in LeSS
Scrum Master – Like in Scrum, LeSS has the Scrum Master whose goal is to coach, enable and help LeSS run effectively. The Scrum Master is a full time role up of up to 3 teams.
Product Owner – The Product Owner is the role responsibility for the overall Backlog prioritisation
Area Product Owner – In LeSS (Huge), Area Product Owners manage the priority of a subsection of the Backlog. They also align with the Product Owner on overall priorities.
Team – There are no explicit specialist roles in LeSS, other than the team (and its members).
Principles of LeSS
A key part of LeSS is the principles that guide decisions and behaviours in the organisation. People can make better decisions when taking these principles into account. You can read more about LeSS’ principles here. Like many other agile ways of working, Transparency is a key principle. Unlike other agile methods, LeSS calls upon both System Thinking and Queuing Theory as principles. Both are useful bodies of knowledge that create more effective organisations.
Another explicit difference is the principle of the Whole Product Focus. This reminds me very much of Lean Software Development’s Optimise the Whole principle. I also like very much the description of More with LeSS principle. This principle challenges adding more roles, rules and artefacts. So think carefully about these!
In LeSS, having LeSS specialisations is a good thing. This encourages more distributed knowledge sharing.
LeSS explicitly priorities feature teams over component teams to maximise the delivery of end to end value. Both have trade-offs.
A lot of LeSS has big implications about organisational design. Agile teams showed how cross-functional teams reduce waste by removing hand-off. LeSS will be even more demanding on organisations and their structure.
The creators of LeSS made LeSS Huge because they found a Product Owner was often a constraint. Since Product Owner’s focus on prioritisation, it’s hard to keep an overview and manage the priority of 100+ Backlog Items. (Note that teams still do the clarification, not the Product Owner). With 8+ teams, they found even good Product Owners could not keep on top of the ~100+ refined Backlog Items (which normally covers the next 3+ sprints).
LeSS Huge addresses this by introducing Categories (aka an Area). Each Backlog Item has its own category, and each category then has an Area Product Owner to manage the overview and prioritisation of Backlog Items in that category.
Guidelines for creating an area:
This should be purely customer centric
Often grouped by stakeholder, or certain processes
Could be organised by a certain market or product variant
No area in LeSS Huge should have less than 4 teams
After taking the course, I have a much stronger understanding of LeSS’ origins and how it works. After the course, it feels much LeSS complex than when I first read about it on their website. It includes many principles which I run software teams by. I can also see many parallels to what I have done with larger organisations and LeSS. I can also see how LeSS is a challenging framework for many organisations. I would definitely recommend larger product organisations draw inspiration from LeSS. I know I will after this course.
In 2017, I stopped working as a consultant and started playing the role of CTO in Berlin. I learned a lot moving away from consulting into a full-time management role. I am happy with the direction the technology team and platform is moving, given where it was when I started. You can read more about what we achieved in 2018, and I’m proud to have been a significant part of that.
I expected to travel less as a consultant. Yet that didn’t seem to really work out. Places I visited for both work and leisure included: Barcelona, Munich London, Brussels, Austin, Capetown, Budapest, Vienna, Heiligendamm, Sitges, Zurich, Siegen, New York, Krakow, Oslo, Cadzand, Malmo and Amsterdam.
Earlier this year, I read the book Multipliers: How the Best Leaders Make Everyone Smarter (by Liz Wiseman). The book title peaked my interest as I’m often helping people on their leadership journey go from Maker to Multiplier mode. The book not only highlights the habits of a multiplier, but also discusses the opposite, The Diminisher. The book defines Tthe Multiplier as, “A person who lead an organisation or management team that was able to understand and solve hard problems rapidly, achieve its goals, and adapt and increase its capacity over time.”
The book defines The Diminisher as, “A person who lead an organisation or management team that operated in silos, finds it hard to get things done, and despite having smart people, seems to not be able to do what is needed to do to reach their goals.” The book often highlights that many people act as accidental diminishers or do so unintentionally.
There are several ways a leader can focus on being a Multiplier including being the Talent Magnet, The Liberator, The Challenger, The Debate Maker or the Investor, each which has its own separate section of the book with tips and practices.
“Multipliers never do anything for their people that their people can do for themselves”
As you watch someone, ask these questions:
Multipliers (Liz Wiseman)
I liked the section on becoming a Talent Magnet (which they contrast with the Empire Builder). Both attract talent, but the question is what do they with that talent afterwards. Talent Magnets don’t run out of talent because they draw upon four practices:
Look for Talent Everywhere – Appreciate all types of genious (Ignore Boundaries)
Find People’s Native Genius – Look for what is native (Label It)
Utilise People to their Fullest – Connect people with opportunities (Shine a spotlight)
Remove the Blocker – Get rid of primadonnas (Get out of the way)
I also liked the three simple practices of becoming The Challenger:
Seed the Opportunity – Show the need. Challenge assumptions. Reframe problems. Create a starting point.
Lay down a Challenge – Extend a concrete challenge. Ask the hard questions. Let others fill in the blanks.
Generate Belief in what is Possible – Helicopter down. Lay out a path. Co-create a plan. Orchestrate an early win.
This book resonated with me as a leader and would recommend this to others looking to expand their own leadership journey.
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.