Have you had the chance to watch the Grand Prix series on ESPN or another sports channel?

I mean these bike races that take place all around the world.

There’s this moment when the rider tilts his bike, extends his knee to the ground and gets into the turn.

What is the secret of the best riders? How do they turn without crashing (Hint: the answer is in the picture)?

Take a good look at the helmet that Eddie Lawson, one of the best bike riders, is wearing. When Eddie turns, his eyes are on the spot where he wants to be. He doesn’t look at the roadsides or at the exhaust pipe of the bike in front of him – Only at the point where he wants to be.

This is the first rule of getting to the finish line and winning the race.

True. You need to shift your weight balance at the right moment, speed at the right time, and some other things that separate the everyday driver from Eddie Lawson. But this is the main thing – keep your eyes on where you want to be.

What’s obvious on the racing track is not that obvious when working on a software product. Nevertheless, in both cases, you might crash and burn if you don’t focus on your goal.

In this post, I’ll be talking about how you can get quite remarkable results when following the rules of focus. You may have read articles on this subject in the past but what makes this one different is the fact that it tells the story of how to translate this rule into a series of actions that quickly result in a dramatic change. I used it during a rather crazy period of time, during which, in addition to building the next version, we were busy in treating emergency calls that kept on coming from customers.

So, if you are dealing with a similar situation, (the need to divide your time between building the next product and working with customers), you may find here a method to efficiently do it. And if not, I hope the example will illustrate how keeping the focus can bring about an amazing change in work.

The whole thing started on the wrong foot. All of a sudden, we were inundated with support requests from our customers. It took us a long time to treat them and the development process almost completely stopped. The situation was very frustrating for the engineers and team leaders, who felt we were going full gas in neutral, as it were.

The thing that made the difference, much like on the racetrack, was focus. When we began following these four rules:

• Define a crystal clear goal for each team.
• Define a simple method which instructs a team how to focus on their tasks.
• Eliminate any interruptions that are not related to the task at hand
• Choose only the most important tasks for success

That’s when things started happening fast and efficiently. And when I say fast, I mean the result was amazing. The speed of development quadrupled itself.

Rule #1: protect the development engineers. Keep them focused.

Context switching is a quiet and deadly project killer. There are so many good reasons to do so many important things. Yet, a team that tries to do everything at once will end up switching from one task to the other, without really getting things done.

To eliminate context switches and to remain in focus, a team needs a crystal clear goal. They also need you to build the right environment for them. The right environment shields from distractions and helps to remain in focus. Actually, the difference between an achievable goal and yet another slogan lies here. A goal without a plan is an empty slogan and a good plan comes with an environment that protects it and allows it to happen.

In our case, the answer was to divide the tasks. We built an environment by changing the structure of the teams, so that some of them shifted to focusing on solving customer issues, while others kept on building the next product. These are two different things. One requires creative thinking and finding quick solutions or workarounds, while the other requires minimum interferences and focus on research, design and development.

One of the team leaders told me that after the change, he felt like someone pressed a button and shut down the volume all at once. For the first time, after a long time, he could actually plan what he was going to achieve every day, and follow his plans without interferences.

What you need to remember: A team needs a crystal clear goal. You also need to provide them with a supporting environment to achieve this goal.

Rule #2: Protect the QA engineers as well. Keep them also focused.

Much like the development group, you should keep your QA team focused. One QA team switched to working on a bug-fixing version that we released to our customers. In fact, every several weeks, this team took that version, tested and released it. The rest of the QA people kept working with the development teams on building the next version.

What you need to remember: Focus is everywhere – in the product strategy, in the product’s definition, in development, testing, documentation and more.

Rule #3 – Verify you are doing the right things. Cooperate with technical support

Focus by itself is not enough. Other than ensuring you are doing everything right; make sure you are also doing the right thing.

