Tribal Leadership by Dave Logan et al. (Book Review)

Tribal Leadership:
Leveraging Natural Groups to Build a Thriving Organization
by Dave Logan

My rating: 5 of 5 stars

So, the story goes that our CEO, Jost Stollmann, asked Mike Cannon-Brookes, co-founder & co-CEO of Atlassian and one of Tyro’s board members, something along the lines of…

“If you had to recommend just one book to your leadership team, what would you choose?”

And Mike recommended: Tribal Leadership. I think I can see why.

What’s the book about?

The book is about the results of ten years of research by the authors and how they found that people in organisations form tribes; that each tribe has a prevailing culture; that the cultures can be roughly grouped into five different levels; that the culture of the tribe can be an indicator of organisational success; and that the culture of individuals and of tribes can be “upgraded” through the levels using actions they describe, undertaken by tribal leaders. (Note that it’s not about leaders trying to create tribes in order to succeed – the tribes are a natural phenomenon, and the benefit comes through recognising them and influencing them. It does talk about building and enhancing networks within tribes.)

The book is well-written (i.e. not boring), contains lots of case studies and interviews, has excellent summaries at the end of each chapter (no highlighting necessary!), and it doesn’t just focus on what to do to become “great” – it also covers basket case cultures and how to start progressing people out of there.

What did I like about the book?

The number one thing I like about this book, as a leadership book, is that it pretty quickly gets a thoughtful reader looking not merely at their own actions and what they can do to improve, but also at how the people around them in the organisation are acting and interacting. You start to think about how to improve the company by influencing the culture, not just about how to improve your own output and your team’s output by doing a few things differently.

The main premise of the book is pretty simple to understand and start putting into practise: people’s culture can be detected by the language they use, and also affected by the language those around them use. So, people in Stage 3 tribes (where most corporate cultures are at) are all about personal accomplishment and they’ll say a lot of things that basically translate to “I’m great”. In contrast, people at Stage 4 are all about forming and maintaining good working partnerships with people around them, and their language will come out as “We’re great”.

As soon as I started reading all this, I could see how problems which I’d observed at work were caused by the behaviours detailed in the book. I also started to see problems I hadn’t noticed before, or areas that were about to be problems, based simply on how people were talking to each other or about each other. I recognised in myself some things I’d been doing which were contributing to holding the culture back from where it could be.

The book has many examples of great companies to aspire to, and not just the ones you’re used to reading about. Yes, there’s analysis of raging startup successes like Zappos, but there’s also a lot of time spent describing a hospital that focuses on creating excellent customer experiences.

The book has great advice, much of which is easy to start following, and it changed the way I behave, even as I was reading it.

Should you read it?

If you’re in any kind of leadership position, in any kind of organisation, I highly recommend this book. Maybe it won’t change your world, and you may not have all the influence you would need in order to affect the whole organisation. At the very least it should help you to start seeing the culture around you for what it is, and start to move it forward from the position you’re in.

Buy it on Amazon

View all my reviews

Book Recommendations from Sydney Technology Leaders

Last week I went to the Sydney Technology Leaders’ Meetup, which we hosted in the Tyro Fintech Hub. There was a trio of great talks, and a panel discussion with the speakers at the end.

When asked what they do to help train new leaders, one of the speakers mentioned “throwing a bunch of books at them”. So I took the opportunity to ask the speakers, if they could only recommend one or two books to a new leader, what would each of them recommend. Continue reading

Notes from YOW! 2014: Simon Brown on ‘Agility and the Essence of Software Architecture’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Simon Brown (@simonbrown) spoke on “Agility and the essence of software architecture”. (Slides, Video)

He started with a great Dave Thomas quote:

“Big design up front is dumb.
No design up from is even dumber.”

Whiteboard covered in a circuit diagram, which looks pretty similar to a typical software architectureSoftware Architecture Agility

He went on to tell us…

Delivering software in an agile way doesn’t guarantee that you’ll develop an agile architecture.

A good architecture enables agility.

He asked “Are monolithic architectures agile?” and proposed the answer, “Well, they could be. Just because you have to deploy it all at once doesn’t mean it’s not agile.”

Which naturally lead into a discussion of what does agility mean? Continue reading

Notes from YOW! 2014: From Monoliths to Microservices at REA

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Microservices at REA (Real Estate Australia)Beth Skurrie (@bethesque) from DiUS, Evan Bottcher (@evanbottcher) from Thoughtworks and Jon Eaves (@joneaves) from REA group spoke about migrating realestate.com.au to a microservices architecture. (Slides, Video)

Why REA migrated to microservices

They started by talking about why they started doing microservices:

  • They had a long release cycle,
  • they were doing coupled releases,
  • with coupled rollbacks,
  • and they had a long defect fix time.

