patkua@work

The intersection of technology and leadership

Category: Tech Leadership (Page 1 of 5)

The Next Experiment? Starting My Own Venture

January 5, 2020 / / 0 Comments

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?”

Ikigai Venn Diagram
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.

Offering Tech Lead Development Workshops more widely

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.

Moving to http://patkua.com

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.

You can now follow me on http://patkua.com (same as my twitter handle) and the writing will continue at http://patkua.com/blog.

A Brief Review of 2019

January 1, 2020 / / 0 Comments

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:

Keynote with Werner Vogels (CTO of Amazon)

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 Patrick Kua
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 talk photo
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.

Patrick Kua speaking at Xpand Conference in Amaan
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 panorama photo
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.

Announcing “Level Up”, a newsletter for leaders in tech

August 18, 2019 / / 0 Comments

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.

Try subscribing to Level Up today at http://levelup.patkua.com

XPand Conference in Amman, Jordan

April 19, 2019 / / 1 Comment

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.

Xpand Conference Logo

About the conference

The conference organisers assembled a fantastic program. Some speakers came from around the Middle East area. Others, like myself, traveled much further. The conference had a very well rounded agenda. It covered everything from the state of JavaScript, observability, chaos engineering, serverless and more. I spoke on one of my favourite topics presenting my most recent talk, “Talking with Tech Leads.”

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

It seemed like Amman’s tech scene is blossoming. People I spoke to used languages like PHP, Python, JavaScript and Java. Many people worked for startups. The startups focused on industries like mobility, last mile delivery, and fintech. Others worked for local consulting companies and a global company like Expedia.

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.

  • The Monastery at Petra
    The Monastery
  • The Treasury at Petra
    The Treasury
  • Cobbled path at Petra
    Cobblestone Path

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.

Goodbye CTO, Hello Chief Scientist

March 10, 2019 / / 10 Comments

What was the Challenge?

Hypergrowth land is fun. Things change all the time. My challenge as a CTO was to shake-up the early-stage startup “snowglobe.” It was to transform “start-up” habits into a “scale-up” culture. It was to prepare and launch into hypergrowth. I took on this challenge because I saw the kernel of engineering talent that I could nurture and support.

What Changed?

Looking back at the time I’ve been there (it feels like ages in startup time!), so many things have improved. It’s hard to count all changes as the company constantly evolves. Here are some of the changes I’m proud to have influenced:

  • Clear priorities – It’s easy to fall into reactionary mode and want to switch gears all the time. As the old saying goes, “If everyone is a priority, then nothing is a priority.” Engineering is always the bottleneck. Ideas are cheap. Ideas are easy. You have 5 ideas. I have 5 ideas. Engineers have 5 ideas. To maximise our opportunity, we needed to be clearer about where to focus attention. We now have a better planning process that enables clearer trade-offs and decisions.
  • Almost 4x tech growth – When I first started, I looked around asking, “Where are all the engineers?” Our ratio of tech to non-tech was way off! We worked hard with the People team to change our recruiting strategy. We improved our onboarding process. I spent a lot of personal time writing articles and speaking on our engineering culture. The result? Tech is almost 4x the people compared to when I started. We also managed this while continually delivering value to customers too.
  • A clear Target Operating Model – Change is hard. What helps is a shared picture of how we wanted to scale Product & Tech. You can’t have more people working on the same problem. You need to create a clear focus. You need to encourage high cohesion and low coupling across people and teams. We established a shared Product & Tech Target Operating Model. This model visualises and explains new structures, processes and how they fit together. Each iteration aims to addresses organisational smells and maximise Autonomy and Alignment. We’re working on our 3rd iteration of this now.
  • Product versus Portfolio Management – We have individual product area priorities. We also have cross-cutting projects. We now can focus on ensuring the bottleneck or critical path has full support and attention. We can manage both product and portfolio priorities well.
  • Fuller life cycle ownership in teams – When I arrived, we already had cross-functional teams. Not all teams were responsible for the full “life cycle” of a product. Sometimes back-office or operational processes belonged to a different team. The separation lead to queues and bottlenecks. Our teams are on a journey of integrating more responsibilities. They continue to extend the definition of done to remove hand-overs. We build security and quality in from the start. Teams can better respond to customer issues, incidents and build new or on existing products.
  • Technical governance practices that scale – As we grow, we also focus on alignment where it makes sense. Organisations can only support a certain amount of variation or entropy. Alignment helps. We adopted a lightweight RFC process and iterated on our internal Tech Radar. We built decentralised support structures like Technical Working Groups and an Architecture guild. These work without relying on the same individuals to make decisions.
  • Three Product and Technology Hubs around the world – We’ve moved from being completely centralised in Berlin to operating three successful P&T hubs in Barcelona, New York City and Berlin. We transitioned major product ownership to one office as it grew. The team evolved and released completely new features and services in record time. We’ve maintained speed and throughput, and quality remains high.
  • Rapid growth of individuals – As a I leader I invest in people I work with. I’ve mentored, coached and trained many individually personally. It’s wonderful to see how it’s accelerated people’s growth. People have better ways to deal with imposter syndrome. Engineers have more impact and influence through stronger leadership skills. Better yet, I know they have done this with an explicit support.
  • Diversity, inclusion and culture – I remember one big change I first made was removing a degree requirement for engineers. I created the #diversity slack channel. I sponsored the celebrations for International Women’s Day. This lead to a wonderful support of CSD in Berlin. Watch this amazing video! I know we’re not perfect but we are improving. Our gender ratio in tech can still improve. We have, however, built an inclusive culture where everyone in Product & Tech can express ideas in safety.

