patkua@work

The intersection of technology and leadership

Page 9 of 53

Everyone can be a leader

June 1, 2015 / / 7 Comments

There are so many definitions of what leadership is so I’m not about to add another one. A nice simple one that I like from the Oxford dictionary is:

The action of leading a group of people or an organisation, or the ability to do this.

Many people assume that playing a role with a title that has “Leader” in it automatically makes them a leader – although this is not always the case. In fact, I have found that sometimes people who pursue roles simply because they have a more senior association with them are not really prepared to lead a group of people.

In my consulting life, I have worked in many teams in many different roles and I have seen many acts of leadership demonstrated by people who don’t have this role.

Examples help.

Example 1: On one of my first projects in the UK that I lead, a developer on the team was passionate about user experience design. He decided to do some ad-hoc user testing on the User Interface (UI) we had written, found someone willing to act as a test subject. He observed what they were doing and reported back to the team his findings. His initiative convinced us that setting aside more time to focus on usability would be a good thing to do. He demonstrated (at least to me) an act of leadership.

Example 2: During one of the Tech Lead courses I gave, I split the class into smaller groups for a number of exercises. I remember one particular group that had a large number of opinionated developers, all trying to get their view across. There was a female developer, who I noticed, listened quietly to all the opinions, waited for a pause before summarising what she heard and asking the group if that was correct. When she reflected back what she heard, she had summarised the different approached, integrated all the opinions and provided a cohesive story that everyone agreed with. She established a clear path that allowed the team to move forward. She demonstrated an act of leadership.

Example 3: On a particular client, there was the traditional divide between the development organisation and the operations organisation (sitting on a different floor). I remember during one of our planning sessions, a developer on the team who had met someone from operations decided to, unexpectedly, invite the operations person to the planning meeting. Although it was a surprise to us, we saw the appreciation from the operations person being involved earlier and probably changed the outcome of what we would have planned without them. He was passionate about the DevOps culture and demonstrated an act of leadership.

I do a lot of speaking and writing on leadership in our industry and what I like about these examples are acts of leadership that come without the authority of a title. Taking initiative, driving people towards a common goal, even in small incremental steps are acts of leadership that mean that everyone can be a leader.

Book Review: Software Architecture for Developers

April 28, 2015 / / 1 Comment

Simon Brown’s book, Software Architecture for Developers has been on my reading list for some time. I am aware of Brown’s talks that he gives at conferences, and his very good workshop on describing how to draw more effective diagrams as a communication mechanism for developers to other groups, but I wasn’t quite sure what his book was going to cover.

Software Architecture for Developers

This weekend, whilst travelling, I had a bit of airport time to do some reading to plough through his book.

What I enjoyed about the book
Architecture is a touchy subject, and Brown doesn’t have any problems raising this as a contentious topic, particularly in the agile community where it doesn’t have an explicit practice. Some XP books explain the role, but mantras like “Big Design Up Front” and “Last Responsible Moment” are often (wrongly) interpreted as “do no architecture.” What I liked about Brown’s approach is his recognition of the Goldilocks approach – not too little and not too much where he provides both points of view and some concrete practices.

Brown covers important topics like quality attributes (Cross Functional Requirements), what the role of an Architect is (and that it is just a role, not necessarily a person). I am biased in the opinion but I enjoyed Brown’s perspective about whether or not architects should code, and it aligns well with my own point of view that for a Tech Lead (or Architect) to make effective decisions, they need to have empathy and understand (live, breath and sometime burn for) the decisions they make.

I appreciated the way that Brown puts “Constraints” and “Principles” as key factors that aren’t necessarily represented in the codebase and are unlikely to be easily discoverable for new people. Both are things that I have done when leading software teams and are things I would repeat because I find it helps people navigate and contribute to the codebase.

What I found slightly strange about the book

