patkua@work

The intersection of technology and leadership

Author: Patrick (page 1 of 51)

Book Review: Factfulness

Book Review: Factfullness

It was almost a decade ago, I first watched Hans Rosling talk about the ever changing state of the world (see the videos here). He was a poster-child for demonstrating how visuals can bring static data to life. In his last legacy to the world, Rosling published the book, “Factfullness.” Unfortunately he passed away in 2017 due to pancreatic cancer.

Factfullness reflects many of Rosling’s personal stories. It also shares his frustration with a world filled with bias and “fake news.” This book is extremely relevant given the current state of politics both in the UK and the US. 

Factfullness challenges us to push past biased social and news media. Instead we should focus on globally available data such as from the United Nations. In the book, Rosling paints a much more positive view of the world than what the media likes to portray. As he often repeats, “It may still be bad, but it’s significantly better.”

Fuelled with data, Rosling shows us how child mortality is drastically decreasing. He demonstrates how fewer people live in critical poverty. He reminds us how women have better rights today. The book highlights how monkeys are more factful than educated humans. Rosling points out we are less factful because of “Instincts.”

The Gap Instinct describes how we quickly classify something into one of two camps. Examples include being poor/rich, sick/healthy, or us/them. Reality is more of a spectrum, with a majority in the middle and that there’s not that much of a gap. Rosling warns us to be careful of extreme comparisons.

The media fuels the Negativity Instinct. Rosling points out, “Negative news sells.” He contrasts this with an observation that  incremental improvements are not considered newsworthy. In this chapter, he starts using the phrase he later repeats, “It can be both better and bad.” (The situation can still improve, but the world has improved significantly.)

The Straight Line Instinct describes how we think linearly. In the context of an ever growing population, this instinct fuels the fear of overpopulation. Rosling highlights how childbirth rates reduce as a country becomes more prosperous. He challenges us to use data to better understand the shape of data. He gives examples where curves are more like doubling curves, or act like an S-curve. Straight line functions are the exception rather than the rule.

Rosling shares a personal example where the Fear Instinct causes unclear thinking. This reminds me of the Type I thinking (from Thinking Fast and Slow by Daniel Kahneman). Type I thinking means we react in critical situations with poor results. Fears from physical harm, captivity or contamination drive us to act irrationally. Rosling challenges us to differentiate between frightening and dangerous. Danger is risk multiplied by exposure. When we recognise this instinct, seek calmness before making an important decision. 

The Size Instinct focuses our attention on individual numbers out of context. A compelling story or a concrete example leads to us overestimating an impact. Rosling recommends we look at numbers in proportion. We should do relative comparisons, or look at trends rather than numbers alone. Rosling reminds us of the Pareto Principle (80/20 rule) or use rates (e.g. number per person).

The Generalisation Instinct describes our habit to automatically category and generalise. Stereotyping through generalising leads us to incorrect conclusions or unjustified judgements. It also leads us to poorer decisions. GapMinder invented Dollar Street to highlight different categories. Rosling challenges us to look for differences and similiaries across categories. Avoid using categories to justify an assumption.

The Destiny Instinct drives us to believe destiny is pre-determined. This reminds me of the Fixed versus Growth Mindsets, made popular by Carol Dweck. To fight the Destiny Instinct, we must recognise small improvements and changes. We should seek knowledge about how cultures and societies do change over time.

The Single Perspective Instinct drives us to seek a simple solution or answer. I recognise this instinct from my studies in Systems Thinking. A counter against this instinct is to collect different Mental Models. Each Mental Model provides a different perspective on a situation. I loved this quote from this chapter. “The world cannot be understood without numbers, and it cannot be understood with numbers alone.”

The Blame Instinct describes our desire to find a scapegoat, or to point the blame at an individual. It blocks our ability to focus on contributing factors. It also means we are unlikely to prevent similiar problems in the future. Rosling provides great advice here. It reminds me of advice for healthy, blameless post-mortems. “Look for causes, not villains and look for systems, not heroes.” 

