So, what the heck is a forcing function and why should you care? A forcing function is one of the most powerful tools a leader or manager has at his disposal to facilitate compliance. Or better yet, if used correctly, a forcing function can force key behaviors that encourage collaboration, motivate employees, and speed up a teams throughput. Keep reading for practical tactics and examples of ways to leverage this unique management technique to build exceptional teams.
First, let me demonstrate the incredible power of forcing functions through a story about a game nearly everyone is familiar with. Chess…
Have you ever heard of Bobby Fischer? He was once the youngest person ever to receive the title of chess grandmaster. At the age of 15 Bobby was awarded this coveted title and became eligible for the chess world championship. I can remember as a kid watching the movie that immortalized his name among those uninitiated in the world of chess. The film, “Searching for Bobby Fischer”, surprisingly has nothing to do with Bobby Fisher however, rather it’s about a 7 year old chess genius who is taught the methods of Bobby Fisher and struggles to keep his positive perspective on life while training to see the weaknesses in his opponents. At the beginning of this movie, the boy is playing a championship match and appears to be losing, when he suddenly extends his hand to his competitor and says, “I’m offering you a draw… you’ve lost, you just don’t know it.” To which his opponent replies “I’ve lost? look at the board.” The boy genius dons a sincerely sympathetic face and replies, “I have”. The drama intensifies as his opponent stares him down and says, “Move”. Our protagonist jumps into action, moving pieces and slapping the clock. After only a few moves they are down to a King and Queen each when the fatal words are uttered, “Check”. The opponent looks stunned as the realization of his situation settles in. He had a Queen, but was unable to move it because he was forced instead to move his King out of check. This opened the Queen up to attack and two moves later it was all over.
This brilliant forced move at the end was the final blow, but the last few moves are not where a chess players brilliance is tested. Let me draw you attention back to the moments before the prodigy extended his hand to offer the draw. In this scene the boy sat quietly staring at the current state of the game, planning out every move. After planning out the next five or six moves, we hear him think, “I can’t see it”, followed by the memory of his coach’s voice saying, “Don’t move until you see it.” Again the boy thinks, “I can’t see it”, and again we hear the coach’s voice in his head saying “Don’t move until you see it. After a moment of this back and forth it clicks for the kid and his facial expression changes. You hear his coach exclaim from the other room, “He’s got it”. This was the moment of transcendence for the young man, when he was able to see the rest of the game played out in a series of forced moves that lead to his inevitable victory.
This is the strategic beauty of chess that has always intrigued me. I am a casual player at best but I have great admiration for someone like Bobby Fisher who is said to have the ability to calculate 20 moves ahead. This is done by designing maneuvers that either entice or force your opponent to do what you want in order to simultaneously craft a counter attack that takes advantage of the manipulated move.
That was a long story to get to the point of this blog, but I hope it resonates with you, and that it helps draw a mental picture of how powerful forcing functions can be. Now let’s take a look at how to leverage this powerful tactic in the world of business.
1. Decreasing Errors
Have you ever been fired for making a mistake on a job? Or how about do you know of someone who has been fired for making a mistake on a job? I read a story once of an employee who made a mistake on the Ford assembly during the era of Henry Ford that was said to have cost the company 2 million dollars. When the supervisor went to fire him, Henry Ford stepped in and said, “Why would we fire a man we just spent 2 million dollars training?”
I have experienced this sort of thing in my own business before. I can remember running a marketing agency and being informed that one of my account managers had ordered a large batch of business cards for a company before having the company proof the final design. Somehow our designer had mistyped the phone number and the entire batch had to be recorded. Though my experience did not equate to a 2 million dollar mistake, the financial loss on the job was still significant and painful. Instead of a reprimand though, we told the employee that we would cover the cost. Feeling guilty, she never made that mistake again.
Though it’s a nice gesture of faith to keep someone on after they make a mistake that costs the company significant money, or after their mistake loses your firm a key client. What would be even better is to avoid that expensive “learning experience” in the first place. The thing I didn’t realize at the time was that it was not my employee who failed by placing an order for a print job with a typo. It was actually my failure as a leader and manager.
Through forcing functions I could have setup processes that forced certain actions to decrease the chance for errors. For instance, I could have set up a process that required a secondary signoff before anything went to print. I could have set up a contractual agreement with our vendor that stated they needed to deliver proofs for review before printing. I could have even shifted the liability to my customer by requiring their signature on any designs before sending them to print. Each of these options creates a forcing function in a process that drastically decreases the chance for errors.
If you look at this through the lense of development teams, I think we would all agree that bugs are a reality of our existence. Computers are far too complex to assume we can develop everything perfectly the first time. That’s why tools and tactics have been developed to help identify and mitigate the impacts of bugs before they are introduced into production systems. Some of these forcing functions were pioneered in the Agile methodology known as Extreme Programing. Including unit testing, and integration testing. Essentially these practices dictate that you write automated test scenarios for your application during the development process then you are required to run them before you can deploy new features into production. If some of the test fail it’s a sure sign that your new code broke the old functionality.
Automated testing is one of the most powerful forcing functions in the tech industry, but policies and tools that enforce those policies go right alongside them. Have you ever heard of error budgets, which essentially stop all deployments when systems reach a certain threshold of issues such as speed. What about policies that limit job and queries from running on live databases and inadvertently crashing them?
Forcing functions are possible in every industry to decrease error rates and increase product and process stability. See the section on Pitfalls below to understand some of the potential issues with forcing functions if they are taken too far.
2. Speeding up Teams
One of the coolest things about forcing functions is that, if used wisely, they can be used to help teams go faster. I don’t know about your company, but in the places I have worked, speed is something the business side of the house is constantly pushing for. The generic answer I have heard a hundred times from the development department is, ‘if you want more speed, hire more people’. What if we could speed teams up significantly without asking them to work more hours and without increasing headcount. There are two ways that this is possible
As a quick illustration, let me tell you about a story I read recently in a management book called First Break All the Rules. The story is about a fast food chain that hired partially disabled employees in an altruistic act of community spirit. One such employee was not able to count and was tasked with frying chicken. The problem was that the frying basket could only hold six pieces of chicken and without being able to count, the employee would often put too much chicken in the basket which resulted in undercooked chicken leading to a significant health risk.
The company could have fired her over this, but instead chose to create a forcing function to eliminate this error. They asked their supplier to wrap chicken in six piece packages so the employee wouldn’t have to count the number of pieces each time. This supplier said ‘no way’, and was subsequently replaced by a supplier who was happy to oblige. The result was, of course, a decreased error rate, but it also drastically sped up the entire process. No longer did any employee have to count chicken, instead they simply opened a package and poured the content into the basked.
On a side note, this is a great example of shifting a constraints responsibility or ‘Subordinating everything to the constraint’ as discussed in my article on the Theory of Constraints.
In ‘Lean’ theory we learn that every workcenter has two customers, the external customer who is buying the finished goods, and the internal customer, which is the rest of the company. ‘Lean’ teaches that the internal customer is the first priority, because through helping the rest of the company you are creating efficiency that also help the external customer. Forcing functions are the way to pull this off. By creating tools or processes that eliminate steps in a process you are speeding up a team or department.
In the technology industry this can be done through investments in automation such as automating the deployment process or the build pipeline. It can also be done at a team level through tactics such as code reviews or paired programming. All of these things force speed, some through offloading work, as in the case of automation, and some through decreasing the possibility of rework.
One last note on this. One of the best forcing functions for speeding up teams is the implementation of WIP limits or Work In Process limits. See my article of Kanban for a deeper understanding of how this works. To summarize, WIP limits are predefined caps on the amount of work a team can be engaged in at any given time. By forcing the team to focus on finishing a small amount of work before taking on more, you are able to maintain focus and avoid the trap of switching costs.
3. Empowering Employees
Have you ever tried the trick of simultaneously patting your head and rubbing your stomach? It’s harder than it seems! The reason has to do with our brains ability to multitask, or more accurately our brain’s inability to multitask. It has been proven that our brain has limited ability to cognitively juggle multiple tasks at the same time. This is where switching cost theory comes into play. It is believed that we lose between 20% & 60% of productivity when we have to switch contexts and tasks. When you are simply switching from one task to work on another, you only have to pay that cost once, when you try to multitask however your brain has to constantly jump back and forth, hundreds of times per minute, between the two tasks, causing you to pay the switching cost each time your brain makes that switch. This is why multitasking is so damaging to productivity.
There is an exception to this rule however which you may have caught onto. If it’s so hard for the brain to multitask, how are we able to walk, breathe, talk, and think logically simultaneously. Without getting into the science of it, let’s suffice it to say that our brains have the ability to turn purposeful actions into habits that are handled by a different part of the brain. This frees up enough brain capacity to focus on new actions or logical problems while the lower level brain functions take care of habits like breathing, walking, and forming words. Switching cost theory largely applies to the part of the brain actively solving new problems rather than the part of the brain handling habitual tasks.
Leveraging this knowledge, we can establish forcing functions that encourage the development of habits. This frees up the mind of a knowledge worker to focus mental energy on new problems rather than asking them to continually re-solve existing ones. This is the foundation of empowerment, creating processes for the things that absolutely need them, or the things that can be significantly improved through standardization. Then letting go of our knowledge workers and letting them function inside the constraints.
Example of this in technology organizations could be linting tools for code, code commit processes, full integration test coverage, and even autofill tools in modern IDE’s. All of these offload the mental requirements of keeping hundreds or thousands of memorized concepts, variables, or potentially impacted modules in one’s head at all times.
A real life example of this can be found at Google inside their SRE (Site Reliability Engineering) teams. Thy have established SLO’s (Service-Level Objective), SLA’s (Service-Level Agreement), and SLI’s (Service-Level Indicator) on all of their services as standards of excellence. A team can do whatever they need to in order to fulfill their primary objectives, as long as their end result meets these standards. This empowers the team while ensuring they stay inside the given standards.
4. Motivating & Keeping Top Talent
Motivated teams move faster and generate an environment of excitement that attracts and retains the most talented employees. Inversely, when a team loses motivation their attrition rate goes up. Forcing functions, if leveraged correctly, can be a key tactic in keeping teams motivated.
I worked with a team one time who spent over a year on a feature for a Saas application. The project was on schedule and they were only a few months away from completing it when a higher priority project was identified and the team was asked to drop their current project to focus on the new one. This felt like a punch in the gut to the team. It demotivated this high performing group and made them feel as if the work they had been doing for the past year was a waste of time.
This team worked in an Agile environment where pivoting based on market needs or organizational directive is encouraged. The problem then was less about pivoting and more about the fact that the team was not able to achieve personal satisfaction for the work they had done before moving on. They pivoted, but their productivity dropped from exceptional to average. You see, motivated individuals invest themselves in a project, demotivated employees invest only their time. There is a major difference in output between the two.
We fixed this issue by establishing a compromise with the business side of the company. They agreed to let teams finish their current projects before pivoting to new ones. In exchange, the development group agreed to break up large projects into smaller batches to create logical breakpoints every few weeks or months. This allowed the team to achieve something at the end of each batch of work, rather than the recognition and completion status being stored for the end of a long lived initiative. This also established a forcing function for the business that made then spend more time on prioritization upfront, knowing that they would have to wait a short time before pivoting if they chose the wrong thing to work on next.
This type of external forcing function was used to insulate the team, as much as possible, from the ebbs and flows of business strategy. It allowed them to feel pride over their accomplishment before asking them to pivot to the next thing. This bolstered the teams morale and showed them that their effort was valuable. In turn, it helped us decrease attrition.
Pitfalls
By now, I’m sure you have recognized that forcing functions are apart of any good process and you have probably drawn a correlation to policies. I would argue that policies generally (though not always) state what not to do whereas forcing functions focus on what to do. Example would be an HR policy that states ‘don’t be late for work’. A forcing function on the other hand would be a daily touchpoint (or stand up, if you practice Scrum) at 8:00 where you will be held accountable by your team if you don’t show up.
Now that we have drawn the correlation to policies, let me make you aware of two common pitfalls. The first is establishing a forcing function without someone who owns responsibility for it. The second is imposing too many forcing functions and thus failing to empower your team to leverage their own drive and creativity to produce amazing work. Avoid both of these and you will have established powerful guardrails to help your team achieve more than anyone thought possible.
Leave A Comment