I believe the book is really strong but there were a few sections that seemed slightly out of place, or not yet completely finished. One was around the “Sharepoint projects needs architecture too”, which I don’t necessarily disagree with but could easily be extended to “Any software product extended to build an application needs architecture too” (cue s/Sharepoint/CMS/g or other examples).

Conclusion

Software Architecture for Developers is a very accessible, relevant and useful book that I do not have any problems recommending for people looking at how to effectively implement Software Architecture in today’s environment.

11 years at ThoughtWorks

April 15, 2015 / / 1 Comment

I had planned to write a 10 years at ThoughtWorks post but was busy on a sabbatical learning a real language (German!) This year, I decided to get around to writing an anniversary post. One of the current impressive employee benefits for long-time employees is a 12-week paid break (it’s mandatory law in Australia but not true around the world).

When I think about my time here at ThoughtWorks, I can’t believe that I have been here so long. I still remember, after graduating from University, thinking how unlikely I would stay with a company for more than two years because I wanted to learn, change and grow. I thought that would be difficult in a permanent position in any other company. I wanted to stay in the zone but also find an opportunity to do interesting work. Consulting proved to be a good middle ground for what I was looking for.

What a ride it has been. Oh, and it’s still going, too 🙂

Facts

Like most companies, ThoughtWorks has changed and evolved over time.

  • When I started, we had (I’m guessing) about 10 offices in four countries. As of this post, we have 30 offices in 12 countries (Australia, Brazil, Canada, China, Ecuador, Germany, India, Singapore, South Africa, Uganda, the United Kingdom, and the United States) in some places I would never have guessed we would have had offices.
  • When I started, we had maybe 500 employees worldwide. We now have around between 2500-3000 people.
  • When I started, we were pretty much a consulting firm doing software development projects. Since then we now have a product division, a highly integrated UX capability, and are influencing companies at the CxO level which means a different type of consulting (whilst still keeping to our core offering of delivering effective software solutions).

We don’t always get things right, but I do see ThoughtWorks takes risks. In doing so, that means trying things and being prepared to fail or succeed. Although we have grown, I have found it interesting to see how our culture remains, in some ways very consistent, but adapts to the local market cultures and constraints of where we are operating. When I have visited our Brazilian offices, I felt like it was TW but with a Brazilian flavour, likewise when I visit our German offices.

Observations

I find it constantly interesting talking to alumni or people who have never worked for ThoughtWorks to see what their perceptions are. With some alumni, they have a very fixed perception of what the company is like (based on their time with the company) and it’s interesting to contrast that view with my own, given that the company constantly changes.

We are still (at least here in the UK) mostly a consulting firm, and so some of the normal challenges with running a consulting business still apply, both from an operational perspective, and being a consultant out on the field. Working on client site often means travel, and still affected by the ebbs and flows of customer demand around client budgeting cycles.

Based on my own personal observations (YMMV) we, as a company, have got a lot better about leadership development and support (although there is always opportunity to improve). I also find that we tend, on average, to get more aligned clients and have opportunities to have a greater impact. We have become better at expressing our values (The Three Pillars) and finding clients where we can help them and they are ready for that help.

It is always hard to see colleagues move on as it means building new relationships but that is always a reality in all firms, and occurs often even more so in consulting firms. After coming back from sabbatical I had to deal with quite a bit of change. Our office had moved, a significant part of our management team had changed, and of course there were lots of new colleagues who I hadn’t met. At the same time, I was surprised to see how many long-time employees (and not just operational people) were still around and it was very comforting to reconnect with them and renew those relationships.

Highlights

I’ve been particularly proud of some of the impact and some of the opportunities I have had. Some of my personal highlights include:

  • Being the keynote speaker for the 2000-attendee Agile Brazil conference.
  • Publishing my first book, The Retrospective Handbook, a book that makes the agile retrospective practice even more effective.
  • Publishing my second book, Talking with Tech Leads, a book that collects the experiences of Tech Leads around the world aimed at helping new or existing Tech Leads improve their skills.
  • Developing a skills training course for Tech Leads that we run internally. It’s a unique experiential course aimed at raising awareness of and developing the skills developers need when they play the Architect or Tech Lead roles. I may even have an opportunity of running it externally this year.
  • Being considered a role model for how ThoughtWorks employees can have impact on both clients, the industry and within our own company.