The final instinct Rosling describes is the Urgency Instinct. This instinct draws upon Type I thinking and biases for action now rather than later. Rosling reminds us that urgent decisions are rare. He encourages us to take a breath, insist on data and be wary of taking drastic actions. 

I really enjoyed reading this book. Rosling’s personal stories bring vibrancy to the book. He highlights how even “experts” or “highly educated” people fail to act factfully. The book makes us wary of the “Instincts” and provides concrete actions to help us. If you’re interested in learning more about Factfullness, get the book here.

6 Lessons Learned in my year as CTO at N26

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

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. 

Flavours of Agile

I started programming around the time people published the Agile Manifesto. My manager at the time handed me the first edition of Extreme Programming Explained. I was also lucky to work in an environment where I could see the first hand problems agile set out to solve. 

Fast forward many years later and agile is “mainstream.” Others defined new agile methods. I want to use this article to capture my understanding and share my opinion about these methods. This means you may not like what you read. Consider this your warning. 🙂

The original agile methodologies

Scrum

Scrum is today, sadly, synonymous with Agile. Founded by Ken Schwaber (now with Scrum.org) and Jeff Sutherland (now with Scrum Inc). I see this agile methodology as an improved project management process. It brings rhythm and synchronises people all working towards the same goal. I like how Scrum provides a simple starting framework that builds trust through incremental delivery. Plan a bit, deliver a bit, inspect and adapt.

What I don’t like about Scrum is the cult-like behaviour driven by commercialisation. Subscription “certification” for sitting in a class for 2 days anyone? Like all typical corporates, the Scrum Alliance has expanded to offer ~10 certifications. NOTE: Scrum certifications do not (for me) equate to competence or experience

My usefulness rating: 7 out of 10

Extreme Programming (XP)

I’m definitely biased because I started off with this methodology. Invented by Kent Beck, XP builds on Scrum practices and adds in technical practices. Even these technical practices bring value without necessarily following XP. Examples include Continuous Integration, Pair Programming, Refactoring, and Automated Testing including TDD.

I like how XP highlights technical practices that make agile software development work.

My usefulness rating: 9 out of 10

Feature Driven Development (FDD)

In my experience, FDD is not heavily used in the industry. It’s iterative, focuses on domain modelling and used dynamic teams to create features. I like how there is an explicit design phase for features and a focus on unit testing. 

In opposition to XP, FDD encourages individual class/feature ownership. I feel this trades-off consistency within a feature against consistency in the application. I used FDD as an inspiration for delegating to Feature Leads.

My usefulness rating: 6 out of 10

Adaptive Software Development (ASD)

ASD stems out of the Rapid Application Development (RAD) methodology. It grew from the work of Jim Highsmith and Sam Bayer. This methodology is super simple. Small cycles of Speculate, Colloborate and Learn.

ASD is not prescriptive with its practices, instead providing guidelines. I like how it highlights Mission, Vision, Leadership and People. This will specifically appeal for those in management roles. It was one of the first books to recognise software as complex adaptive systems.

My usefulness rating: 6 out of 10

Dynamic Systems Development Method (DSDM)

I have never experienced this methodology in the wild. I see DSDM as another project management framework fitting with the spirit of agile. I like the emphasis on modelling and the invention of MoSCow (Must Have, Should Have, Could Have). 

I like less that it’s “owned” by a consortium, which limited its adoption to mostly the UK.

My usefulness rating: 3 out of 10

Crystal

Crystal is a meta-methodology. Alistair Cockburn, who thinks deeply about the process of building software, invented Crystal. Crystal is the methodology to help define a specific methodology. Cockburn describes a process to “tune” a methodology to fit its context. Cockburn created specific methods (e.g. Crystal Clear) for different contexts. Some cater to larger groups. Others consider the domain characteristics (e.g. safety or life critical)

Like other agile methodologies, Crystal focuses on collaboration and communication. In his book, I liked how Cockburn described osmotic communication. It was also one of the first methodologies I read that focused on personal safety. Google’s research demonstrated how important psychological safety is for high performing teams.

