Operation Biting

 

This book details the planning and executing of Operation Biting by the UK during World War 2. The raid was conducted by the beginnings of the UK's special forces, and served two purposes: (1) To capture German radar equipment so as to ascertain how advanced it was and (2) to boost English morale at a time when they were facing repeated failures on the battlefield, including the surrender of Fortress Singapore to the Japanese.

The book shared that Special Forces here werent that elite, and alot of the operation's success seems to be due to luck and incompetence of the defenders, rather than the skill of the attackers. 

It was also interesting to learn more of individuals closely involved in this area such as Browning, which cant be learnt from their wikipedia pages. 

The book also shared on the conduct of other successful (Gran Sasso) and unsuccessful paratroop (Market Garden) missions and the factors that contributed to this outcome.

Lastly, many of the individuals in the mission did not survive the war, which only goes to show how tragic war is, something many of today's leaders do not grasp, given that we are headed towards a world with more conflict.

How To Win the Premier League

 

A fascinating read that explains to the reader the intricacies between football analytics. This is the book I have been looking for ever since coming across Moneyball, which revolutionized analytics in the sport of baseball.

The book uses a romantic story of how Liverpool used analytics to capture undervalued signings of Salah and Firmino to sell itself, but actually goes far beyond that, breaking down the use of stats throughout the field.

For starters, it delves into how analytics is used to break down the probabilities of goal scoring in different situations throughout the pitch. This alone would already be quite interesting, but stats can be used in all areas, and is extended to study player quality, value for money, tactics, off-the-ball movement and to top it off, managerial influence.

Stats are also used to study club finances, and finally the illustration of the wrong use of stats, which is an ever present danger of people looking to extract insight but end up going down the wrong alley.

The writer also issues a warning against individuals looking to beat the bookie, since the bookie has more resources than us. This is something i can attest to from personal experience as well.

A Friendly Guide to Software Development

Just finished this book by Leticia Portella.

Although I am not a developer, working in the IT industry means that i need to have a basic understanding of the working processes and terminology. While I would say I already know about 70-80% of the information, its presentation provides food for thought in organising my team/work and the simple explanations also provided some "oh so thats what it means" moments.

Crucially, the work of developers isnt just about developing, but there is a whole other ecosystem of work needed in order for the coding to happen. 

The key points i need to note relating to tracking and visibility of work, and making work better. Alot of points arent new, and it is heartening to know that we arent the only ones facing these issues!

1. Documentation is important for maintainability, including decision logs

2. Documentation also helps in versioning, which helps us roll back changes quickly

3. Tests should be written alongside development, similar to how they are tied to requirements

4. Incident management is intensive and stressful, and eats into project work.

5. Errors are unavoidable. Every crisis forces a re-examination of policies and practices

6. External and unpredicted work requires reprioritization, leading to fatigue, lower morale and context switching/ interrupted work

7. Communications is key. Consider making teams small enough using the Two Pizza Rule.

8. Glue work (admin such as setting up meetings, taking notes, onboarding) is also work. It should be visible and shared.

9. Good teams require psychological safety and not star players

10 . Managers should be available for their team, to be interrupted so that engineers can focus on their work. They also need to know how the team feels (likes/dislikes, feeling satisfied, learning wants)

11. Lastly, product managers, project managers, business specialists are all different roles!