The intersection of technology and leadership

12 years, 12 lessons working at ThoughtWorks

I’ve been at ThoughtWorks for 12 years. Who would have imagined? Instead of writing about my reflections on the past year, I thought I would do something different and post twelve key learnings and observations looking back over my career. I have chosen twelve, not because there are only twelve, but because it fits well with the theme of twelve years.

1. Tools don’t replace thinking

In my years of consulting and working with many organisations and managers I have seen a common approach to fixing problems, where a manager believes a tool will “solve” the given problem. This can be successful where a problem area is very well understood, unlikely to have many exceptions and everyone acts in the same manner. Unfortunately this doesn’t reflect many real-world problems.

Too many times I have witnessed managers implement an organisational-wide tool that is locked down to a specific way of working. The tool fails to solve the problem, and actually blocks real work from getting done. Tools should be there to aid, to help prevent known errors and to help us remember repeated tasks, not to replace thinking.

2. Agile “transformations” rarely work unless the management group understand its values

Many managers make the mistake that only the people close to the work need to “adopt agile” when other parts of the organisation need to change at the same time. Co-ordinating this in enterprises takes a lot of time and skill with a focus on synchronising change at different levels of the organisation.

Organisations who adopt agile in only one part of their organisation face a real threat. As the old saying goes, “Change your organisation, or change your organisation.”

3. Safety is required for learning

Learning necessitates the making of mistakes. In the Dreyfus model, this means that particularly people in an Advanced Beginner stage, need to make mistakes in order to learn. People won’t risk making mistakes if they feel they will do a bad job, lose respect from their colleagues or potentially hurt other people in that process.

As a person passionate about teaching and learning, I find ways to create a safe space for people to fail, and in doing so, make the essential mistakes they need to properly learn.

4. Everyone can be a leader

I have written about this topic before, but it is such an important observation. I see a common mental model trap where people feel the need to be given the role of a leader, in order to act like a leader. People can demonstrate acts of leadership regardless of their title and can do so in many different ways, simply by taking action on something without the explicit expectation or request for it.

5. Architects make the best decisions when they code

In the Tech Lead courses I run, I advocate for Tech Leads to spend at least 30% of their time coding. Spending time with the code helps build trust, respect and a current understanding of the system. Making architectural decisions without regard for the constraints of the current system are often bad decisions.

6. Courage is required for change

I miss people talking about the XP values, one of which includes Courage. Courage is required for acts of leadership, taking on the risk to fail and the risk/reward of attempting something new. Where there is no risk, there is often little reward.

7. Congruence is essential for building trust

Beware of the old age maxim, “Do as I say, not as a I do.” In reality, regardless of what you say, people will remember how you act, first and foremost. Acting congruently is making sure that your actions follow your words. Acting incongruently destroys trust. Saying “no” or “not now” is better than promising to do something by a certain time, only to not deliver it.

8. Successful pair programming correlates with good collaboration

Although not all pair programming environments are healthy, I do believe that when it works well, teams tend to have better collaborative cultures. Many developers prefer the anti-pattern of (long lived) branch-based development because it defers feedback and sources of potential conflict.

I consider (navigable) conflict a healthy sign of collaborative teams. Deferring feedback, such as is the case with code reviews on long-lived branches tends to lead to more resentment because it is delivered so late.

9. Multi model thinking leads to more powerful outcomes

One of my favourite subjects at University, was Introduction to Philosophy where we spent each week in the semester studying a different philosopher. Over the course of my career, I have come to appreciate the value of diversity, and to see a problem through multiple lenses. Systems thinking also recognises that facts can be interpreted in different ways, leading to newer ideas or solutions which may be combined for greater effect.

10. Appreciate that everyone has different strengths

Everyone is unique, each with their own set of strengths and weaknesses. Although we tend to seek like-minded people, teams are better off with a broader set of strengths. A strength in one area may be a weakness in a certain context, and teams are stronger when they have a broader set of strengths. Differences in strengths can lead to conflict but healthy teams appreciate the differences that people bring, rather than resent people for them.

11. Learning is a lifelong skill

The world constantly changes around us and there are always opportunities to learn some new skill, technique or tool. We can even learn to get better at learning and there are many books like Apprenticeship Patterns and The First 20 Hours which can give you techniques to get better at this.

12. Happiness occurs through positive impact

The well known book, Drive, talks about how people develop happiness through working towards a certain purpose. In my experience, this is often about helping people find ways to have a positive impact on others, which is why our Pillar 2 (Champion software excellence and revolutionize the IT industry) and Pillar 3 (Advocate passionately for social and economic justice) values are really important for us.