What’s next?

The CTO is one of the most confusing roles. Some call it a chameleon role. Companies have different requirements of the role. It changes rapidly in the same company (particularly one going through hypergrowth). There are just many different explanations. As our company grows, the needs of the CTO role grow and change.

As a leader, I found myself asking others (and myself), “How does this scale?” I’m constantly looking at ways to scale myself too. To scale with the growing set of responsibilities, we are splitting this role.

The CTO for our company, in our stage, demands a more operational, management and inward focus. I will step into a new role called, “Chief Scientist.” This new role takes a more outward focus and still guides the technical direction and growth of the tech team.

Our “Chief Scientist” role focuses on three areas:

  1. Representing the external face of technology
  2. Supporting and enriching technical decisions
  3. 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!

Sekt on a mountain

PS. If you’re interested in joining me on building the bank the world loves to use, check out our open opportunities.

The Trident Model of Career Development

February 3, 2019 / / 9 Comments

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 Model of Career Development

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.

Conclusion

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

Looking for an example of this in the wild? This post, Engineering Levels at Carta, isn’t as visually deliberate, but points out “Senior software engineer II (L5) is the second of Carta’s two senior levels, our first terminal level.” This is made more explicit in this post about Staff Engineering at Carta, which says, “For those who wish to pursue it, our first level beyond “senior” and into focused technical leadership is staff engineer.”

I hope you found this post interesting. Please leave a comment about your thoughts of the Trident Model of Career Development.

6 Lessons Learned in my year as CTO at N26

September 20, 2018 /

Life has been a bit of a whirlwind trip in the last year. I moved cities (London to Berlin). I started a new role as a CTO. I transitioned from 14 years of consulting into a management role. I joined the hyper-growth startup, N26 – the mobile bank the world loves to use.   It’s been exciting to particularly see the company growth. Our customer base has grown from 500K+ users to more than 1 million. Our users transact more than €1B in currency. We’ve expanded our offices from Berlin to New York. We also announced moving to Barcelona and this is only the beginning. 

In this blog entry, I will share my personal lessons learned on the rollercoaster ride from this year. 

1. Management overlaps with leadership, but is different

Over the almost 14 years of consulting, I spoke all the time about leadership. I still believe that anyone can be a leader. Leading is less about a title, and more about how you act. In my role, I also better appreciate the important role of effective manager. Google even proved that effective management matters.

I still think great managers are also great leaders. We try to test for this at N26 during our interviewing process. We hold our managers accountable for having difficult conversations. We want them to be kind, not only nice.  We want managers to nurture an environment of candid feedback. Great managers manage things and lead people. Managers, unlike coaches or consultants are also held accountable for this. 

2. Hypergrowth stretches everyone