The support team knows the customers best, what is critical and what can wait. Much like a hospital, where a staff meeting is held every morning to review the patients’ treatment, we also established a weekly meeting with the support team and the leads of the development teams. We reviewed all open problems, identified which were the most important ones, which ones could wait and which ones should be rejected as a product misuse. In every review, make sure you understand the nature of the problem, what the customer’s real pain is and what solution would satisfy him. And another thing – at all times, and I mean “at all times”, seek the fastest and simplest solution, and even if there are better ones.

What you need to remember: It is not enough to do things right. Make sure you are also doing the right things.

Rule #4 – When dealing with customer problems, aim for a quick resolution.

When we dealt with a customer problem, we insisted on four guidelines which drive to quick resolution:

• Focus on solving the customer’s pain and not on fixing the technological issue – For example, a customer complained about a low performance system and we discovered the reason was high memory consumption. Immediately, we changed system’s virtual memory settings and solved the issue. Later on, we implemented a code change which prevented the problem from happening. Yet, the customer got a solution within a single day and didn’t have to wait for the new and improved version.
• Update at all times – A technological solution is only a small part of what it takes to keep your customers satisfied. If a customer has a problem, update the support team on what you did, what you plan to do and the approximate date of the fix. Even if there is no progress, the customer will feel his problem is important to you, remain patient and even thank you when you’re done.
• What is not supported is not supported – Many times we discovered problems were caused due to using unsupported operating systems, incompatible hardware, etc. In such cases, we simply recommended the right configuration. It may seem trivial, but quite often it is overlooked, and when the user is on the line, people tend to forget everything and invest effort in trying to make things work when they shouldn’t.
• What is not interesting is not interesting – If a customer did not reply to our inquiries about his problem, we stopped treating the issue. It may not be relevant for him any longer, so we’d better invest our time and effort in solving other problems.

What you need to remember: As part of a supporting environment, define simple rules that will guide your team to achieve their goal.

Rule #5 – Focus on the “What” – Clearly define the development areas

The first 4 rules describe the “how”. This one addresses the “what”. When more and more calls land on your desk, it would be just natural to try and solve them one by one. It works, but it is not very efficient. At some point, we paused and started looking for repeating patterns. We looked for specific areas in which a single change could solve a whole group of issues. That’s how it should be done:

• Once every two weeks, go over all incoming reports and try to identify repeating patterns and common issues. If you find any, it is possible that fixing one area of the product may solve a whole group of problems.
• When we identified such “hot points”, they were moved to the development team that worked on building the new version, who refactored them. After it was done, the fix was back-ported to the version of the fixes.
• Priority was given to dealing with these “hot points”, even over problems identified by the QA people.

What you need to remember: sometimes different goals = different methods.

In the example above, much like when using binoculars, where you can either focus on a distant object or an object which is nearby, one team was focused on the short-term, while the other was working on the long term. One team worked in a KANBAN style, while the other found SCRUM more suitable (guess, which is which).

Rule #6 – Last but not least: understand how to prevent it

The right thing to do is not to solve the problem, but rather preventing it from happening in the first place. In this case, the solution was obvious – switching to a continuous integration mode and improving all levels of automated testing – unit testing, subsystem testing, and end-2-end UI testing.

What you need to remember: stop for a while and look at the big picture. What do you really want to achieve?

One last comment on the difference between service and on-prem

When the product is delivered as a service, a correct implementation of continuous integration (CI) is mandatory, so you can have a clear view of the product’s state at all times and decide whether an update is ready to go live. Similarly, continuous delivery (CD) is mandatory so you can immediately deploy an update.

As updates need to be applied quickly, it is a good idea to introduce them in baby steps – a small change at a time, so the odds of things going wrong are lower. This way, introducing small changes via CI/CD leads to higher quality. Moreover, building the deployment environment in the right way would allow a gradual exposure of updates to your customer base (what is known as AB testing). This way, you can get instant feedback from the users and identify a problem before it makes a significant impact.

Good luck!

Ilan