Conclusion

The twelve points above are not the only lessons I have learned in my time at ThoughtWorks but they are some of the more key learnings that help me help our clients.

12 Comments

  1. Franz

    I don’t really understands the opposition of pair programming and branch based development. And the fact that branch based may delay feedback you can give feedback on an ongoing branch. Can you develop in that?

  2. Aristotle

    Good read.

  3. Thibault Delor

    Agreed with @Franz Everything makes sense to me except this sentence “Many developers prefer the anti-pattern of (long lived) branch-based development because it defers feedback and sources of potential conflict.”

    First I don’t like people suddenly declaring a well established practice as ” an anti pattern”. Then you can argue against it in some context, it’s not a silver bullet, but it’s almost unavoidable when for example you are maintaining several version of your software.
    I was really enjoying this article but I stopped reading after that, sorry…

  4. Patrick

    Thanks for leaving comments @Franz, @Aristotle and @Thibault. It’s a useful discussion. We have many clients who work with long-lived branches. Where those are individuals working on feature branches, you can do code reviews on those branches, but often they end up performed at the end of the branch (hence, lots of delayed feedback). I see many examples where developers, who have invested lots of time in their code, feel frustrated some of that feedback was not done earlier, and they become resistant to actually implementing those changes.

    @Fritz – Where done well, you can do continuous reviews on a branch but in practice, I see it more commonly done just before the merge (when it is quite late). Pair programming or continuous code reviews on the branch can solve some of those issues, but not all…

    Long-lived branches often result in large merge conflicts (depending on how large the development team is, and how fast moving the code or active development there is). Large merge conflicts potentially introduce bugs and wastes excess time, and is what Continuous Integration (the practice, not a tool) was intended to solve.

    @Thibault Thanks for making it to #8! In some situations, yes, you may need to maintain several versions of your software (and have branches that represent each of them). For me, it’s important that teams don’t unnecessarily maintain too many branches because we all know the pain of having to merge across branches. The longer each one lives and the more divergent, the harder it will be – hence the idea of Continuous Integration as a practice.

  5. Carlos Costa

    Nice article, thanks for share 🙂

  6. johnlewis2013

    Good article – systems thinking is very powerful and I am a great fan of pair programming and lifelong learning – I am 62 learning Scala (not too bad because i grew up on Simula and Lisp (Flavors)). Here are my 12 points (rules) on Project Management – http://wp.me/p3U0tf-29 – things I have learnt.

  7. Paulo Caroli

    Great article Pat!
    Thanks for sharing.
    It is very inspiring.
    I will start thinking about my top 10 for my 10 year anniversary.

  8. Dzung

    Branch base can be suitable for feature base project with very experienced developers who can develop a whole feature independently.

  9. Daniele Pozzobon

    One question about Agile Transformations.
    It looks like you have seen a lot of cases where the Pointy haired Management imposes Agile Procedures on their teams (because someone sold them on faster and cheaper development) without understanding it’s real value and meaning.
    My question is if you have ever seen an agile transformation starting from the bottom: where the developers start to organize their job in an agile way and this mentality gets absorbed by the Management that notices the actual advantages of the mental shift.

  10. Patrick

    Hi Daniele,

    Sorry for getting back to you so late. I have seen what you talk about where a team start to organise their job in an agile way. Where management notice it depends on multiple things: how strong the relationship between the team is and managers, and also how influential those managers are at changing the systemm. Where the company is small, managers tend to have more influence and can successfully transition if they have the mindshift. In my experience, this doesn’t happen *fully* organically – in that someone needs to work with the management group to help them understand the values. Hope that answers your question!

  11. Marco B.

    I really enjoyed reading this post. In general I think that a lot of points can be summarized to “positive attitude towards life”. And this is typical of a curious humble learner – someone who is not afraid to fail, because “that’s life, and failure will eventually produce success”, while at the same time “I can and I will do better next time, thanks to my mistakes”.

    Just to quote the one of the biggest examples of “positive attitude”:

    > As an inventor, Edison made 1,000 unsuccessful attempts at inventing the light bulb. When a reporter asked, “How did it feel to fail 1,000 times?” Edison replied, “I didn’t fail 1,000 times. The light bulb was an invention with 1,000 steps.”

  12. Vikram Shetty

    Good read, It is nice to see some engaging employee talks about his employer. It is nice to see you grow technically and appreciate the leanings you have found.

    I loved the long haul that you still enjoy.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2024 patkua@work

Theme by Anders NorenUp ↑