I was expecting lots of information about giving feedback but I was pleasantly surprised that there was a lot more in there than that.
Scott discusses that to be great leaders and team members we must both care personally and challenge directly. Without these two qualities we fall into one of three other quadrants.
People who care but don’t challenge fall into Ruinous Empathy. These are the people who won’t tell a friend that they’re unzipped because they’re afraid of the conversation. They’d rather let their friend continue to embaress themselves rather than push themselves out of their comfort zone.
People who don’t care personally are split into one of two categories. If they do challenge but don’t do it with someone elses best interests at heart then they display obnoxious agression. Or, simply put are just jerks. If they don’t challenge then they see what they could do to improve and don’t do anything to help them. This is manimulative insincerity.
Scott teaches us that we must always strive to give direct feedback to people we work with because we care about their success and their feelings. She also discusses lots of ways to do that.
I’d been expecting much of this content before I started the book but what delighted me was the actionable advice on how to go about this. I want you to read (or listen) to the book so I won’t give it all away here (plus, you know, plagurism). Suffice it to say that if you do now feel you should give feedback there are lots of tips in there to help.
But this is just for managers right?
Kim discusses that everyone should feel they can give feedback. Peer feedback is one of the most valuable thing we can give, it shows we care about our colleagues.
So, would I recommend it. Absolutely – go and have a read. Stop being ruinously empathetic today and start supporting your friends and colleagues directly!
I recently read Waltzing With Bears by Tom DeMarco and Timothy Lister, these are the same guys who wrote Peopleware so I was curious to give it a read as I found Peopleware useful, if a little dry.
Waltzing with Bears is all about managing software risk. Specifically the risk that something will not be delivered on time. The example the pair give early in the book is an airport which couldn’t open because the software to operate the baggage carousel wasn’t working. A late software delivery had huge financial impact.
In the book the authors talk about different ways to identify, represent, and manage risk. Like their other book Peopleware Waltzing with Bears is very comprehensive walk through of software risk covering a lot of the basics as well as some really interesting topics such as how to show delivery dates in a graph format to show the earliest possible, most likely, and worst case delivery dates. Thereby giving far more context than a best guess (which as we all know has a bad habit of being communicated to clients and becoming a deadline).
The authors made a very nice point about the bold being the ones who start projects early, not the ones who set ambitious deadlines and expect people to hit them.
However, I couldn’t help feeling like the authors were missing a big piece. The entire book (which I admit isn’t a long one) is based around delivery date risk. There’s no mention of many of the other risks which software teams face including usability, tech debt, and the ever present security risks. I would have liked to have seen more (well, any) pages dedicated to risks which aren’t about the due date. I felt like we were given a comprehensive introduction, but at the expnense of a breadth of knowledge of how to manage other risks.
Overall a good book which is well worth a read to anyone getting started in project planning and wants to understand how to manage the risk deliveries will run late. However, only a 4* read for me.
What do you think? Have you read Waltzing with Bears? Post your comments below!
Over the last year I’ve invested time in trialing and adopting apps which help my productivity. In this post I’m going to share them and explain why I believe they’re invaluable.
Todoist is an easy to use and intuitive TODO list application which supports projects, due dates, reminders, tags, and filters. It’s easy to use and syncs effortlessly across devices. I use it for everything from management work projects to keeping track of shopping lists and birthday presents.
The premium version unlocks additional features and it is well worth the money.
However, be aware downloading Todoist is enough to organise yourself. No tool can do that if you don’t have a system in place. I strongly recommend having a look at
Forest is an app which encourages you to put down your phone. I’ve written about it before and continue to use it. You can set how much time you’d like to “lock” your phone for and if you pick up before then your tree will die. Planning trees leads to gold which you can use to purchase more tree designs in the store or even plant trees in real life!
I started using this app this week and I’m really impressed. The premise is incredibly simple, the app records a quick message and then emails the text to the email address of your choice. Install on your watch and configure to the email of your Todoist inbox for a really effective way to record notes wherever you are and drop them right into your digital in tray!
Again, Audible shouldn’t be a surpise to anyone who’s read some of my recent blog posts. Listen to audiobooks while you’re driving or doing housework for a really effective way to consume books you wouldn’t ordinary have time to read. Especially if you practice building up your speed until you can listen in hamster mode!
And A Setting for Luck
Chances are your phone has a time limiter built in already, configure this to limit access to those time sync apps to 30 minutes each day. Being asked if you really want to spend your fourth hour on Facebook (or social network of choice) really is a great way to get you off your phone!
What are your favourite productivity apps? Do you use any which aren’t on my list?
This is a question I hear a lot, people have heard of (or may follow) Scrum and often have read about DevOps. They want to know whether DevOps is a replacement for Scrum or if it’s something they should be doing as well. Others believe that Scrum and DevOps are incompatible, in this post I want to talk about what both of these are how (because spoilers – they can) they should be used together.
What Is Scrum?
Lets start with the obvious question, if we’re going to discuss how DevOps and Scrum interact we need to define what exactly what we mean.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
The Scrum Guide
The Scrum Guide is an extremely concise and valuable guide to Scrum. If you haven’t read it I strongly recommend you do. However, for the purpose of this post I’m going to to highlight a few points.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
Various Sections of The Scrum Guide 2020
When many people think of Scrum they discuss the Scrum Events, these include Sprints, Retros, Planning Sessions, and Sprint Reviews. However, equal importance should be given to the underlying theory of empiricism and incremental nature.
Each Scrum Team should deliver at least one increment of work each Sprint, this increment should be potentially releasable, and meet the Definition of Done. They will then meet in a Sprint Review meeting and discuss what they should do next to deliver maximum value.
What Is DevOps?
DevOps is, at it’s core an effort to reduce the divide between development and operational teams. Literally, Dev-Ops there are many practices and ways of doing this from the cultural to the technological however what has most likely led you to this post are the ideas of Continuous Integration, Continuous Delivery, and Continuous Deployment. Again, DevOps has many valuable lessons, I’m focusing on these three not to devalue the other concepts, but simply because they are some of the key concepts we need to understand for this article.
Continuous Integration requires that each developer merges their code into the master branch every day and if the master build breaks it is resolved or rolled back within ten minutes.
Continuous Delivery is a promise that any code which is the master branch is always in a potentially deployable state. Untested and unverified code is never merged in.
Continuous Deployment is an automation mechanism which pushes whatever is in the master branch into environments (often production) without any manual steps.
As you can see these are cumulative, so teams may practice Continuous Integration but may not practice Continuous Delivery or Continuous Deployment. It is also nearly impossible to practice Continuous Deployment unless you also follow Continuous Delivery and Continuous Integration.
It’s also worth mentioning the “3 Ways of DevOps” these were popularised by the highly successful book The Phoenix Project. The 3 Ways are:
Amplify Feedback Loops
Culture of Continual Experimentation and Learning
Using Scrum and DevOps Together
Now that we’ve talked about what Scrum and DevOps are (or at least highlighted some of the relevant and key parts of each) I want to discuss whether these concepts can work in harmony together.
The first aspect to address is the Scrum concept of an increment. The Scrum Guide says that each team should produce at least one increment of “Done” software which is potentially releasable to production each sprint. I believe that the three concepts of Continuous Integration, Continuous Delivery, and Continuous Deployment are not only compatible, they are the natural evolution of this requirement.
If an engineering team is following CI, CD, and the other CD then each day (or less) a piece of work should be added to master. This means that a typical team of 7 engineers working a standard two week sprint could easily produce seventy or more increments in a single sprint. They key here is that by breaking down the Scrum Product Backlog Items down into single pieces of work which can be individually developed with a single day and then tested in isolation. This is not easy, however with practice and strong story splitting skills it can be done.
It’s also worth mentioning the Definition of Done. The Scrum Guide states that each increment must meet the Defintion of Done. Continuous Delivery states that the master branch should be always be in a deployable state. What a high performing Scrum/DevOps team should do is write automated tests which execute against incoming pull requests into their master branch to confirm that it always meets the agreed Definition of Done. This not only reduces the amount of repetitive testing work expected of the team but it highlights immediately when a proposed increment does not meet the team’s Definition of Done. If it doesn’t, it’s not merged in.
Before wrapping up I also want to consider the 3 Ways of DevOps I discussed above.
By building the Definition of Done into the Deployment Pipeline of the product we support the 1st Way by ensuring that the requirements of the team are baked into the pipeline.
The 2nd Way is to shorten feedback loops. Scrum emphasises the value of engaging with stakeholders frequently to ensure that they are involved and know the current state of the product. Scrum is also based on empirism, the belief that only we can only make estimates by looking at real data, by valuing the 2nd Way and shortening those feedback loops wherever possible this gives us a more accurate picture of what impact our changes have had. Simply put, this more accurate view provides the transparency we need to inspect and adapt. These are the three pillars of empirism.
Scrum also defines an event, the Retrospective where team members should meet to discuss ways to improve the quality and effectiveness of the team. This fosters the experimentation and innovation expected of the 3rd Way. These ideas aren’t working against each other. Scrum is providing events to ensure that the DevOps approaches are being honoured.
DevOps is often seen as a Scrum upgrade or perhaps a replacement to the agile framework. However it shouldn’t be. I believe that many of the automation and development strategies of DevOps are the natural evolution of Scrum principles and fit very neatly into any team already using the process.
With automated tests continuously testing each increment to guarantee that it meets the team’s Definition of Done increments can become smaller and a continuous flow of high value work can be delivered with shorter lead times and higher quality.
This is a question I get a lot, what are Scrum Alliance and Scrum.org and which is “best”? The truth is there is no best, both have different certifications and a different business model. In this post I want to explain the differences between the two and help you decide which to choose.
Let’s start with what they do. Both Scrum.org and Scrum Alliance offer training courses and certifications for Scrum Masters and Agile Professionals. Both offer a variety of courses for Product Owners, Engineers, and other professions but in this post I’ll focus purely on the scrum masters.
You can think of these organisations like Exam Boards, if you pass their exam you get a certificate which you can present to any employer and it will prove that you have a certain level of scrum knowledge. You can also show the badges off to your friends and family but personally I’d recommend against that. I spent half an hour explaining to my mum that a Scrum Master had nothing to do with Dungeons and Dragons…
Both organisations offer three levels of Scrum Master certification. For Scrum Alliance these are the Certified Scrum Master (CSM), the Advanced Certified Scrum Master (A-CSM), and Certified Scrum Professional Scrum Master (or CSP-SM). Scrum.org offers the Professional Scrum Master levels 1, 2, and 3 (more commonly known as PSM-I, PSM-II, and PSM-III).
Personally I hold the CSM from Scrum Alliance as well as the PSM-I and PSM-II from Scrum.org.
Where these organisations differ is in how they go about granting the certificates. Scrum Alliance require you to attend a training course organised by a certified trainer. The prices of these vary depending on whether they are being held remotely or in person, which country they are being held in, and the level of the course. Typically in the UK you will pay around £700 for a remote course and £2000 for an in person one. Obviously the trainer then pays a fee onto Scrum Alliance. Once you have completed the course you will be sent a link to take the exam on Scrum Alliance’s website. If you pass (the pass mark is 37/50 questions) you’ll be awarded your certificate.
Scrum.org also offer training courses. However, their courses are not a prerequisite to taking the exam. Personally I have never done a Scrum.org course, I simply logged onto the website and purchased the exam token. These vary slightly depending on level but the PSM-I exam is $150 dollars.
It is also worth noting that Scrum Alliance certificates expire and you will either need to attend another course or pay (about £30 I believe) to renew it every couple of years. Scrum.org certificates do not expire.
The next most obvious question is which is easier!? There is a general feeling that the Scrum.org exams are a little more challenging, however I’ve never seen any data to back this up. Personally I scored a couple of percent higher on the Scrum.org exam than the Scrum Alliance one however not enough to state clearly. If you’re looking for a simple answer on which one would be easier to achieve or which holds more market value then I can’t give that. I would say however that the PSM-II (and I assume the A-CSM) covers significantly more ground than the PSM-I and asks questions based drawn from personal knowledge rather than simply knowing the subject matter. There is a distinct step up in difficulty and, although I’ve never taken it I wouldn’t be surprised if the PSM-III was far more challenging again.
So there you have it, all the differences that I’m aware of between the two organisations. If you’re looking for a taught course with a certificate at the end then Scrum Alliance may be for you. If you’re interested in self study and funding then Scrum.org may be the better alternative however I’ve found that both are extremely high quality certificates.
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’ve spent three months describing the role and life of a Junior Software engineer and hopefully providing some useful tips and advice along the way. To wrap up this series I wanted to do something a little different and talk with some of the junior engineers I currently work with to ask them about the journey they’ve made and what advice they would give.
I’m sure this goes without saying but this is a personal blog and the views expressed are personal and do not reflect the views of our current employer or any of my previous companies.
Neither of you came from a Computer Science background. What made you want to move into Software Development?
I identified my interest in software programming when I used software programming for certain taught modules whilst studying for an Electronic Engineering degree. As for my final year project at university, I wanted to select it purely of my interest, consisting of mostly software programming. I then developed a tool that is currently being used within the University to extract embedded features in an Electromyography signal. This was the turning point that gave me the confidence to pursue a career in Software development even with a different degree background.
I studied Maths at Newcastle University, and was exposed to a small amount of programming, but it was usually used in our statistics modules to model data. I joined the company as a Client Service Desk Technician in Operations, and worked comfortably in the role for a couple of years, before wanting to utilize my maths degree whilst staying in the organisation, as I really like working hereand love the culture. I applied successfully for the Graduate Scheme and started in Delivery as an Associate Engineer in 2019, working on my competencies to progress to be an Engineer 1.
If I were to change my journey, I would still choose to study maths at University, however, I would choose to take some computer science modules to understand the fundamentals of software development. I think I would also choose to start reading about and learning programming from a younger age, which would have given me a platform of knowledge to build on when I did start the Graduate Scheme.
What advice would you give to someone who didn’t study IT at university but was interested in becoming a Software Engineer?
Get as much exposure to as many development materials as possible; if these are online courses, reading online videos, starting your own side projects, you name it. It’s not essential to study computing at University to become a Software Engineer, but I think an understanding of IT and software development processes is important for building knowledge learned whilst on the job.
If you are goal-oriented and have a true passion for IT, it is not an impossible challenge. Identifying where the passion lies is the first challenge; having the passion for what you want to do always makes it easier to be successful. It will be a comfortable journey if you have a tech background. However, even if not, there are many available resources, including books, articles, blogs which are beneficial whether you are a new starter or an experienced professional.
You have both had a challenging journey. Has there been overwhelmed and felt you made a bad decision going into IT? What did you do?
At the beginning of the Graduate Scheme, we undertook a number of workshops run by experienced engineers already working at TU. There were parts of the workshops that I failed to understand or grasp straight away, which caused me to feel overwhelmed as the other members of my graduate cohort were more advanced than myself. It did cause me to second guess my abilities, however, I took myself away to calm myself down, reassured myself that this is common for junior engineers that are new to software development (I was also reminded of this by Adam who was running the cohort this year) and carried on.
As a learning aspect from such situations, I have learned not to make decisions quickly based on incomplete information. It is a matter of being more patient and not rushing to conclusions. The methods that I have been following to improve decision-making are reflecting, understanding the context that led to a bad decision, and communicating with an experienced person to gain an opinion before rushing to decide. Never let yourself down and always work towards improving yourself while taking chances to correct the mistakes that led to wrong decisions.
There is a lot of discussion at the moment about how to address the huge gender imbalance in IT, especially in Software Development. As a young white male I can’t begin to understand what it must have been like to join an industry which was so male dominated. I asked Lizzie how she found it.
As a young lady joining a male dominated industry must have been quite daunting, what would you say to any young woman thinking about moving into development?
I think it takes a little bit of time to adjust to working with the split of men and women, as the dynamic is slightly different to begin with. But I wouldn’t allow it to discourage you from applying for a role in a male dominated industry. There is a massive drive at the moment for Women in Tech around the world, which should hopefully encourage young women to be confident in working in male dominated ‘worlds’, and to understand that the thought of working with predominantly men shouldn’t be daunting!
Finally I wanted to know about the success stories of the pair since becoming developers.
What has been your proudest moment in your development career so far?
Passing my competencies and becoming an Engineer 1 last year. I initially found the transition to working from home quite difficult, as I had to move to a new house unexpectedly, meaning my work from home environment changed overnight. I also found it challenging adapting to asking for help and gaining exposure to pieces of work as we weren’t all in the office, but my team were extremely supportive of one another, and we managed to get into the swing of working from home together, and therefore, felt like a big achievement to be promoted to Engineer 1.
I have a couple of moments that I am proud of as a junior Engineer with less than 2 years of working experience. Firstly, securing my first internal promotion even while working from home for almost a year due to the current COVID-19 pandemic. Secondly, I have been involved in organising tech talks for the development community within my workplace, and as a result, I was rewarded with an Excellent value award.
I want to give a huge thank you to Thajanee and Lizzie for agreeing to answer my questions and sharing their experience with my readers. They have not had an easy introduction to the industry, adjusting to working at home while still in a very early phase of their career however both have achieved huge success at our company.
I want to wrap up this series of Junior Developer posts by thanking you for following along, I do hope that this has entertained and hopefully inspired a few people to considering giving Software Development a try. I am always contactable so if I can be of any further support please do not hesitate to get in touch.
I was recently facing a bit of a conundrum. I was trying to work out why I was reading far more using Audible than I was out of paper or even kindle books. The obvious answer was because because I was listening to 45 minutes of audiobooks at double speed every morning but I was only getting half an hour every other night with my real book (currently Waltzing with Bears). The former I was fairly sleepy at the start of the day, the latter as I’m trying to keep my eyes opening in the evening.
The obvious answer I came up was because I was spending less time with my mind on the physical book. But also most likely because I could listen further than I could read.
However, as I pondered the question a little further I also realised that I was trying to do several things in that precious 30 minutes in an evening. I journal every day, I am reading a book on my kindle as well as the paper book and I enjoy painting my Warhammer and Game of Thrones minatures to undwind. In other words I had too much WIP in my evening routine!
We all know that WIP is very bad news and kills all productivity, what I had uncovered in my own routine was a bottleneck where I was trying to push several projects through the same 30 minute space in my day.
Wondering where else these existed I began thinking about my working day and carved my time into three categories. These are Hands Free, which are tasks I can complete while my hands and eyes are occupied on something else like driving or housework. Computer, which I spend a lot of time at so I created two parts. Hands On, which are times when I can complete a task with my hands. For example reading a paper book or painting my toy soliders.
I decided to call these Personal Swimlanes, you can now clearly see why I was having so much trouble delivering on the last one. I was thrashing between the various projects with no focus on any of them.
So, what’s the solution?
Well – you’re looking at it. By indentifying which work falls into each categories I can properly throttle WIP coming through and prioritising. Right now I’m focusing all my “Hands On” time on finishing Waltzing with Bears. When I finish that (in 70 odd pages) I’ll look at what the next project to move onto is. At the moment it’s looking like that unit of Ultramarines I picked up the other day!
What Swimlanes do you have in your day? Am I missing any? How do you focus your precious hands on time to make sure you focus on one project before moving onto the next?
Performance Management are two words which have the power to strike dread into the hearts of developers and managers alike. For engineers it conjures images of being fired, for managers it’s the sinking feeling that you’re going to have difficult talks with people with people about the quality of their work.
But that isn’t what performance management is about. At least it shouldn’t be!
Performance Management should always be about you working with your boss and mentors to continue to improve your performance. It should involve feedback, praise, and coaching. It should be something junior engineers embrace because it helps them progress their career and develop their skills. However, giving feedback is very difficult and unfortunately finding a boss who will give you honest, valuable feedback is rare.
I could write pages about Performance Management but this post is intended as part of my Junior Developer series so instead I’m going to focus on the most common mechanisms companies use and what you should expect when you join.
Probation periods are very common across the software industry (and elsewhere). In effect they’re a trial period for both you and your employer. They’re an opportunity for you to ensure you’re really happy with the company you’re working with but also for your boss to ensure you can do the job (or at least that you have the potential to do the job).
Typically probation periods last three or six months and during that time your notice period (the amount of notice the company has to give you and the notice you give the company if either wishes to end your employment contract) is significantly shorter. A month’s notice period is fairly typical for developers in the UK (or longer if it’s a more senior role), however during your probation this may be a week, or non existent. This is intended to support both sides. Personally I have never failed a probation, but I have left a company during my probation and being able to make that clean break was much simpler than having to wait an additional three months.
Every employer should set very clear objectives or what they expect you to achieve during this probation period. They should never simply book a meeting at the end of the three months to tell you if you passed or failed. The golden rule of good management is to never surprise your employer. A good manager will work with you during your probation and, if you’ve got some areas that you’re struggling make you aware of them so you’ve got plenty of time. You should never be unclear whether you’re on track to pass or fail a probation period.
1 to 1s
One of the most effective ways to support and coach your team is for managers to book in 1:1 sessions. Typically these are every couple of weeks but it varies with the individual and the circumstances. I have senior engineers who only watch to check in once a month and team leads I meet with weekly (or more often if they need it). I always hold more frequent 1:1s with people during their probation to make sure they’ve got the support they need.
Your 1:1 is your managers opportunity to coach and your chance to ask questions. It’s also your opportunity to talk about goals and career goals. There are countless excellent articles out there about 1:1s so I’ll leave it there and say that you should expect them and that they’re nothing to worry about.
End of Year Reviews
Most companies operate an end of year review cycle. These vary from company to company but they often involve talking about the positives and negatives of the year with your managers, some kind of goal setting exercise for the upcoming year, and often a discussion around pay and/or bonus. Often these are split into various conversations which may take place over a few weeks or even months.
The key is to understand what each session is for and what topics are likely to be discussed. This will help you think of examples where you’ve done especially well and give you a chance to think or a few areas where, with hindsight you may have done things a little differently.
It’s also helpful to understand what form of conversations the ones around pay and bonuses are likely to take. What’s normal for your company? Many television shows give the impression that you can march into your boss’s office and make a pitch for a higher salary. In reality (at least in the uk that’s rarely how it works). Often managers are given a pot of money to work with, once a year, and will have to make the fairest choices they can. However your manger be able to advice you on what happens at your company and what the financial review process will look like. Don’t be surprised if you’re not included in this process if you’ve been with the company for less than a year, it’s not uncommon for people who have recently joined to have to wait to be part of the uplift process.
When talking about goals for the following year try and be open and honest about what you would like to achieve. Ask your manager to support you and whether you think your ambitions are realistic. You can achieve a lot more if your manager is also looking for opportunities to stretch you than if you have to go hunting for them yourself.
Hopefully I’ve convinced you that normal Performance Management is nothing to be worried about. Sure, there are cases need to be coached through areas of under performance but the vast majority of what I’ve talked about in this post is the positive side of how to work with you manager to avoid needing and performance improvement plans.
What are your experiences of performance management? Are your experiences similar to mine?
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.