patkua@work

The intersection of technology and leadership

Category: Organisations (Page 2 of 6)

Book Review: Accelerate

May 27, 2018 / / 0 Comments

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.

Starting as CTO at N26

September 18, 2017 /

I’m excited to announce that I’ll be taking on the Chief Technology Officer (CTO) role for N26 (formerly Number26), Europe’s first mobile bank with a full European banking license, and who is setting new standards in banking.

I’m joining an exciting and talented team based in Berlin, Germany – one of the favourite start-up cities in Europe. In my new role, I’ll draw upon more than a decade of my consulting experiences with the well-respected and industry-changing technology firm, ThoughtWorks – best known for leading the adoption of agile ways of working (particularly its technical practices), publishing open-source software like CruiseControl (the first widely used Continuous Integration servers) and Selenium (well-known automated web-testing tools), and sharing ideas through books like Continuous Delivery and the Lean Enterprise. I’m really looking forward to applying my experiences guiding organisational design, building evolutionary architectures, developing technical leaders all while sustainably delivering value for our customers.

What will be different?

After many years as a consultant, I realise that working with a product organisation is a different beast. I look forward to having some responsibility to instigate and guide changes throughout the organisation and living out the long-term consequences (both good and bad!) of my actions. I know that this is often a missing feedback loop for consulting. In my role, I’ll be able to invest more in challenging and growing people and building out new technical and organisational capabilities.

I also look forward to spending a bit more time “at home”. I still expect to travel for my new role, still speak at some conferences but I hope I will have a bit more say as to when and where I’ll travel to, based on our business needs rather than where clients happen to be based. Did I mention that I’ll also be based in Berlin, and it’s a great city with a very good balanced lifestyle? I might even get a chance to further develop my German again.

Why FinTech and N26?

As a consultant, I was always skeptical about having significant long-term impact on established financial companies. With teams, or parts or the organisations, yes. With a 10,000+ person company, less so. The exciting part about working with N26 is that I will work with a strong management team to prevent unnecessary bureaucracy and to let people focus on adding value to the product and organisation. We benefit from not supporting certain types of legacy, and building software with Continuous Delivery and modern technologies first. I’ll be helping guide us away from the traps and pitfalls I have seen many customers suffer from in the last decade.

The N26 Black Card

I also like the fact that N26 is growing fast, and has already proven to meet customer needs, where all growth has been organic so far with very little advertising. Did you know that we recently hit 500,000 customers? It’s also one of the first mobile-first startup banks with a European banking licence, which opens up a world of opportunity that a lot of other FinTech banking products do not yet have.

Here’s what TechCrunch wrote two years ago:

N26 (Number26) could be the best banking experience in europe – Tech Crunch

Bank of the future

In case you can’t tell, I’m really delighted to be leading the technology organisation behind the bank of the future. The team has already accomplished a lot so far, and I look forward to working with the team to do even more. We’re going to build an exciting place to work in the FinTech sector and have a huge impact on our ever-growing customer base across Europe. If you’d like to be a part of the N26 team and join me on this journey, did I mention that we are hiring?

Drop me a line on twitter @patkua (DM’s open), or on my email address if you’re even curious. Berlin’s a great city to live and N26 is a great place to work while you’re there.

Book Review: Scaling Teams

June 5, 2017 / / 1 Comment

This weekend I finished reading Scaling Teams by Alexander Grosse & David Loftesness.

I know Grosse personally and was looking forward to reading the book, knowing his own personal take on dealing with organisations and the structure.

tl;dr Summary

A concise book offering plenty of practical tips and ideas of what to watch out for and do when an organisation grows.

Detailed summary

The authors of the book have done a lot of extensive reading, research and talking to lots of other people in different organisations understanding their take on how they have grown their organisations. They have taken their findings and opinions and grouped them into five different areas:

  • Hiring
  • People Management
  • Organisational Structure
  • Culture
  • Communication

In each of these different areas, they describe the different challenges that organisations experience when growing, sharing a number of war stories, warning signs to look out for and different approaches of dealing with them.

I like the pragmatic approach to their “there’s no single answer” to a lot of their advice, as they acknoweldge in each section the different factors about why you might favour one option over another and there are always trade-offs you want to think about. In doing so, they make some of these trade-offs a lot more explict, and equip new managers with different examples of how companies have handled some of these situations.

There are a lot of links to reading materials (which, in my opinion, were heavily web-centric content). The articles were definitely relevant and up to date in the context of the topics being discussed but I would have expected that for a freshly published book. A small improvement would have been a way to have them all grouped together at the end in a referenced section, or perhaps, (hint hint), they might publish all the links on their website.