I’ve definitely grown over this year. Our company has also grown rapidly (both with users and people). Hypergrowth means people have opportunities for new tasks. We are also not the first company to experience this. The community has been very generous with sharing their knowledge. I will contribute more to this in the future too, as I build on lessons learned.

I have found myself repeating, “The company will grow much faster than people.” 

With this in mind, I have tried to support, develop and grow as many people as possible. At the same time, I’ve focused on bringing in new skills and experiences that we need. Combining a learning workforce with experienced people is tremendously powerful.

3. Really underscore the Why, not just the What

I believe very much in Simon Sinek’s “Start with Why.” A group of brilliant, collaborative problem solvers will end up with a better idea if they understand why.  You can, of course, still give your input. Your role as a leader it to explain the context. Or to clarify the goal or problem. Not just the solution.

I’ve seen too many technical debates fail because they first didn’t agree on the problem. Agree on why, then move on to what. 

In a fast moving startup, I found people underrate listening. Listening and asking questions are my most powerful tools as a leader.

4. Investing in people has exponential returns

I always try to be generous with my knowledge and experience. I’ve particularly enjoyed helping people grow. Sometimes it’s required tough, candid conversations. Effective feedback helps people grow. Coaching and training helps people see potential they don’t see. It’s been wonderful to help people discover, test and practice tools that make them more successful. 

I’m proud of N26’s technical leaders (both formal and informal). I’m impressed with how people have rapidly grown. I’m also impressed with what they do to pass it on.

5. What got you here, won’t get you there

I read the book, “What got you here, won’t get you there” many years ago. It’s message resonated with me during this year. Startups often go through several phases, “Start Up, Scale up, and Optimise” is how I like to think of it. We are definitely in the Scale Up phase. This phase demands different thinking. 

Acting as if we were in the Start Up phase no longer scales. It’s an educational journey for many people. At scale, you can no longer manage every single situation. At scale, you can no longer make all the decisions. At scale, you have to decide on where you will have the greatest impact. At scale (as a manager), you make less, and need to focus on multiplying more. 

6. Focus on Capabilities, not just People

In Hypergrowth, it’s too easy to hire lots of people. I am wary of this after reading the Mythical Man Month many many years ago. As a manager, I first focus on understanding what capabilities we need. I also think about how those capabilities are best met. Be clear on what you need before hiring people. 

Focusing on what you need helps you find the right people. It also helps those people be clear about how they will be successful. 

Conclusion

I have learned many other lessons in this year as a CTO. The six lessons above reflect some of the major themes for this past year that I hope you many learn from.

I’m super proud of the people I work with. I’m super proud of the product we produce. It’s been a great ride so far, and it’s only the beginning of the journey.


Thanks Jerry Weinberg

August 11, 2018 /

If you have worked in IT for some time, you will have come across the name Jerry Weinberg (Gerald M Weinberg). I first came across Jerry when I first read his book, “The Secrets of Consulting.” Jerry impacts great wisdom through his use of stories. He shared his knowledge generously with our industry and set a great example.

He was a prolific writer and I was lucky to inherit many of his books when a contact moved house. I devoured them rapidly, learning much in the process. As a proud Systems Thinker, I enjoyed “An Introduction to General Systems Thinking.” As someone passionate Technical Leadership, I inhaled, “Becoming a Technical Leader.” I refer and recommend many of his books time and time again.

I never had the opportunity to meet Jerry but I met many people who he had personally influenced. I heard amazing things about the “Amplify Your Effective (AYE)” conference. I felt people who frequented the AYE conference came away with more drive to have a greater impact. I regret not taking the one opportunity I had to take part, given the wrong timing and place in my life.

As someone who believes in agile values, I was lucky to meet Norm Kerth. I forgot he co-authored the “Project Retrospectives” book with Jerry Weinberg. Continuous improvement is the basis for better organisations, teams and processes. Call it retrospectives, kaizen or some other name. I count myself lucky for reading this early on in my career.

We stand on the shoulders of giants. Jerry was definitely a giant among giants. In the world of software we often have a negative association with the word, “legacy.” We forget that sometimes that legacy can be a good thing. I am particularly grateful for the legacy Jerry left behind. 

Three Common Mistakes of the First Time Tech Lead

