ISBN 13: 9781921731808
The Lotto Factor
Smith, Guy V.
This specific ISBN edition is currently not available.
Alex McCabe, a passionate numerologist, sets out to prove that nothing is truly random. His life has seemed so meaningless to date, but maybe all the suffering he has endured was not simply a series of random events. What better way to disprove randomness than being able to predict the outcomes of the National Lottery? With the help of a computer program, a mischievous bulldog that effortlessly gets Alex into and out of trouble and a few special friends, he succeeds in winning the lottery – but not without headwinds. Together with Alex’s ability to predict the lottery numbers almost at will, a more profound discovery results in a surprising twist, which could possibly change the fabric of human society.
“synopsis” may belong to another edition of this title.
AbeBooks.com: The Lotto Factor (9781921731808) by Smith, Guy V. and a great selection of similar New, Used and Collectible Books available now at great prices.
Maintaining a Good ‘Lottery Factor’
Ensuring there is no single human point of failure
Sep 10 · 5 min read
What is the Lottery Factor?
The Lottery Factor, more often referred to as the Bus Factor, is a number that represents how many p e ople being no longer available on a project would put that project in jeopardy. It is derived from the concept that if specific people on a project won the lottery and left (or were hit by a bus), those remaining would not have sufficient knowledge to keep the project going. A low Lottery Factor therefore is bad, because people do leave projects for many reasons, and having a project dependent on one or two key people is risky. This concept applies to projects in many industries and disciplines, but my focus here is on Software Engineering.
In addition to putting a project at risk due to people leaving, a low Lottery Factor can slow down a project’s development if work on areas can only be done by specific people who may be already busy elsewhere.
It is therefore important as a manager, and/or project lead, to ensure that the project has redundancy in the knowledge and skills required to continue. Whether that be to continue building, operating, or maintaining the project. I detailed in a previous article how to build up a good Lottery Factor, but how do you maintain a good Lottery Factor?
Building a Good ‘Lottery Factor’
Ensuring there is no single human point of failure
How to Maintain a Good Factor
Everything needed to build a good Lottery Factor is also needed to maintain it. Those efforts should be continuous as the team evolves, and the projects change. Once a good Lottery Factor has been achieved, it will inevitably dwindle over time. This could be due to attrition or just the team focusing on the newer aspects of a project or new projects entirely. There are, however, a few things you can do as a team to slow the decline of the Lottery Factor.
“It is critical for someone who has to deal with live site incidents to have context on what has changed recently.”
Pull Requests (PRs)/Code Reviews
In order to keep shared knowledge of a project up to date with the ongoing changes to it, having team members participate in reviews of PRs ( Pull Requests or Code Reviews) is essential. There are many benefits to having multiple engineers approve code changes before they go into production, the sharing of knowledge is one of them.
As well as giving others an opportunity to provide feedback on upcoming changes to a project, PRs give insight into changes occurring to those on-call too. It is critical for someone who has to deal with live site incidents to have context on what has changed recently. Neither the SME ( Subject Matter Expert) nor the person on-call really wants to have to have an issue escalated due to a lack of knowledge.
Finally, PRs give team members who may be working on other areas of the project a way to see what changes are happening elsewhere at their leisure. Without the need for them to be included in every meeting or discussion in real time.
“Where PRs help keep the detailed low-level knowledge flowing, collaboration, feedback and review of designs help the higher-level knowledge spread.”
Collaboration on designs
Ensuring the design of new features is done in a collaborative way, involving others on the project, helps to share the new bigger-picture knowledge right from the very start. Where PRs help keep the detailed low-level knowledge flowing, collaboration, feedback and review of designs help the higher-level knowledge spread. Accepting and facilitating feedback on designs and plans also encourages buy-in from others on the project, which promotes shared ownership and responsibilities. These aspects help prevent the need to rebuild your Lottery Factor by keeping knowledge across the team fresh as things develop.
This is applicable not only to system architecture designs, but to any planned item. Whether that be user experience proposals, process changes, business direction changes, or marketing campaigns. Opening these up for broader discussion and feedback before they go into action is a great way to start seeding that new knowledge that will need to be shared eventually. And getting diverse feedback at an earlier stage is of course better than when it’s too late.
“It is a good idea to have people within an engineering team rotate around a number of areas a team is responsible for.”
Rotation of work areas
While having dedicated SMEs remain responsible for specific areas of a project over a longer term does have some benefits, it also increases the risk of them becoming the one person capable of running an area. The dreaded Lottery Factor of one. In order to help alleviate this, it is a good idea to have people within an engineering team rotate around a number of areas a team is responsible for. This rotation shouldn’t be only small, insignificant work, it should give people the opportunity to really invest in an area and deliver something meaningfully. But knowing that the work will be passed on and the knowledge shared once again encourages openness of information and reinforces the need to document.
There are cases where specialized, and very deep knowledge, is essential, and in order to build this people need to be focused on a specific area for a long time. And that is ok. The aim of having engineers rotate around does not need to apply to every engineer. In fact, having too much churn can make it hard for engineers to ramp up in new areas if those most knowledgeable in an area are focused elsewhere. Having the rotation focused on the more junior engineers actually has many additional benefits. It is a great way for them to gain a wider breadth of experience, and help them figure out where their strengths and passion lay, while also building understanding of the operations of the various areas.
In this case, it is acceptable to have the primary source of knowledge in a single person. But, in order to maintain a good Lottery Factor, that knowledge should also be duplicated in fragments across a number of other people. That means in the situation the primary SME leaves, there is not an immediate single replacement, but the knowledge does exist and needs to be combined from a number of the other engineers. In this situation, a decision would need to be made as to whether a single replacement SME collating all the knowledge to become the replacement is the desired outcome. Or whether the new normal should be keeping it spread in fragments and ensuring each fragment is duplicated across multiple people to keep the Lottery Factor up. The right choice here will depend on the state of the project and the plans for its future development.
Maintaining a good Lottery Factor, in order to protect your Team and Project, is a continuous exercise. It requires a team that is well balanced across the spectrum of those new to the areas and veterans of them. And it requires growing a culture of knowledge sharing and collaboration across the team. This is a journey the whole team needs to take, not one a manager can just dictate.
Maintaining a good Lottery/Bus Factor on a team in order to ensure there is no single human point of failure.