What I really liked about this book its wide reaching, practical advice. Although the book is aimed at rapidly growing start-ups, I find the advice useful for many of the companies we consult for, who are often already considered very succesful business.

I’ll be adding it to my list of recommended reading for leaders looking to improve their technology organisations. I suggest you get a copy too.

Types of Development Teams

December 17, 2015 / / 2 Comments

In some of the Tech Lead courses I have held, we sometimes talk about leadership styles and whether or not the Tech Lead role is essential. During these discussions, one of the biggest influences on both style and necessity is the style of teams.

This article represents my current classification of teams I have seen over my years in industry.

One man army

A lonely developer working on a project by themselves. Most likely they are working on multiple projects and consequently multi-tasking, because that’s the way the organisation works. Often seen in organisations that are siloed. Technically not a team but treated as a part of a team.

Distributed

Distributed teams come in many shapes and sizes. Although distributed teams are similar to Off-Shore teams (see below), distributed teams tend to be a team spanning several locations. GitHub are an example of a distributed team (and organisation). Often seen with start-ups who are seeking talent not easily found in the same location.

A distributed team typically spans several timezone, making an “all-hands” meeting more difficult. Relies on asynchronous tooling such as chat software (e.g. IRC, Slack) and virtual task boards.

Off-Shore

An Off-Shore team is a distributed team in mainly two locations. Often used by many IT organisations as a “cost-cutting” tactic trading communication effectiveness. Sometimes an off-shore team is a historical artifact (company acquisition or expansion) and necessary to keep essential knowledge alive.

Off-shore teams often have better overlap with time zones that fully distributed teams, but often results in an us-and-them mentality.

The “Pod” shaped team

The “Pod” shaped team is a co-located team who that has most of the skills they need to deliver a project. The team often includes a PM, developers, analysts, testers and sometimes operation and support people. They are all working towards the same project at the same time. This reduces co-ordination and communication lag and makes software delivery more effective.

They are called a “pod” because they are kept to a certain size (typically less than 12 people) to keep communication overhead minimised.

Functional Silos

Functional silos are not representative of effective teams because people are grouped managerially and physically by skillset instead of by goal. Each group is managed by a separate person and in larger company, decision making and authority reaches several layers much higher into the organisational hierarchy. Collaborating and changing the way that a team working on the same project across functional silos becomes very difficult to change.

Typical functional silos often seen: PM (and their PMO), Analysis, Developers, QA, DBA, System Administrators, Network and Support.

The dark side of gaming metrics

December 7, 2015 / / 0 Comments

I published an article a while ago on how to design for metrics, but I read this well-written, but article of horror, “Why drivers in China intentionally kill the pedestrians they hit.”

This article hits home about the reality of a population gaming a metric and what is leading to a shift in cultural values through their actions. The short story, if you don’t read the article is that it is apparently seen as more economical to pay for someone’s death, than for their healthcare overall combined with a low chance of apparently being caught for murder. Due to the economic cost, it has apparently become acceptable, or at least, very common for someone to finish someone off, rather than pay for what medical aid they made need.

Championing P3 on a panel at DevTalks Bucharest

June 15, 2015 / / 0 Comments

On Thursday I was presenting at DevTalks Bucharest, a 550+ developer conference with four different stages. I shared the panel with a Sabin Popa (Cloud Strategy Leader at IBM) and there was supposed to be another panelist but they had withdrawn. The topic of the panel was, “Innovation and data privacy – Keeping innovation alive in Cloud!” We first presented a bit about ourselves and our companies, where I was talking about our three pillars: Sustainable Business (P1), Software Excellence (P2), and Social Justice (P3).

Image courtesy of

Image courtesy of Phillipp Krenn (@xeraa)

I talked a lot about observations we see around the world with our clients – these stories really resonated with people, particularly because:

  • It is based in reality (and not just sales demonstrations or fancy presentations)
  • People are genuinely interested in what other people are doing around the world.

During the panel, I talked about the responsibilities that we have as developers for privacy, and the responsibilities that we have as educated citizens to get this on the agenda of our parliaments. I touched upon the idea of Datensparsamkeit and that we can use our knowledge to start raising awareness among our friends and families.

Although not meaning to, I found that I probably spent a lot of time talking on the panel – but mostly because both the moderator and the other panelist wanted to keep asking questions of me. I had suggested that Sabin also give his own thoughts about what they could be done about data privacy.