April 22, 2018 / / 2 Comments

The first time a developer steps into the role of a Tech Lead can be difficult. The skills and experience of a seasoned developer do not automatically translate into the skills necessary for the Tech Lead role. In fact, some of the habits of a developer can do more harm than good, when not applied well and with more authority in this new role.

3 mistakes

In this article, we explore three common traps a first time Tech Lead experiences, and what they can do to avoid them.

1. Coding Full-Time

A first time Tech Lead will miss writing code. In fact, it is easy for them to assume that they need to demonstrate their leadership by writing code all the time. Although effective Tech Leads need to spend some time writing, reading and reviewing code, other responsibilities are left unfulfilled when they spend too much time writing code, – such as creating a technical vision and ensuring that the team understands key system quality attributes.

A lack of technical vision might lead to three different implementations, as developers make decisions individually about what they feel is best, or a deployment might fail because developers are not aware of operational constraints or environmental differences in production. Worse yet is when the code must constantly be reworked because a developer chooses to do something differently without considering maintenance, or how the system may evolve over time.

The more experienced Tech Lead understands that they must balance their time to code with other responsibilities. They split their time daily, or at the very least weekly, to ensure that they spend time addressing other responsibilities including building a shared architectural vision, identifying and addressing technical risks, being involved in planning sessions and focusing on team and code cohesiveness and consistency.

2. Making all the Technical Decisions

A first time Tech Lead may sometimes be the most experienced developer on the team, or feel the pressure to make all the technical decisions to demonstrate their authority or influence. When a Tech Lead is making all the technical decisions, they become a bottleneck in the team and the team cannot progress when the Tech Lead is not around. Other team members might feel demotivated when the Tech Lead makes all the important decisions, because their contributions are overruled and this could lead to resentment.

The more experienced Tech Lead realizes there are different ways of making decisions, and often, the best decision comes from using the breadth of experience and knowledge from the entire team. They might draw upon the following techniques, depending on how critical a decision is, how quick a decision must be made and how much commitment they want from team members:

  • Only delegating – A Tech Lead gives the decision to someone else without any other interaction
  • Offering advice – A Tech Lead delegates the decision to someone else, but offers their input and opinions for consideration
  • Inquiring – A Tech Lead delegates the decision to someone else, but inquires about the outcome and factors that led to the decision afterwards
  • Building consensus – They bring all team members together to find a solution that everyone is happy with
  • Consulting with the team – They invite opinions from team members, synthesise the information, but ultimately make the final decision
  • Being autocratic – They use the information they have to make a decision, choosing to involve or not involve team members, but inform everyone about the outcome.

3. Forgetting about Cultivating Team Culture

A team is a group of people working together towards the same goal. The first time Tech Lead might mistakenly see their role leading on all the technical aspects and forget about how the team works together. Although this responsibility may be shared with other roles such as the Team Lead or Project Manager, a Tech Lead must also shepherd the team to move in the same technical direction.

It is all too easy for the first time Tech Lead to ignore heated discussions between two developers, or to ignore how technical team members interact poorly with or disrespect non-technical team members.

The more experienced Tech Lead realizes that the lead part of their role is just as important as the tech, and constantly looks for ways to build trust and relationships between people in the team. They use practices like white-boarding architectural diagrams as a team, establishing coding or architectural principles with the team to guide individual decisions or running regular improvement katas or retrospectives.

Conclusion

The first time Tech Lead can easily fall for a number of traps, often caused by habits developed from their time as a developer. To overcome these traps, they must find ways to strike a balance between their technical and leadership responsibilities.

5 Tips for Being an Effective Tech Lead

February 26, 2018 / / 2 Comments

Becoming a Tech Lead is a tough transition for any developer, because only part of the skills and experience you had as a developer prepares you for the expectations of a new role. Instead of simply designing and writing code, a Tech Lead is suddenly responsible for an entire development team – and this means dealing with people, both technical and non-technical.

The time a developer spent focusing on writing well-designed code does not translate into the skills necessary for understanding people, resolving conflict, or suddenly having to juggle more tasks than they can possibly achieve by themselves.

Tech Lead Dilemma

I present 5 tips for being an effective Tech Lead.

1. Learn to Delegate