My usefulness rating: 6 out of 10 (It would rate higher but I scored it less because it’s a meta-methodology)

Second-wave agile methodologies

I refer to the following as second-wave methodologies. They emerged as more people connected with the agile values and community.

Lean Software Development (LSD)

The Poppendiecks created LSD by importing lean manufacturing ideas into software development. LSD focuses more on principles and, to me, feels less concrete compared to other agile methods. I really liked the ideas of value stream mapping and trying to follow and reduce waste. 

I was never able to reconcile one mental model. Product discovery is naturally exploratory in nature. Except if you are digitising a manual process. As a result, there is some natural waste in the system that you can’t get away from.

My usefulness rating: 7 out of 10 

Kanban 

David Anderson created the official “Kanban Method”. He took the Theory of Constraints and applied it to the flow of software development. This method is simple and is a super useful Getting-Things-Done (GTD) technique. I’ve heard of weddings and house moves planned with Kanban boards. I’ve even used one myself for Christmas meal planning.

The method is easy to get started and immediately practical

My usefulness rating: 8 out of 10 

Scrumban

Loosely attributed to the evolution of teams as they move from rigid Scrum to Kanban. 

My usefulness rating: 7 out of 10 

Scaled agile methods

As agile went mainstream, large organisations wanted to “adopt agile at scale.” The result is a plethora of methods that cater for the “enterprise.” I have yet to experience any of these successfully work at creating a truly agile organisation. Many of these feel like rebranding existing dysfunctions as “acceptable agile.”  

Scaled Agile Framework (SAFe)

Many leading agilists have written enough about SAFe for you to make up your own mind. I have witnessed a poor enterprise choose to go down the SAFe path. They found it didn’t help them solve many issues. I feel SAFe allows mediocrity. I find it doesn’t put enough emphasis on the continuous improvement. Nor does it emphasise a shift of values (e.g. “People over process”). 

I do like that it touches upon topics such as Portfolio Management and Architecture. I don’t think that makes SAFe agile.

My usefulness rating: 2 out of 10 

Large Scale Scrum (LeSS)

I know Bas Vodde personally from the retrospective community and I have a lot of respect for him. Bas Vodee and Craig Larman (creators of LeSS) also wrote a book about Scaling Lean & Agile Development. The book acts as a case study from their experiences. 

I haven’t personally experienced LeSS. I feel that LeSS is more in the spirit of agile than SAFe. It is a starting framework (the authors say it themselves) about how you might apply Scrum to very large groups. LeSS focuses on 1-8 teams and LeSS Huge focuses on 8+ teams. This is a simple starting framework that organisations might use as a starting point. 

I find the LeSS website rather confusing to navigate.

My usefulness rating: 5 out of 10 

Scrum@Scale

One of the founders of Scrum (Jeff Sutherland) first published the guide for Scrum@Scale. The guide is free, simple and very Scrum focused. Scrum@Scale doesn’t simply target agile software development, so is very process focused. It doesn’t mention any technical practices that are also needed at scale.

It feels like it tries to keep the agile spirit, by being lightweight, simple and iterative. Scrum@Scale introduces more complex terminology (e.g. Executive Action Team, Executive MetaScrum). I can see how this might help large projects involving lots of people.

My usefulness rating: 5 out of 10 

Nexus

Nexus is Scrum.org’s answer to scaling Scrum. Ken Schwaber (the other Scrum founder) defined Nexus. Nexus attempts to create more alignment via its Nexus Integration Team. Nexus also applies many Scrum practices to this central group. Examples include the Nexus Daily Scrum, Nexus Sprint Planning & Review and the Nexus Retrospective.

I like how Nexus reuses many of the Scrum concepts to try to provide consistency with its scaling method. It feels lightweight enough. Nexus aligns with core agile ideas. It focuses on  transparency, iterating and the constant flow of value. 

I don’t like how Nexus (like Scrum) fails to include any technical practices. 