When we touched the topic of innovation in the cloud, the topic of certification came up – something that didn’t really surprise me. One statement was that all platforms would be certified in the future (for security) and that would be considered one form of innovation. Although useful, I challenged the position, talking about how certification gives false confidence – particularly in services and products where people are involved. I think certification is definitely useful for testing mechanical parts, for testing platforms and products that never change – but software is soft. It constantly involves and once a platform is certified, doesn’t mean it will continue to pass the same tests. I see a lot of companies sell certification as an easy answer and I believe it gives companies a false sense of confidence.

An interesting question posed to the panel is what would we do if we are asked by our company to do something that is borderline unethical but not doing the task puts our job at risk and the mention that there are many more people to do our role. This, for me, was an easy answer. I talked about our responsibility of being digitally-educated and responsible citizens of the world and talked about the bravery and confidence of people like Snowden. I challenged everyone we should think through the consequences of mindlessly doing tasks that we don’t believe in and not think about just the consequences of the job right now, but question the consequences for our family, friends and the world we are creating for future generations.

Roles, not People

June 3, 2015 / / 0 Comments

Naming functions and methods are one of the hardest tasks developers need to take. A good name is hard to find, but with enough thought, is useful to show intent.

Likewise, the name for a given role is useful to help establish what that role is accountable for, and can help speed up communication when people have a common understanding of that role.

All models are wrong, but some are useful – George E.P. Box

Unfortunately there are two inherent problems with role titles:

  • People do not understand the role
  • Roles are not the same as people

Issue 1: People do not understand the role

One point of confusion is assumptions about what the role does or does not do. For example, a Project Manager might assume that the QA role will be responsible for a Testing Strategy. In another situation, a different Project Manager might assume the Tech Lead will be responsible for a Testing Strategy. In this case, different expectations could be a source of conflict about which role is responsible for the Testing Strategy.

Another example might be where the Tech Lead assumes the QA role is responsible for the Testing Strategy, and the QA role assumes the Tech Lead is responsible – resulting in no one really thinking about a Testing Strategy.

A great way mechanism to force a way forward is to run a “Roles & Responsibilities” session. I find an effective method to run one is:

  • As an entire team, brainstorm all the important activities that must be completed by the entire group. Ensure that one activity is written on a separate sticky note.
  • Brainstorm some names of roles and put them at the top of a whiteboard/flipchart next to each other. You may want to add a generic “Everyone” or “Team Member” role as well.
  • Ask everyone to place each activity under the roles they think should be responsible for the activity.
  • Walking the board, review each role one at a time and their activities, inviting discussion and disagreement about why the role should be/not be responsible for that particular activity.

This is a very useful exercise for helping to define, and articulate confusion around particular goals.

Issue 2: Roles are not the same as people

Another common failure mode of roles is where people assume that a role is the same as the person. On my business card, I have the title: Generalising Specialist because it’s true – although I consider myself a developer, architect or Principal Consultant, I am also much more than that.

Generalising Specialiast

Generalising Specialiast

People come with a whole bag of skills and experiences that sometimes fit into a particular role. Just as important as it is to understand a person’s strengths – it’s just as important to understand where their fit for a role is and the gaps. A person may be much more capable of playing several roles at once, or a role can be split among a group of people with the right set of skills and experiences.

Concluding thoughts

Remember that roles are a name we give to a collection of responsibilities and it doesn’t necessarily map to single people. A role may be split among people (where the responsibilities are distributed) but it is essential that everyone has the same understanding of who has those responsibilities.

A Tech Lead Paradox: Technical Needs vs Business Needs

December 8, 2014 / / 7 Comments

Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.

A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.

A common Tech Lead paradox is the case of Technical Needs versus Business Needs.

The case for Technical Needs

Before cloud services were available on the Internet, most companies would invest in hardware to run their services. The work to setup and configure machines was easier for non-technical stakeholders to see because of its physical aspect. Today software requires even more software and non-physical services that need configuring, testing and releasing. Much more of it is virtual.

Practices such as Continuous Delivery do not come without some overhead, although it provides an invaluable business capability. All of these “internally-facing” technical requirements demand time from the software delivery team.

The case for Business Needs

A lot of software is written for businesses, whose overall goal is to make money. A business that does not evolve their business offerings will lose out to competitors or to the ever-changing consumer marketplace. This means a business wants to always experiment with their existing services, or provide new services to keep their existing customer base, or to attract new customers.

This pressure to modify, or introduce new services demand either software support, or new software to be developed.

The conflict