How do you get self-empowered teams to change the whole architecture?

However, there was a realisation that changing things at REA is a bit hard, partly because the teams are very self-empowered, they’re trusted, and they value their independence.

In order to convince teams that trying a new architecture was a good idea, they came up with a vision of where they wanted to go, which included: Continue reading

Notes from YOW! 2014: Mary Poppendieck on ‘The (Agile) Scaling Dilemma’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Lots of empty seats at a stadium. Can Agile scale to this kind of crowd?Mary Poppendieck (@mpoppendieck) spoke about scaling agile teams. (Slides)

She started by saying:

“There’s a big assumption that if agile is good, scaling agile must be good.”

Which made my jaw drop. I make that assumption. It had never occurred to me. Maybe agile techniques don’t work in a larger organisation?

She talked about four constraints on scaling: system complexity, organisational mindset, multi-team communication, and the time and energy of bright creative people. Continue reading

Notes from YOW! 2014: Jeff Patton on ‘User Story Mapping: Discover the Whole Story’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Jeff Patton (@jeffpatton) was billed to present a “fast paced workshop [where] you’ll learn the concepts of story mapping by building a map collaboratively with others”. He shared lots of great insights about stories but (I felt) really only touched on Story Mapping briefly near the end of the time. Still, I collected some good notes about stories that made me re-think a few things…

He started by showing this great list of wrong things he used to think about stories. Stupid stuff Jeff Patton used to belive about Agile stories Continue reading

Notes from YOW! 2013: Michael T. Nygard on ‘Five Years of DevOps: Where are we Now?’

I attended Day 1 of YOW! Sydney 2013 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Small child in a field looking into the distance with binoculars, as someone surveying the current state of DevOps probably wouldn't do.Michael T. Nygard (@mtnygard) is probably best known as the author of the 2007 book ‘Release It!‘, which teaches developers how to look beyond just getting their code working and instead design it from the outset to handle the harsh conditions of production environments. He has since become a DevOps luminary and now works at Cognitect. He spoke at YOW! 2013 about ‘Five Years of DevOps: Where are we Now?’.

Michael started off setting the timeline by pointing out that Chef and Puppet were preceded by CFEngine in about 1993!

He explained how his own experience has contributed to his DevOps insight: he worked as a Dev in Ops for some time, showing the Ops team how to solve some of their problems with Dev-like approaches, but also finding lots of problems with the way Devs created software, which was the chief inspiration for his book. Continue reading

Notes from YOW! 2013: Jeff Paton on ‘Safety Not Guaranteed: How Successful (Agile) Teams Ignore the Rules to Create Successful Products’

I attended Day 1 of YOW! Sydney 2013 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Two people dressed as crash test dummies with their thumbs up. Does following Agile processes to the letter mean your team will be safe and succeed?Jeff Paton (@jeffpaton) is an independent consultant, teacher and Agile coach, and (I believe someone said) the inventor of Story Mapping. He spoke at YOW! about ‘Safety Not Guaranteed: How Successful Teams Ignore the Rules to Create Successful Products’.

Jeff started his talk by announcing that he hated agile development since the moment he first heard of it, but went on to explain that he doesn’t really hate agile now and that an important part of this has been to learn to pay a lot of attention to what he’s doing. Continue reading

10 Reasons You Shouldn’t Have Senior Developers, Tech Leads or Architects

Two weeks ago I published a post titled ‘Why Smart Software Teams Don’t Need Senior Developers, Tech Leads or Architects‘. I received a lot of good feedback, but I also know it was a long read. So, if you’re interested by the title but are looking for a quick brain dump rather than an enjoyable read, here’s the abridged version:

At Tyro Payments, we’ve doubled our Engineering team over the last year.

We don’t hire for, or use, titles like Graduate Developer, Junior Developer, Senior Developer, Tech Lead or Architect. Everyone has the title ‘Software Engineer’.

This is an important part of Tyro’s Engineering team culture. Here are the reasons… Continue reading

Why Smart Software Teams Don’t Need Senior Developers, Tech Leads or Architects

Queue for Steve Jobs' keynote at WWDC 2010

A queue of software developers, not unlike the one that has inundated my inbox for the last year.

We’ve almost doubled our Engineering team at Tyro Payments over the last financial year and we’ll be adding that many again this year.

Most people who’ve worked in or with software teams would imagine that within this surge of hiring we’ve been filling all kinds of different roles – Graduate Developers, Junior Developers, Seniors, a couple of Tech Leads, maybe an Architect. But the truth is we’ve only been hiring for one role: Software Engineer. In fact, it’s the only development role on our team, and it’s the title we give to everyone on the tools, whether they have 20 years’ experience or none. This isn’t just some convenience we came up with to save ourselves HR work. It’s an incredibly important part of the culture at Tyro. Why? Continue reading