As a developer, you get a kick from working out what the hard, technical problem is to solve. You research different ways to solve the problem, seek the most simple solution and celebrate a victory when you want that red, failing test going green.

As a Tech Lead, you cannot take on all the coding tasks, and cannot take on all the hard or interesting problems, regardless of your experience. You have many more responsibilities that need time and attention, and if you are focused solely on a single task, those other responsibilities will fail to be fulfilled. When you take on the harder problems, it also misses opportunities for other developers to grow and problem solve, which will lead to frustration and potentially people leaving your team!

Of course, there are some problems when your experience and knowledge are important, but you do not want to be a bottleneck in solving problems, so you want to find a way to delegate and still be involved. Solutions might include kicking off a design session with developers to talk about general approaches, and reviewing progress with the developer on a regular basis to see if things are on track.

As you and the developer build trust with each other, you can be less involved and fully delegate an activity to let you focus on more important tasks.

2. Find Time to Code

The role is called “Tech Lead” for a reason, and it is essential that you find some time to spend in the codebase. Being involved in the code helps you build respect with the rest of the team, but it also helps keep your knowledge up to date and current with constraints, problems and the “shape” of the current codebase.

If you do not spend time with the code, you run the risk of invoking the “Ivory Tower Architect” anti-pattern, leading technical decisions without understanding their real implications for implementation or maintenance. This anti-pattern has numerous side effects including destroying trust with developers, increasing the development time of new features, and increasing the accidental complexity of your software systems.

There are many different ways a Tech Lead can find time to code, but it is essential that you make it a priority. This often means making difficult choices about where you spend your time. Tip #1 should help increase the amount of available time you have. I know some Tech Leads who will block out time in their calendar to ensure that there is always time during the week to write or review code with the other developers. I know of other Tech Leads who review commit logs, and provide feedback to developers – similar to a loose pair-programming style.

3. Visualise Your Architecture

I have worked in several teams where developers had no idea how their task fit into a bigger picture. A small technical decision made by a developer might have a wider architectural impact, but is impossible to prevent if developers do not understand the broader picture.

An effective Tech Lead often has a visual representation of their system architecture on-hand and uses it to have discussions with developers. There will often be different views of the architecture (logical, deployment, etc) and each diagram helps developers see how their task fits into a broader system architecture.

A whole-team whiteboard session is often a useful exercise for reviewing the overall architecture, as it evolves over time to meet differing requirements and the discussion during the session is even more important than the diagram. Focus on key quality attributes that drive out your architectural vision (scalability, performance, usability concerns, etc) and how they have shaped your architecture. Call out assumptions and the historical context to help developers guide their everyday decisions.

4. Spend Time 1-on-1 With Team Members

An effective Tech Lead will not be measured with how many coding tasks they complete. They are measured by how effective their software team is. Anything that a Tech Lead can do to make each person on their team better, makes the overall team better. Sit down with members on your team to understand their backgrounds, their strengths, their interests and their goals to understand how the people in your team fit together as a group. Connect developers with opportunities for them to grow. This means allowing them to take risks so they can learn and grow, but also contribute to the team. Encourage people sharing knowledge across the team and find ways to help each team member connect with each other.

5. Learn to Speak the Language of the Business

To be an effective Tech Lead, you will need a great relationship with people outside of the development team including people like Product Managers, Marketing, Sales and CxOs. They will not understand the vocabulary you accumulated as a developer, and talking to them in terms of frameworks, technical tools and platforms will only confuse them.

An effective Tech Lead finds ways for non-technical people to understand technical concepts, and the best way to do that is to find the terms that business people use and find ways to explain tasks in those terms. Use visual models, whiteboard sessions and metaphors to help business people understand technical concepts and their implications. You might rehearse on friends or relatives who don’t work in technology to see if you can succinctly explain an idea.

Minimize the translation layer as much as possible by bringing business terms into the development team and encouraging their use as much as possible. The better the developer team uses these domain terms, the better their understanding and empathy with business stakeholders will be.

This is a repost of an old blog post I published while I worked at ThoughtWorks and wanted to recapture it here. See the original here.

« Older posts

© 2024 patkua@work

Theme by Anders Noren — Up ↑