A business will always put pressure on a development team to produce as much software as possible. At the same time, effective delivery of software is not possible without addressing some level of technical needs – such as technical debt, deployment pipelines, or automated test suites.

Time spent on technical needs is expected to improve developer effectiveness, but this is often hard to measure and prove to outside stakeholders. An endless amount of time can always be spent tweaking, optimising and improving technical infrastructure and tools. What starts off as “just an afternoon” turns into a week, or a month and business features are put on hold as a result. If this happens too long, the business might miss agreed external deadlines for certain features and thus lose customers, or money.

What does a Tech Lead do?

Champion time for Technical Needs

A Tech Lead champions for time to spend on Technical Needs by being part of the prioritisation process. They ensure that enough work is delivered, or finds solutions to business problems that minimise the amount of software that needs writing. They ensure the team is not over-loaded with delivering new features and changes and finds small slices to work on technical needs that will provide a good benefit.

Explain the business benefit of each Technical Need

A team can spend an endless amount of time investigating, configuring and supporting their technical infrastructure. A Tech Lead will have support from non-technical stakeholders if they understand what benefits they bring. The successful Tech Lead can explain not just what the team is working on, but also why and who else benefits.

Some typical business benefits include: reducing the amount of repetitive work, improving the quality (by minimising the chance of human error), or to prove out a business opportunity.

The Tech Lead builds trust with non-technical people by highlighting benefits on Technical Needs and also demonstrating if they reach those benefits.

Work on high impact items first

A list of Technical Needs will often be endless, so a Tech Lead will work to prioritise the list, culling items that no longer make sense, or pulling work items forward that may have an immediate and significant effect.

Keep a balance

The Tech Lead is mindful that the team cannot work on Technical Needs alone, and watches to ensure a good balance is met.

Maximise the use of “quiet” periods

Sometimes a development team will outpace the ability for a business to prioritise, “What’s next?” You might recognise these periods when a Product Owner has met all their objectives, or they are working on clarifying the next set. The Tech Lead uses these “quiet periods” as an opportunity for their development team to work on infrastructure, or tasks that have always been deprioritised.

These are often good periods for a team to run a “Hack Day” or for the team to work on small ideas they have had themselves that provide a good benefit.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Why you want to give up coding

December 1, 2014 / / 12 Comments

A background story

A friend of mine worked as a Tech Lead, let’s call them Jo (not their real name) for most of their career. A few years ago, Jo moved into a management role that involved very little coding. They were no longer working full-time as a developer and they stopped playing a Tech Lead role. Jo now leads an organisation with six or seven large development groups.

In the definition of a Tech Lead, I suggested a Tech Lead should write code a minimum of 30% of their time. Jo managed to find some time writing code, but it was inconsistent – about an hour a week. In a 40-hour week, that is less than 3%. Jo missed writing code. Jo was no longer a developer and Jo was no Tech Lead.

What do you control? What do you influence?

Every role comes with a set of responsibilities, and the authority to fulfil those responsibilities. This authority gives you a certain amount of control.

For example, a developer has control over the code and tests that they design and write. Others may have influence over the code. Examples of influencing factors include architectural or product and/or platform constraints, team code standards and code reviews. Ultimately the developer has control over their own code.

Every company has a certain organisational design. Developers (and other employees) work within this structure. The organisational design impacts on how effective software delivery is. Rigidly hierarchical structures with completely different departments (e.g. developers and testers) have difficulty collaborating. An ineffective organisational design is a sore point for many developers because it makes delivering software much harder.

A developer has zero control over organisational design. They might be able to influence it, but it is ultimately controlled by managers. Some developers may try to change this, but most complain. I have heard this from developers in the past:

Who’s brilliant idea was to setup a development [team] like this?

Who's great idea was this?
Another example.

I can’t get anything done because I rely on those people to get something done and they sit on another floor.

Developers can complain, which is an ineffective style of influencing, although there are many more effective ways. In the book Influence: The Psychology of Persuasion, the author, Robert Cialdini outlines six key influencing strategies: Reciprocity, Commitment (and Consistency), Social Proof, Liking (a variant of the Halo Effect), Authority, and Scarcity.

Developers only influence their working environment. They do not control it. Note: An exception is, of course, when a company is small enough that the developer also takes on general organisational management responsibilities (e.g. in a startup)

Trading control for influence

Influence for control

Jo, who moved from being a developer to a Tech Lead, and again from a Tech Lead to a general manager shared an interesting insight with me.

You know those things I used to complain about as a developer? Well, now I have the ability to change them.