My usefulness rating: 6 out of 10 

Disciplined Agile Delivery (DAD)

The people behind the, IMHO complicated, Rational Unified Process did it again. They invented Disciplined Agile Delivery. DAD appears to define a solution for the entire organisation. This choice adds a lot of complexity to try to address everything. 

DAD feels less prescriptive than other scaled methods. It still feels to me overly complex. DAD prescribes no single lifecycle for synchronisation. They even map how other practices map to different lifecycles in their view.

Trying to do too much without being prescriptive? A good starting point but its complexity makes it less accessible.

My usefulness rating: 5 out of 10 

Back to basics

Agile started with a simple set of values and principles. Second-wave methodologies connected ideas from other fields to name new practices. When agile crossed the chasm, people tried to “scale” agile and it got excessively complex. Many of these, IMHO, feel like snake-oil. Many focused on selling consulting or training instead of delivering value early. It’s only natural that early agile practitioners tried to bring agile’s core back.

Modern Agile

Joshua Kerievsky invented Modern Agile. The ideas refocus people’s attention away from complex methods. Instead of practices, Modern Agile focuses on four simple principles. It encourages people to be agile instead of simply doing agile. I have a lot of respect for Kerievsky. He is an ideal role model in the agile community. He applies agile values and principles to his company, Industrial Logic. He is also super generous in sharing his knowledge and lessons learned with everyone. 

I like how Modern Agile is so simple. I like how accessible they make it and how they’ve built up a strong community that shares generously. The Modern Agile community shows where to start and how to continuously improve.

My usefulness rating: 7 out of 10 

Heart of Agile

Alistair Cockburn started the Heart of Agile to, once again, focus on principles. I feel this emerged as a result of of “scaling agile” and including “all the practices.” 

I like how the Heart of Agile is a simple set of principles that guides people to think with an agile mindset. It reminds me of the Deming Plan, Do, Check, Act/Adjust (PDCA) cycle of continuous improvement. 

My usefulness rating: 7 out of 10 

Conclusion

I am amazed at the emergence of new “agile methodologies.” From a positive note, it demonstrates how wide agile has reached. It also demonstrates how the Agile Manifesto did such an effective job. A simple set of statements brought a worldwide community together. It provided an umbrella for people to share ideas, knowledge and practices. Agile catalysed improvements in the state of software development.

This list is my attempt to better understand some of the newer methods. I admit this list will never be complete. It also reflects my own, limited and biased views of the methods above. YMMV

I wanted to provide a simple overview of what’s out there (as of this writing). I challenge you, the reader, to start small and iterate. In the true agile spirit, pick something that adds immediate value. Improve your situation and continually inspect and adapt. It will never be perfect but you can continuously improve.

My Personal Productivity Tools

Everyone has their favourite tools for getting the job done. In this post, I want to share some of my favourite pieces of software and how I use them.

For Presentations

I start with an abstract or outline with a simple markdown editor like MacDown (OS). Markdown gives me enough formatting to play with structure and messaging. When I’m happy with this, I use Keynote to prepare the slides. Magic Move transition is the killer app for presentations.

I have an account with The Noun Project for imagery, and use Inkscape (OS) to format and edit the icons. I also rely heavily on another image editor, Gimp (OS). I feel Gimp has more versatility than Inkspace, particularly with photo editing.

For Reading

I like to read books in the real world, but when using my Kindle, I use Calibre to manage my e-books. Refind is super helpful for saving links to find later while I use Pocket to save links to read offline. Feedly plays a big role helping me manage my RSS feeds and plugs straight into Pocket.

My normal workflow looks like this. During short commutes, I browse through Feedly and save interesting articles to Pocket. I   sync the Pocket app before I head to an airport, or hop on a train with limited connectivity. I also save interesting reading material via Refind and Pocket when I’m at a computer.

For Writing

When I started my blog in in 2004 (more than a decade!), I chose WordPress out of all the blogging platforms. I’m very happy with my choice. WordPress outgrew its competition such as Movable Type, Typepad, JRoller, and LiveJournal. I started to use  Hemingway Editor this year for writing, and rely on Flickr (CC) for imagery. ImageOptim is my go-tool for optimising images for the web.