Book Review: Waltzing with Bears

March 3, 2015 / / 0 Comments

I read this book very early in my career, and I thought it would be useful to read it again as a refresher to risk management. Waltzing with Bears is a book that focuses on the identification and management of risks within the software industry. It’s filled with a number of stories answering the question, “Why should we care about risk?” as well providing a number of strategies and tools for handling risk.

Waltzing with Bears

Although a lot of the advice is still applicable today, I think it is true that some of the recommendations are commonplace today. They recommend, for instance, an incremental delivery approach to software (Hello agile software development!) without a specific reference to a methodology as a way of mitigating risk.

They also present the idea of estimate (un)certainty and using the idea to make better commitments to others. They also warn against default behaviour that is still rife in our industry: e.g. making a commitment to others based on an optimistic estimate hoping for a series of breaks when it is clearly high risk, which later leads on to the project death march, or a huge loss of quality.

Reading the book the second time around, I picked up a few other interesting models I don’t remember so clearly from the first time around including the use of probability profiles (a graph that shows the shape of our estimates and the uncertainties) to understand when and where to give estimated dates. There’s a useful section around risk-storming for people who have never been to a risk brainstorming session, but that wasn’t particularly new for me. Another one is the use of the Monte Carlo simulation for calculating the impact of risks. After reading that section however, I feel like I still don’t fully understand it and I would need to practice applying it for me to fully understand how that works.

Although the examples used in the book are relatively old now, there are still powerful stories about how people failed to manage risk, what they could have done instead and what the consequences were (e.g. Dallas Airport Baggage system!) I also like their practical experience shared when they talk about the cultural side of risk (e.g. how transparent or open and organisation is) and when it’s dangerous to share your view of risk. This sort of advice is often missed from books where the authors provide a very one-sided dogmatic approach without the consideration of contexts.

Overall this is an easily digestible book that introduces the idea and the importance of managing risk together with tools to help you achieve it, all set in the software industry context.

Book Review: The Lean Enterprise

February 9, 2015 / / 1 Comment

This weekend I finished reading a copy of The Lean Enterprise by Jez Humble, Joanne Molesky and Barry O’Reilly.

Top level summary: If you want to learn about the truly agile organisation, this is the book that shows you what it looks like.

The Lean Enterprise

I have read many books about agile, lean and organisations that build software, but this is the first that really brings it all together. Other books tend to be either too theoretical (founded from either Drucker or Taiichi Ohno) or with a very practical toolkit in a very narrow domain.

This book is aimed at executives and managers or organisations – the people with the authority to change to change the system. We know from W. Edwards Deming:

A bad system will beat a good person every time.

Like a book that was actually test driven by real-life questions, it provides answers to questions executives and managers ask time and time again.

The book is packed with information and provides solutions to problems that organisations, doing agile software development, struggle with in other parts of their organisation. Better yet they offer many examples of companies who are doing it right, proving that it is not just theory and that it can be done in many ways. There are many great stories from many industries demonstrating how different approaches can be yet still exhibit the lean attitude and culture that is so essential to success. I am also glad how much the authors focus on the importance of culture (and what people can do about it) and not just a single focus on either theory or tools.

The authors have done their research well, with excellent, tangible examples of lean concepts, practices and tools linked to much more detailed reading in a referenced article, paper or book. I would almost buy this book only to give people the reading list in the back – it is really that good. I have read many of the books referenced, and I remember how they challenged and changed my thinking in a positive way. After this book, my own personal reading list is also much richer.