Programmers see the “non-technical” path as a path with nothing to offer. When programmers step into a leadership role, they inherit both responsibilities and the authority to control more of their work environment. A developer works within these constraints. A Tech Lead has more authority to change those constraints, and a manager even more authority to control and change those constraints.

How does this impact developers who become Tech Leads?

When developers give up their control in trade of influence, their sphere of influence grows. Instead of developing a single feature, they can guide the entire technical solution. The Tech Lead’s influence also grows between the technical and the business side. A Tech Lead has much more influence over how technology can be used to solve business problems, while developers are engaged too late.

I would suggest to Tech Leads never to give up all coding. Instead, it is trading more of the time you would spend crafting code, in exchange for a wider sphere of influence. The wider sphere of influence helps not just you, but also your team write better code in a better work environment.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub. The featured image from this post is taken from Flickr under the Creative Commons licence

A Tech Lead Paradox: Delivering vs Learning

November 24, 2014 / / 4 Comments

Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.

A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.

A common Tech Lead paradox is the case of Delivering versus Learning.

The case for delivering

In the commercial of software development, there will always be pressure to deliver software that satisfy user needs. Without paying customers, companies cannot pay their employees. The more software meets user needs, the more a company earns, and the more the company can invest in itself.

Business people will always be asking for more software changes as there is no way of knowing if certain features really do meet user needs. Business people do not understand (and cannot be expected to fully understand) what technical infrastructure is needed to deliver features faster or more effectively. As such, they will always put pressure on to deliver software faster.

From a purely money-making point of view, it is easy to interpret delivering software as the way of generating more earnings.

The case for learning

Software is inherently complex. Technology constantly changes. The problem domain shifts as competitors release new offerings and customer needs change in response and evolve through constant usage. People, who have certain skills, leave a company and new people, who have different skills, join. Finding the right balance of skills to match the current set of problems is a constant challenge.

From a technologist’s point of view, learning about different technologies can help solve problems better. Learning about completely different technologies opens up new opportunities that may lead to new product offerings. But learning takes time.

The conflict

For developers to do their job most effectively, they need time to learn new technologies, and to improve their own skills. At the same time, if they spend too much time learning, they cannot deliver enough to help a company to reach their goals, and the company may not earn enough money to compensate their employees and in turn, developers.

Encouraging learning at the cost of delivering also potentially leads to technology for technology’s sake – where developers use technology to deliver something. But what they deliver may not solve user needs, and the whole company suffers as a result.

What does a Tech Lead do?

A Tech Lead needs to keep a constant balance between finding time to learn, and delivering the right thing effectively. It will often be easier for a Tech Lead to succumb to the pressure of delivering over learning. Below is advice for how you can keep a better balance between the two.

Champion for some time to learn

Google made famous their 20% time for developers. Although not consistently implemented across the entire organisation, the idea has been adopted by several other companies to give developers some creative freedom. 20% is not the only way. Hack days, like Atlassian’s ShipIt days (renamed from FedEx days) also set aside some explicit, focused time to allow developers to learn and play.

Champion learning that addresses user needs

Internally run Hack Days encourage developers to unleash their own ideas on user needs, where they get to apply their own creativity, and often learn something in the process. They often get to play with technologies and tools they do not use during their normal week, but the outcome is often focused on a “user need” basis, with more business investment (i.e. time) going towards a solution that makes business sense – and not just technology for the sake of technology.

Capture lessons learned

In large development teams, the same lesson could be learned by different people at different times. This often means duplicated effort that could have been spent learning different or new things. A Tech Lead can encourage team members to share what they have learned with other team members to spread the lessons.

Some possibilities I have experienced include:

  • Running regular learning “show-and-tell” sessions – Where team members run a series of lightning talks or code walkthroughs around problems recently encountered and how they went about solving it.
  • Update a FAQ page on a wiki – Allows team members to share “how to do common tasks” that are applicable in their own environment.
  • Share bookmark lists – Teams create a list of links that interesting reads based on problems they have encountered.

Encourage co-teaching and co-learning

A Tech Lead can demonstrate their support for a learning environment but encouraging everyone to be a student and a teacher at the same time. Most team members will have different interests and strengths, and a Tech Lead can encourage members to share what they have. Encouraging team members to run brown bag sessions on topics that enthuse them encourage an atmosphere of sharing.

Weekly reading list

I know of a few Tech Leads who send a weekly email with interesting reading links to a wide variety of technology-related topics. Although they do not expect everyone to read every link, each one is hopeful that one of those links will be read by someone on their team.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