I use Twitter’s native mobile applications and then Tweetdeck for the laptop. I used Tweetdeck long before Twitter acquired them. 

I make heavy use of the Mac/iOS Notes apps to capture ideas and write drafts because it syncs so well across devices. It’s simple enough to jot ideas down where I am and expand on them when I find time to write.

For Everyday Use

I happily use KeePassX as my password generator and manager, syncing to my devices. It syncs well with KeePass Touch on the phone and provides enough usability for me. I also like the control it gives me by not trusting a third party to store this in the cloud. I rely heavily on Google Docs/Sheets for general office administration. I then switch to OpenOffice when I need to work with documents or spreadsheets offline.

Skype and Slack play and almost daily role with me. I use a combination of Stickies and Trello for my personal backlog.

Conclusion

Everyone has their favourite tools that make them effective. These are the ones that I draw upon all the time. What are your favourite tools that you use on a regular basis?

Book Review: Accelerate

I first heard about this book when I saw Jez Humble (@jezhumble) keynote at OOP earlier this year. You will get significant value from this book. Jez has already made many contributions to our industry. He introduced Continuous Delivery (CD) and the Lean Enterprise. He also helped shape the field of DevOps, as we know it today.

The Science of DevOps: Accelerate Book

Think about this book as a very readable academic paper, based on the long-running State of DevOps report.

Rigour in its research method

The book describes how the authors gathered vast data and their research methods. They discuss their observations and lead you to their conclusions, with concrete examples. The author shared how some of their assumptions turned out false. An example is the study showing how there is a positive correlation with Trunk-Based Development (TBD) and quality. This technical book is a rare gem based on rigorous research methods. Nicole Forsgren obviously had a large impact on the book

I’m amazed at how rich their raw dataset is. The authors draw on four years of data from many responses around the world. Their sample size towers over many academic studies. Many academics rely on student control groups instead of real industry data. Rarely academics also get to study a few companies or teams within a single company. The wealth of the raw data gives more weight to the report’s authenticity and credibility.

Martin Fowler highlights one point in the Foreword which I agree with. Even though the survey raw data comes from many sources, it is still self-assessed. Self-assessments are naturally biased by Dunning-Kruger effects.

Strong guidance and good advice

Our industry struggles with useful performance measures in IT. Metrics are either irrelevant or drive poor behaviours. This book debunks false prophets like Gartner’s Bi-Modal IT. Spoiler: You can got fast AND have quality, unlike normal assumptions. The book, Accelerate, gives strong suggestions for useful KPI measures. The authors present convincing conclusions that any modern technology firm should take on. This book gives many ideas to improve software and organisational architectures, and processes.

Many studies such as this focus only on the technical practices (such as CD or TBD). Many experience people realise a focus on technical practices is not enough. They realise organisational processes or structures constrain the value technical practices bring. To make the most of technical practices, management must look at their processes and structures. (Disclaimer: We address this topic in our book about Building Evolutionary Architectures). Maybe it’s confirmation bias, but the chapter on Transformational Leadership is super important.

Here’s an simple example why. Imagine you have an organisation with a Head of Development and Head of Operations. Each have hundreds of people with different reporting structures and processes. If the Heads do not support new initiative like DevOps, collaboration won’t move very far.

Conclusion

I found this book extremely easy to digest. I wanted to read more about their research methods. The authors convinced me of their conclusions and made them come to life with concrete examples. I highly recommend this book for any technology executive in the modern world. Accelerate sets the standards for measuring the performance of technology firms in 2018.

Three Common Mistakes of the First Time Tech Lead

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.

Book Review: 15 Secrets Successful People Know About Time Management

I ended up reading Kevin Kruse’s book, 15 Secrets Successful People Know About Time Management: The Productivity Habits of 7 Billionaires, 13 Olympic Athletes, 29 Straight-A Students, and 239 Entrepreneurs in January but haven’t had the chance to write-up my review. Here it is now!

