I’ve had this book for a while and it finally reached the top of my Audible list. Measure What Matters has intrigued me for a while, especially as I am focusing on setting and meeting goals at the moment.
I have to confess to being a little disappointed. At it’s core the book discusses OKRs, a kind of public goal which does a very nice job of splitting out the goal and the actionable tasks required to complete it. Visibility creates transparency to make sure no teams are duplicating effort or conflicting priorities, they also allow people to assist each other in meeting their goals.
So far so good, I didn’t have a problem with any of that.
However, the majority of the book was a list of testamonials from the author’s long list of supporters. It was genuinely interesting to see how the technique has been applied to everything from IBM to U2. But I’m really not sure wheeling out the famous and successful was really needed (in the audiobook many of them actually contributed their parts). It felt more like a sales pitch of OKRs rather than a practical guide of implementing them.
I kept finding myself expecting the next chapter to be a “How to get started with OKRs in your business.” but alas, it never came.
Enlightening by adding a new way to think about goals, however disappointing because although I’m intrigued I feel far from equipped to take advantage of the concept.
Do you agree? Have you read Measure What Matters? What did you think?
I recently finished Algorithms To Live By, a book by Brian Christian and Tom Griffiths. I’ve been putting off this book for a while (I’m not sure why) but after reading a few positive reviews I fired up Audible and listened to it.
The book opened extremely well. I wasn’t entirely sure what optimised stopping was. What the authors do incredibly well is take computer science concepts and apply them to real life problems. In that case when to offer a candidate a position or when to say no and hope for someone better (the secretary problem) or when to opt for the empty parking space and when to carry on and hope for one closer to your destination.
There were interesting chapters on sorting and searching (football games league and organising books), Game Theory (employees at companies with unlimited holidays), and scheduling.
While extremely interesting what it lacked was… how do I say this… a lot of of take away value. I felt there was so much interesting stuff in there, but I’d have loved to have some really clearly spelled out takeaways. I think there’s still a jump to be able to take what the authors talked about and apply it to day to day life in any more than the lightest way. A great read, but perhaps not as paradigm shifting as I’d hoped.
I recently read Eat That Frog, a personal productivity guide by Brian Tracy.
It’s an interesting book. There are 21 easy simple tips which work together, I especially like the format because it’s easy to dip in and out of. Some of the suggestions are very very good. Putting technology aside, breaking big goals into smaller steps, and making sure highest priority tasks are identified.
Brian Tracy makes a huge point of picking up the most important task for the day at the very beginning. Personally I’m not a fan of this approach (as long as it’s identified and gets done). But I can see the wisdom in it.
Would I recommend Eat That Frog? If you’ve not ready many personal productivity books before and are looking for a few tips to help you organise things and deliver – sure, there’s probably quite a lot in there you’ll like. If you’re not new to the genre then you probably won’t get a huge amount of new advice from the book.
Atomic Habits is a different book, more granular and if you’re interested in personal productivity then it’s a good read.
In the book James first sells the value of habits, discussing how small incremental changes each day are vital to achieving major results. Then he moves on to deconstruct the various parts of a habit including Cue, Crave, Response, Satisfaction. In other words something triggers our habit, then we develop a craving for something, we act in a pre-trained way to satisfy that craving, and gain satisfaction.
In a positive habit this may look like:
Every morning when I get up
I want to clear my head
So I meditate
And feel better afterwards
However, in a negative habit this could be:
When I’m bored
I crave entertainment
So I open social media
Which entertains me
James then talks about how to hack these habits by eliminating cues, changing rewards, and building commitments so the habits you do want to form stick and the ones you don’t are broken. It’s good, sensible stuff.
As I mentioned above there’s a LOT of crossover with Routine Machine, however Atomic Habits goes far more into the techniques for forming and breaking daily habits. In his book Mark Lamberton focuses on how to point these in the direction to achieve big things. I see the two books as a very valuable pairing because, if I was to raise a criticism with Atomic Habits there’s not enough pagespace dedicated to creating structure so habits point you towards your longer term goals (although the idea of reinforcing identity is a very good one – see “Habit 2” of 7 Habits of Highly Effective People).
I listed my 2021 goals in an earlier post and I think there’s lots that can help me here. Specifically I want to work on the cues and immediate satisfaction of my reading, writing, and blogging. Perhaps putting together a calendar so it’s very obvious which days/weeks I’ve missed.
Have you read Atomic Habits? What did you think of it and have you encorporated any of it’s advice into your daily routines?
When I saw a copy of The Advantage on the shelf at the airport I picked it up straight away. I read Five Dysfunctions of a Team a few years ago and considered it leadership gold. Learning about organisational health from the same author, sign me up!
I’m disappointed to say that for me, The Advantage just didn’t hit the same high notes. Despite only being 216 pages the book took me around eighteen months to complete and that’s simply because I wasn’t engaged and I felt I had to force myself through the final few sections.
The early part of the book recovers a lot of the same ground as Dysfunctions, I have no problem with that. Creating a leadership team who feel safe and can operate together as a team is no doubt a key part. Then we moved onto organisational values, both desired and acididental. I found that part quite interesting but when we moved onto creating and reinforcing clarity I drifted and drifted.
It’s quite possible I missed the point, the book is highly rated on Goodreads so many people have clearly got a lot from it. Unfortunately, this won’t be one I pick up and re-read again in a hurry. I will however go away and try to define my teams’ values – I grant, that’s a very valuable exercise!
Have you read The Advantage? Do you disagree with me? Let me know either on Twitter or in the comments, I’m always happy for someone to point out something I’ve missed!
This morning I finished listening to Routine Machine on audible. The book is by John Lamberton, who describes himself as The King of Routine and in it he discusses the power of a good routine and how it helps him (and many others) achieve financial suggess and good health.
I’d highly recommend it. There are some really good ideas in there and it really gets you thinking about long terms goals and the small steps we take each day (how agile is that) towards achieving them.
Of course the book isn’t perfect, there are a few ideas and comments I really don’t like. Especially around the Director or Investor of any company locking himself away for a week to write a book and ignoring all emails and messages of people who work for him who require help with emergencies. I take John’s point on board – that he shouldn’t be a bottleneck and that these emergencies often don’t actually need his help. But I can’t help thinking that he and Simon Sinek would have a very heated debate on that one!
However, there was so much I did find valuable that I’d recommend you read it to. Here are my highlights:
Big goals aren’t achieved by a few big actions, we achieve them by doing lots of good little actions day after day, week after week, year after year.
The biggest asset you have to achieving success is time, don’t expect success overnight – aim for it and embed the habits you need to make it happen into your daily routine.
Track these habits in an excel spreadsheet (other spreadsheets are available) and give yourself gold stickers to ensure that they are sticking.
Don’t bite off too much too soon.
Don’t read books without taking the message way. Read the book, follow the instructions.
Identify what’s important and make sure you schedule time for those things first. Put the big immovable objects in your calendar first, not the day to day 30 minute meetings we’re all a slave to.
Although John told me to write a review I don’t want to share all the advice (because second hand is never as good as the source). Instead, if I’ve peaked your interest then grab a copy and have a read.
I was recently talking with a colleague I respect greatly about personal organisation. He said he’s a great believer in the GTD method. I raised an eyebrow, it sounded like some kind of car maintenance routine. But, when someone who seems to always have his eye on any number of spinning plates throws three letters in your direction I find it’s a good idea to listen.
As a developer I’ve grown up with scrum and kanban. When I moved into management I started creating ToDo lists but no matter how hard I try they always seem to fall out of date. David Allen’s book, although fairly exhaustive really opened my eyes to a better way of working.
I don’t want to go into too much detail on the GTD methodology, there are far better resources out there and the book itself is very comprehensive. However, there a few nuggets in there which are too good not to share.
The first revelation for me was that your inbox is not your ToDo list. It’s a capture tool, used for recording every commitment you make and idea you have. Allen’s approach is to frequently empty your inbox by actioning, scheduling, or delegating tasks. The same principle applies to an email inbox. Don’t let it build up, move items out into Archive or Action Required folder so you’re not digging through thousands of messages for the ones you need.
The other ideas I liked were the concept of Agenda projects to keep track of topics to cover in specific meetings and using a Waiting folder for work you are tracking but have been delegated to other people.
Hopefully this has given you a taster. If, like me you find actions slipping through the cracks or found time wasted while you were looking for the next task I’d highly recommend the book.
It’s quite iterative, the first couple of chapters contain most of the secrets. These are then expanded upon and developed in subsequent pages. It’s also very… almost technology phobic. I appreciate that the methodology should be tech agnostic, something you can do with a pen, paper, and a few folders. But in this digital first world I’d have started with a technological approach. However, the Todoist post I shared above gives a very practical guide of how to implement it using their (frankly outstanding) software.
I recently listened to the audiobook version of Matt Skelton and Manuel Pais’ book Team Topologies. It was so good I bought the kindle version while I was still halfway so I could make notes and highlight the good bits (most of the book it turns out).
The book takes several principals such as Conway’s Law and really applies them to business teams. This is something I’ve seen first hand. When several teams work on one large product the codebase becomes decoupled if the teams are given ownership of particular components. However, if teams are expected to work across the codebase the solution becomes monolith and the teams become a super squad.
In the book the authors argue that there are actually a very limited number of team types in a modern organisation. I don’t want to list them because I’d strongly recommend you to buy the book and read the descriptions for yourself. However, if the various types it was the concept of platform team which intrigued me the most.
I actually think Matt and Manuel underplay the huge value of a platform team. They discuss brilliant ideas about consumable APIs and documentation for product teams which consume them. However, a data driven business like mine I believe we should run far more platform teams and far fewer product teams. If we want our Product Owners to be able to innovate and prove the value of ideas quickly we need our data sources and components to be as plug and play as possible. This allows any product or concept to be built and tested very quickly. If all these services were owned and managed by platform teams, instead of falling down the gaps between product teams the solutions would be more robust and the lead times far lower.
If you’ve never given any thought to how teams are created and assigned areas of ownership then this is a brilliant book to read. If you’re not sure how your teams communicate and share information then this book is essential.
When I first heard about The Unicorn Project I have to admit I was disappointed, I’ve long been a evangelist for Gene Kim’s book The Phoenix Project but I’d just spent months working on my own development DevOps book, Code Black.
I shouldn’t have worried, I really enjoyed The Unicorn Project and we’d gone down different angles. Where I’d focused more on the Continuous Deployment journey Kim’s book focuses much more on developer empowerment and continuous experimentation.
The story follows Maxine, the developer who caused the now legendary payroll outage at Parts Unlimited towards the start of The Phoenix Project. Exiled to the documentation team as punishment she’s instructed to support the Phoenix rollout but quickly realised how woefully under supported the engineering teams are. As the business piles on more and more pressure, expects more features, and has less and less appreciation for the technical debt they’re wracking up they continue. Until, as we know the entire project explodes.
Working with some familiar characters such as Bill, Brent, Erik, and Maggie and a few new ones including Cranky Dave and Kurt our heroine works to make life better for the entire company. These are the engineers, the red-shirts, not the bridge crew. They’re the ones who actually do the work and they’ve got a lot of it to do!
What did I like best? Kim put lots of emphasis on testing and improving the entire system not just a small part of it, he focuses on collaboration and the importance of making it easy to onboard developers and share knowledge, and really drives the need to innovate and out experiment the competition. He also emphasis the importance of treating engineering tools as important systems and draws distinctions between the IT products we build, and the miscellaneous ones which just keep the lights on.
What wasn’t so good? Within a few chapters I was absolutely sick of Erik’s use of the word “sensei”… seriously can’t some of the people he quotes simply be experts, evangelists, or even gurus!?
On a more practical point the book spends a lot of time evangelising functional programming and scalability technologies. Which is great, they’re very powerful tools. But one of the things I liked so much about The Phoenix Project was how it was clear the team were struggling the same tech debt we all are. It made it more relatable and I worry in this book Kim’s “rip it out and use the latest and greatest” will overpower his more generic messages of continuous incremental improvement. Perhaps it’s personal preference but I like my DevOps books technology agnostic.
So, would I recommend this book? Absolutely without question! I believe that The Unicorn Project will take its place alongside its elder sister on the bookshelves of developers, testers, managers, product owners, and operational engineers for the next decade. If you haven’t already go and buy it, any while you’re at it not get a copy of Code Black too!? 🤣
I’ve been posting a lot about communication and safety recently and I want to give credit to the book which kickstarted my renewed interest.
Crucial Conversations is by Kerry Patterson, Joseph Grenny, and Ron Mcmillan. In the opening chapters the authors explain that a crucial conversation is any exchange where the stakes are high and emotions are running rampant. They describe how avoiding these conversations or handling them badly can leave lasting repercussions on our wellbeing.
Over the following chapters they describe how to recognise safety, how to reinforce it, and how to reach a positive outcome. It’s really strong stuff, in fact I’ve incorporated many of their ideas in my own style and recent talks.
The book isn’t targeted to a work environment, in fact many of the examples are close to home and personal scenarios. Asking for a raise or disagreeing with someone over a design choice will seem like small fry compared to some of the issues the characters in the book face.
However, I believe strongly that by using these techniques teams can communicate more effectively. By using some of the ideas Kerry and his fellow authors use to monitor safety in a conversation we’ll have better retros, planning sessions, and general collaboration.
If you’ve not read it then I strongly suggest you pick up a copy – it’s one of the few books I’ve rated 5* this year.