When I’m setting up a new computer, one of the tasks I need to do is set up new SSH keys to access different servers. It’s good practice not to use the same key for different services. Keys are useful so you don’t need to type your credentials in all the time when working on a trusted PC.
Instead of typing something like: ssh thekua@github.com I can just simply type ssh github without being prompted for credentials. Less typing. Win!
After you generate several different keys, you can either add them to the command line when using ssh, but it’s easier just to use the config file (typically found at ~/.ssh/config).
Here’s an example config file you might have assuming you have three different projects:
My last post shared some of my reflections about some of the highlights and lessons learned from my last role. In this post, I want to share with you what’s next for me.
What’s most important for you?
During many of my coaching/mentoring sessions, I often start by asking this hard question. It’s hard for a lot of people to answer because it requires looking deep into yourself. It’s a question that no one else but you can answer.
For some people, it’s about having new experiences or growing new skills. For others, it’s about being able to apply their strengths in a way that has a positive outcome. For others, it’s being able to bring their whole self to work collaborating in an environment with people they trust.
To dogfood my own question, I spent a lot of time last year thinking deeply about what this meant for me. Although I know the answers to this question change over time, I believe what is most important to me right now is:
Having more time flexibility – I have a goal of spending my time with writing and working on a couple of different projects. Having a full-time role would constrain that more than what I would like right now.
Helping others grow – Feedback from participants from my Tech Lead Skills for Developers workshop has been personally very fulfilling. Many come away with the realisation that the Tech Lead role is a role change, not a promotion. Others told me how their personal lives have benefited from the training. Hearing how others have grown, and knowing I’ve had a part in that has been very fulfilling.
Having a broader impact – All good leaders continue to review the impact they have had. I’ve had a lot of success growing others leaders within a single company and want to do more.
Got some Ikigai?
The Japanese have a word, Ikigai, that is roughly translated to “the thing you live for” or “reason for being.” It was propelled into the Twittersphere when Marc Winn published this article, “What is your Ikigai?”
A visualisation of the meaning of Ikigai
Today’s world talks a lot more about mission-driven or purpose-driven companies. Paloma Medina talks about people’s core needs using the BICEPS acronym where two key elements are both seeing Improvement/Progress (e.g. “Progress towards purpose”) and Significance (e.g. “Your work is recognised and appreciated in ways that feel good”).
All of these models resonate with my own personal values of having an impact with the skills and experiences I’ve built over time. I’m grateful I work in an industry (tech) where we have more options to find our Ikigai.
The next experiment?
Now that I understand what is most important for me right now, my next experiment is starting my own venture. I don’t want to label myself as a “founder” and I’m not necessarily interested in starting a product company. Although I’ve learned to “never say never!
Instead my venture is best summarised by the following mission statement: “Accelerating the growth of technical leaders, software delivery and organisations”.
Personal mission statement: Accelerating the growth of technical leaders, software delivery and organisations
Rather than defining everything upfront, I have a couple of ideas and initiatives to fulfill this mission right now.
My previous role significantly limited how and when I could offer my “Tech Lead Skills for Developers” workshop. I’ve had many requests for running this workshop – both internally for other companies and externally as public workshops as well.
I will be initially offering this to companies who would like to host this internally for their staff. If you’re interested in organising a workshop for your company, then read more here.
If you’re interested in joining a public workshop, I’m in discussions with a couple of training companies and conferences to offer this. Follow me on twitter (@patkua) or connect to me on LinkedIn to watch for updates.
Offering Keynotes and Talks
I’ve had great feedback about the presentations I hold. It’s also an important part of sharing and distributing knowledge more widely and something I enjoy. You’ll still, therefore, see me at various tech conferences (mostly around Europe).
If you’re interested in having me speak at your own internal conference or event, then take a look at some of the talks I offer and you can also get in touch if you’re interested in hiring me for that.
Advising and mentoring
During my own leadership journey, I’ve had a number of people I’ve mentored and advised. I’ve found that many senior leaders (e.g. CTOs, VP Engineering, Directors of Engineering) benefit from having an external perspective who has “been there before.”
I’ll be offering this through a traditional consulting/advisory model so get in touch if you’re interested in that.
Projects in the Pipeline
Offering the services above also gives me significant flexibility to work on a number of projects I haven’t had time for. My newsletter, Level Up is one such project that has had a good reception and I have a number of others I’d like to focus on as well.
As part of this new venture, you’ll see fewer (maybe zero?) updates on this site going forward. Thank you to all those long term RSS subscribers who’ve shared my journey over this website. I plan on keeping http://thekua.com/atwork around as there are many useful resources on it.
The start of 2020 and another year has gone by. While I experienced so many different new things in 2019, it’s really hard to capture so many of the memories in a single post.
Memorable experiences
Here are some of my professional highlights of the year:
As part of the AWS Summit in Berlin, I was invited to do a customer keynote with Werner on stage. His bodyguard, who is somehow even taller than Werner (and much more built) took this photo:
Werner Vogels and me at AWS Summit Berlin
Another highlight was the presentation coach, who helps Werner and Andy Jassy with their talks gave me such positive feedback after the keynote, saying that she hoped I continued doing more of these.
Presenting about personal leadership lessons learned at a conference on the ski slopes in Austria
Skinnovation, Innsbruck (Austria)
Taking part in Skinnovation was a really fun experience. It somehow blended investors, start up founders, other tech leaders and made it a fun and casual environment. There was nothing quite like the experience giving a talk in a ski hut while it was snowing outside!
Taking part in the first ever tech conference in Jordan
Jordan is a rich hub in the middle east and it was an honour to be invited to take part in the inaugural edition. I was super surprised at how vibrant the community was (the questions and conversations never stopped in the breaks!) and impressed by the gender balance (at least 50-50) that I don’t see here often in Germany or the UK.
Xpand Conference, Amaan
A bonus highlight was fitting in a trip to Petra with a very early morning visit meaning a lot of peace and quiet before all the other tourists arrived.
Petra, before all the big tourist crowds arrived
Transitioning to Chief Scientist
Those who have played the CTO role know how variable this title can be. In the first half of the year, I transitioned officially to being a “Chief Scientist.” This new title allowed me to refocus where I could use my strengths and my interests of supporting people in tech (versus spending more time with other departments/teams). As part of this, I really enjoyed spending significant time doing more 1-1 coaching and mentoring of people in tech, helping them navigate the rapid changes in hypergrowth, find a way to navigate their worries during constant change and to help people accelerate their growth. It was such a pleasure to have personally helped so many people during this time.
Supporting a tech community in need
I was approached by a tech training community trying to upskill people in a war-torn area. Like a coding academy, their mission was to help cross-train people so they had new opportunities in life. Although I wasn’t able to physically attend (it would have been both difficult and likely dangerous) I was able to do a presentation remotely and support the community from afar. I received a lot of feedback afterwards about how helpful it was.
Starting a newsletter for leaders in tech
On the back of the semi-weekly email I used to send out as CTO, I had a lot of requests for sharing what I read, and what I was researching. LevelUp, a curated newsletter for leaders in tech was the result. It just reached Issue #20 and looking forward to even more this year.
Level Up, a curated newsletter for leaders in tech http://levelup.thekua.com
Levelling up new Tech Leads
I ran a Tech Leadership development course in N26 three times this year and was able to offer this workshop as part of the Lead Dev conference in London and Berlin. Seasoned Tech Leads provided feedback like, “I wish I had this training when I first started out!” while others provided feedback like, “I never knew this is what was expected of a Tech Lead.“
One particular personal feedback stood out from one participant who came away realising they were more than ready for the role, but their manager hadn’t ever given them an opportunity to step up and they (a minority in tech) gained a lot of confidence to go back to their workplace and have a conversation around their role and future growth opportunities.
Lessons learned
I am entirely grateful for all the good (and bad) experiences I had this year. As the old saying goes:
I wouldn’t be where I was today, if I never experienced the things that I experienced.
Unknown
Here are some of my key learnings from this year:
Only you hold yourself accountable for how you behave. You can’t control how other behave, but you can always control how you react.
Stress (and especially extreme stress) sometimes triggers extraordinary behaviour. (See the above lesson).
(Relearned) Trust is built slowly over time. Losing trust happens in an instant.
Good leaders will always aim for the best outcome for everyone. Bad leaders will do simply what they’re told.
(Reaffirmed) Having a title doesn’t automatically make someone a great leader.
Psychological Safety is a huge prerequisite for learning and high performing teams. Leaders are responsible for nurturing this.
How was your 2019?
It was extremely useful to reflect on the year gone by and to share some of my lessons learned. Feel free to share with me how your 2019 was and any lessons you learned below in a comment.
More than a couple of years ago, I started on the journey as a “shake-up” CTO at N26. I often describe the role at the time as, “Shaking the snow globe.” The patterns of an early stage start up would no longer scale, and the company needed someone to help guide the transition. I was very honoured to guide the tech team through hypergrowth, and helping us transition from “start up” to the “scale up” stage of a company. Flash forward to today, and I’m happy to say we achieved that (and more).
I’m happy to say that the tech team is significantly more robust, and I leave knowing it’s in a much healthier state than what it was.
“Every new beginning comes from some other beginning’s end”
Semisonic
There are, of course, always many areas to continue to improve on. I’m happy that we have grown and hired many strong technical leaders who will continue to improve and iterate on this.
What I’m proud we accomplished
Although there are many elements I’m proud we accomplished, here are some of the ones that were definitely highlights.
An organisation with too many ideas will remain just that.
A better balance of tech to non-tech
When I first started, each C-level introduced new team members to the rest of the company. In the first few months, I was introducing one, maybe two, new people per month when the business team was introducing maybe 10-15. If, like me, you have worked in a place where you have more people with projects than capacity to work on them, you know what that would result in.
I worked closely with the people and especially recruiting team. We reworked everything from compensation and benefits, employer brand, recruitment processes and onboarding. Although we ultimately improved how we recruited and retained people in tech, I believe many improvements also benefited other departments as well.
Diversity doesn’t matter if you don’t have inclusion
We’re not just diverse, but also more inclusive than before
Like London, Berlin attracts all types of international people. In the last report I read, we had more than 60 nationalities in the tech department. I also wanted us to have diverse educational backgrounds and gender diversity, but I know focusing on diversity alone is not enough. We also needed to make sure we focused on inclusion.
Early on in my time, I sponsored the very first company wide International Women’s Day event. You can read more about it t. We set up a diversity channel on slack, added a bot that provided alternatives to gendered language like “guys”. (Sidenote: It’s amazing how many times we had to reinstall that bot!) I believe these actions let more people bring their full selves to work and resulted in support for CSD, many other Employee Resource Groups to support better work-life balance.
We avoided growing chaotically, instead doing so deliberately with a Target Operating Model
As the tech team grew, I knew that we would need to change our organisational structure to maximise both autonomy and alignment. As the team grew, we restructured deliberately to address issues team members faced as bottlenecks moved to different parts of the organisation. We introduced new roles and capabilities to focus on issues, giving people new growth paths and new areas to work in.
Growing people is like growing plants. A healthy environment combined with enough time and care.
I was able to personally support many people in their own growth
Growing companies offer people new opportunities for growth. However knowing that many roles like management or technical leadership are not a promotion but a role change, I’m happy to have supported many technical leaders in their own growth. I personally ran the Tech Lead Development Program approximately 5 times throughout my time. I mentored and coached people through many tough situations and I’m happy to have seen so many people grow and evolve. I even received some feedback that my support not only helped them professionally, but also in their personal life and relationships!
What’s next?
I very much appreciated my time shepherding the tech organisation, influencing the leadership team and direction of N26 and valued the experiences and tough situations I faced. I’m grateful for the experiences of working so closely with founders and other wonderful executive team members.
Many leaders ask themselves if they are having the best impact they can have. Are they able to bring their strengths to play in their role? I know where my strengths lie, and given my personal goals, it’s time for me to apply these strengths in a new context.
I will announce what exactly I’ll be working on in the new year, so watch out for a future post.
This is more of a reminder for myself so I don’t need to keep googling or looking at man when I need to look up the syntax.
Let’s assume you have two hard drives, ones called PHOTOS the other other BACKUP. You can use the following command to synchronise photos (including removing all files that were deleted on PHOTOS to BACKUP.) also ignoring backup files (.* files).
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”
Vernā Myers
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.patkua.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.
When you say the word, “management,” it’s easy to drum up terrible images. Dilbert, Ferris Bueller’s Day Off, The Office and Silicon Valley reinforce these bad stereotypes. Poor leadership and management is common as people transition into a different role for the very first time. As the old saying goes, “It’s not a promotion, it’s a role change.” Great management may be emotionally exhausting but is also extremely rewarding. Unfortunately I can’t point to enough material about what great management looks like. That’s why I’m excited by “An Elegant Puzzle: Systems of Engineering Management.”
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.
Organizations
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.
Tools
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.
Approaches
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.
Culture
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.
Careers
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
Communicate Effectively
Build Resiliency
The book provides clear, direct and actionable ideas for managers. Lara covers topics like:
Understanding individual’s core needs
Growing individuals
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.
A code smell is a potential indicator of a larger problem. A code smell does not always lead to a problem. Rather you have to investigate and decide for yourself. An organisational smell is similar but to do with the organisation itself.
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
The “Team” model
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.
The “Product Group” Model — more autonomy and flexibility appropriate for the area
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.
The relationship between a Product Segment, Product Group and Product Team
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?”
“What are you optimising for right now?”
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.
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.
Recent Comments