This book, other than having one of the longest book titles ever, is a huge collection of tips and tricks from a lot of people from different fields. It’s chapters are organised around different topics, with examples and quotes from different people (both famous and not so well known) to help you understand how others manage their time.

At the end of each chapter is the concluding tip, which I’ve summarised here below.

  1. Time is your most valuable and scarcest resource.
  2. Identify your Most Important Task (MIT) and work on it each day before doing anything else.
  3. Work from your calendar and not a to-do list.
  4. Procrastination can be overcome when you figure out how to beat your future self, who cannot be trusted to do the right thing.
  5. Accept the fact that there will always be more to do and more than can be done.
  6. Always carry a notebook.
  7. Email is a great way for other people to put their priorities into your life; control your inbox.
  8. Schedule and attend meetings as a last resort, when all other forms of communication won’t work.
  9. Say no to everything that doesn’t support your immediate goals.
  10. Eighty percent of outcomes are generated by twenty percent of activities.
  11. Focus your time only on things that utilise your unique strengths and passions.
  12. Batch your work with recurring themes for different days of the week.
  13. If a task can be completed in less than five minutes, do it immediately.
  14. Invest the first 60 minutes of each day in rituals that strengthen your mind, body and spirit.
  15. Productivity is about energy and focus, not time.

There are many nice personal stories about situations and each chapter frames the advice in terms of different roles about how it might apply if you’re an entrepreneur, an executive, a freelance, student or a stay-at-home parent.

I really found this book really easy to read as it was one of those books that gives you lots of practical bits of advice that you can apply immediately. I think it’s also a great book if you’re feeling overwhelmed and unsure about how to manage your time and energy. Since all the advice comes from different people, you will find that some of the advice may not be so easy for you to put into practice, but gives you a good set of ideas to try something out for yourself.

5 Tips for Being an Effective Tech Lead

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.

Walled gardens, open source and why I never publish posts to LinkedIn

Whether or not you like LinkedIn or not, it seems to have won the “social network” for professional contacts. This post isn’t so much about LinkedIn, but about some of the well-known tricks to keep people attached to a platform. These techniques are also used heavily by companies such as King Games, Facebook and Snapchat. If you work in tech, I ask you to consider where you post your personal content and what that means for all of us.

Even LinkedIn acknowledges it’s own Authentication “Wall”

Before I go on, I want to share a short trip based on my own personal history.

The growth of the open internet

When I first started working in the industry, J2EE was the new “hype” and people were still using CVS. Email was fairly common, although many were through proprietary platforms (remember Lotus Notes anyone)? Since then, the Internet exploded in popularity bringing with it many open platforms for sharing information and knowledge. You will have benefited from this generosity of knowledge. StackOverflow is now a ubiquitous, open, resource that provides invaluable knowledge for people in tech. Platforms such as WordPress enable anyone to share their views or experiences with the world and this is what is so special about the openness for the Internet. Wikipedia is richer than any Encyclopedia Britannica could have been.

The rise of open-source

One of my first jobs working in tech was working as an intern with Bell Labs. I worked on a perl-based testing system that allowed people to run test scenarios on multiplexers and hardware located within a telephone switch. I remember really clearly how everything was written in-house. You needed a logging library, you’d write it yourself. You needed an error reporter, there was an in-house custom built solution for that.

Since then, the world has really changed. Open source has changed the way that we develop. We literally build on the work of previous generations. We compose libraries and frameworks to focus on what our business problem is, instead of rebuilding common utilities again and again.

Stay a responsible web citizen and keep your content open

If you are in technology, you have benefited from the openness of the internet. Avoid posting your public content to walled gardens such as Facebook, PInterest or LinkedIn which require users to login *before* they read the content. Be a good web citizen and keep your public content open. I will continue to do so (by posting to this blog) and I hope you will too.

Older posts

© 2018 patkua@work

Theme by Anders NorenUp ↑