3 Tips for Avoiding “Reactive” Engineering

How to create successful proactive teams.

Jacob Beningo

March 1, 2022

6 Min Read
HR2TW0.jpg
Image courtesy of Alamy

Over the years, I’ve noticed that engineering teams tend to fall into two camps: reactive and proactive. As one might guess, the teams that are the most successful are proactive. They identify potential problems before they occur and put into play a series of contingency plans that allow them to navigate the issues nearly seamlessly. Reactive teams can be successful, but they are always putting out the latest fire and are too busy to look ahead at what is coming up just around the bend. They spend their development cycle in a stress-filled, reactive environment where they are always behind. In today’s post, we’re going to explore several tips for ditching reactive tendencies and thinking while adopting a more proactive approach to engineering.  

Tip #1 – Learn to prioritize activities

Unfortunately, human beings are bad at prioritization. In general, human beings are short-sighted and focused on the short-term, not the long-term. Short-term thinking tends to make us focus on what we believe to be fires. The client who interrupts our day wanting something right now or the manager who suddenly feels like focus needs to be placed on a different feature. The problem that we face is that not all tasks are created equal and we often focus on and prioritize the wrong ones!

Related:5 Tips for Choosing an Embedded Programming Language

Dwight Eisenhower, the 34th President of the United States, had a simple decision-making process to prioritize activities that has become known as the Eisenhower matrix (popularized by Stephen Covey). The idea is that all tasks and activities can be classified as either Urgent or not Urgent, and Important or not Important. These four classifications then create the four quadrants of a matrix which help to guide what should be done with each task as shown below:

2D8E1J1.jpg

An illustration of the Eisenhower matrix.

The Eisenhower Matrix can help engineers and managers decide what activities should be prioritized. For example, if a customer calls in with a major bug and their entire company has ceased functioning until it is fixed, that would be Urgent and Important and should be handled immediately. If the customer calls with a request to change how a report looks, that might be important but not urgent. The change could be placed onto the sprint backlog and then scheduled at a reasonable time in the future.

Another example is that a customer could call with a configuration change that is needed. To the customer, it’s urgent but not necessarily important. In that case, the configuration update might be delegated to an intern or junior engineer. Finally, an engineer may realize that with some code refactoring, the performance of the system could be improved by 2 percent. That improvement might not be important if there is plenty of processing power and it most likely isn’t urgent. In that case, the team may just decide not to spend the time on that improvement.

Related:3 Tips for Rapid Prototyping with the Raspberry Pi Pico

Reactive teams often fall further behind because they struggle to prioritize the right things. I once worked with a client who on a daily basis changed the priority. One day feature A was urgent. The next day feature B, and so on and so on. A week later, feature A was urgent again. Once I noticed this behavior, the key to helping them was to place proper prioritization and planning processes in place. The daily fires ceased and everyone became much more productive.

Tip #2 – There is no time better than right now

An interesting behavior that I’ve noticed about reactive teams is that they often know what they should and shouldn’t be doing, but they put it off. The heat seems to be one them and they are buckling down and pushing hard to just get through this. They believe that once this fire is out, things will be better, but their reactive nature keeps the reactive cycle going strong. Teams that are reactive will often say things like:

“We know we should do X, but we need to deliver A, and then we’ll go back and do it right”.

“We should be doing X, but we just don’t have time right now”.

“After this delivery, we’ll spend time putting A and B in place”.

Unfortunately, it’s all wishful thinking. The only way to break the cycle is to recognize that right now is the best time. If a better DevOps process will help improve quality or delivery times, start on it now, not after that next delivery. What comes after that next delivery? Another delivery! In his book “Atomic Habits”, James Clear says that if you improve by 1% per day, then over the course of a year, you’ll have improved by 37x! You may not need to improve that much, but starting now and making small incremental, daily improvements will result in some dramatic improvements.

Tip #3 – Develop team discipline

One definition for discipline as defined by the Merriam-Webster dictionary is “to train or develop by instruction and exercise self-control”. Proactive teams are disciplined. When a curveball is thrown at them, they don’t react, they evaluate the situation, develop a plan, and then follow through with the plan. Even better, they already considered the potential curveball and had a contingency plan in place which they execute.

In the technology industry, we are all in a hurry. We’re trying to be the first to market. We’re trying to get a leg up on the competition. Maybe we’re trying to get to market before we run out of venture capital funding. Perhaps we’re just in a hurry to get rich. In an industry that by nature is in a hurry to innovate and get to market, it’s more important than ever for teams to be disciplined. To carefully weigh the activities they work on, and how they perform those activities.

As strange as it can sound, the teams I’ve worked with that are most successful are disciplined, thoughtful, and proactive about how they do things. From the inside, it can feel like things are moving slow. From the outside, it can be difficult to understand how they can move so fast and create such wonderful products.

Conclusions

Successful engineering teams are proactive and disciplined; they don’t react to perceived urgent activities. There is a difference between urgent and important activities and urgent non-important activities. Whenever a fire pops up, don’t immediately react. Carefully consider and weigh the longer-term effects of responding immediately. You may be surprised how many urgent things pop up that turn out to be not that important. Just waiting 24-hours can provide a completely fresh perspective.  

The ultimate question you must ask yourself is whether you want to always be reacting or be proactive. If you want to be proactive, plan ahead. Watch for what can go wrong and what changes could occur and plan for them. Then when they do occur, you won’t react, but just pivot to one of the plans. In principle, it sounds simple, but you’ll find it takes discipline, patience, and practice to get there. The benefits though can be dramatic.

Jacob Beningo is an embedded software consultant who works with clients in more than a dozen countries to transform their businesses by improving product quality dramatically, cost, and time to market. He has published many blogs to count embedded software architecture, processes, and development techniques. He is a sought-after speaker and technical trainer and holds three degrees, including a Master of Engineering from the University of Michigan.

Feel free to contact him at [email protected], at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter.

About the Author

Jacob Beningo

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 300 articles on embedded software development techniques, has published several books, is a sought-after speaker and technical trainer and holds three degrees which include a Masters of Engineering from the University of Michigan.

Sign up for Design News newsletters

You May Also Like