What makes this book especially stand out for me is the pragmatic nature of the book. Even though, to many readers, the contents may appear idealistic or too unrealistic, the authors have given many examples of companies doing it, refer to many case studies or experiences where they have seen the practices and principles at work and shown their own insights into the challenges or dangers that lie ahead. This last part speaks volumes to the authors sharing their experiences about the questions some organisations have not even asked yet and advice on how to solve it. One good example is the paradoxical nature of balancing exploration through prototyping (discovery) against the disciplined nature of continuous delivery (e.g. additional work of well refactored code, tests and scripted deployments).

When I got to the end of the book, I knew that I would need to re-read the book for a deeper understanding because it is so rich with concepts and tools – some I have not had the chance to try out.

A perfect match for the target audience it was written for and a book that will continue to be relevant for many years to come.

ThoughtWorks London Opening Party

February 6, 2015 / / 0 Comments

Last night ThoughtWorks had a welcoming party to celebrate the opening of our new London office, located in the heart of Soho.

I didn’t take as many photos I would have liked, but it was a fun event with a couple of musicians: Emily Lee, Scott McMahon and an amazing set of food prepared by Ed Baines (chef of Randall and Aubin).

Thoughts on OOP2015

February 4, 2015 / / 0 Comments

I spent the first half of last week in Munich, where I was speaking at OOP Conference 2015. I missed last year when Martin Fowler was a keynote but had presented both in 2013 and 2012.

The conference still seems to attract more seasoned people like architects and decision makers and I am still constantly surprised at the number of suits I see for a technical conference – I do not know if that is more of a German culture difference as well. I felt like there were significantly more German-speaking sessions than English ones, and I sat in a number of them when I expanded my vocabulary.

I was only there for three of the five days of the conference, and was lucky enough to be invited and attend a special dinner on Monday evening where Dr Reinhold Ewald (a former German astronaut) gave a presentation about what it was like being an astronaut, what they do in space and some of the interesting challenges.

I saw a number of the keynotes and talks which I’ll briefly summarise here:

  • Challenges and Opportunities for the Internet of Things (IoT) by Dr Annabel Nickels – A relatively introductory session on what the Internet of Things actually means. The talk explained the IoT well, why it’s not possible and what people are experimenting with. It was clear that security and privacy aspects had not advanced and that there was still a lot of work to go, as there were lots of questions from the audience, but no clear answers in this space – more “it’s something we’re looking into”-sort of answers
  • Coding Culture by Sven Peters – Sven is an entertaining, engaging and obviously well-practiced presenter who knows how to engage with the audience with pictures and stories. His talk focused on coding culture – but more particularly the coding culture of Atlassian, the company Sven works for. An entertaining talk about how they work inside the company, but was not particularly surprising for me since I know already a lot about that company.
  • Aktives Warten für Architekten by Stefan Toth (Actively Waiting for Architecture) – A nice introduction to the Last Responsible Moment or what is more popular in the Agile community these days, Real Options.
  • Ökonomie und Architektur als effektives Duo by Gernot Starke, Michael Mahlberg (Economics and Architecture as an effective pair) – From my understanding, the talk focused on bringing the idea of calculating ROI on an architectural front. The pair spent a lot of ideas introducing financial terms and then a number of spreadsheets with a lot of numbers. Although well-intentioned, I wasn’t sure about the “calculations” they made since a lot of it was based on estimates of “man-days” needed and “man-days” spent/saved – it all looks very good when calculated out, but they didn’t really spent much time eliciting how they get estimates. They spent a lot of time introducing Aim42 which I wasn’t familiar but will now look into.

I ran two talks that had both good attendance and great feedback (like the one below):

OOP2015 - Best Talk

The fist was “The Geek’s Guide to Leading Teams” where I focused on exploring the responsibilities and remits of what a Tech Lead does and how it’s quite different from being a developer.

The second was “Architecting for Continuous Delivery” which focused on the principles and considerations for when people build systems with Continuous Delivery in mind.

I had a great time visiting the conference and had an interesting time expanding my German vocabulary as I tried to explain what I and what my company do in German – something I didn’t really do a lot of when I was living in Berlin.

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 ↑