Stop Optimizing for The Past

I have had the fortune of learning a lot about development processes and how people approach work. It is always amazing to understand what excites people about work and how they see their role in creating our products. I find great pride in helping people evolve their practices to improve how products come together. Let's explore some observations I have made about what drive people to optimize, and some ideas on how to move to a different way of thinking.

Road crew paving a road in an abandoned town

What drives optimization?

I have noticed a typical driver in how many groups and companies define their development practices. These practices start by working to prevent pains the team has encountered in the past. We build our documentation, processes, and automation around avoiding things that have happened to us before. 

“This happened once, three years ago, and in response, we implemented a rule to prevent it from happening again.” 

I will share a scenario from my experience.  One of the teams I work closely with adapts products from one market for other sales opportunities.  This team traditionally operated 2-3 years behind the rest of the company in terms of software libraries and improvements. Developers on this team have built deep, ingrained expertise in navigating our company’s legacy code and are well-versed in the pains that go along with that.  All their documentation, tasks, and methodologies are designed to find and navigate problems in those legacy products. They maintain numerous versions of software and tools that have been designed to overcome every fathomable scenario.

Fast-forward to today. This team is now trending about 6 – 12 months behind the rest of the company, and their mindset is still about preventing hardships around 3-year-old code. They are optimizing for a problem that doesn’t often occur anymore.

Why do teams focus on the past?

In the simplest form, our teams tend to optimize for the past because that is what they know. We do not really know what we will encounter. Also, if we look for data about where issues occur, it will always point to work we have completed. When looking for opportunities to improve, it is easiest to look at the tasks and processes that were most difficult to accomplish in our most recently completed projects. Additionally, we naturally look to prevent pain and discomfort. This could also be described as a fear of failing or making a mistake more than once.

You only need to grab a cactus once to learn that touching anything with spines sticking out will likely hurt. The next time you encounter anything with spikes on the side, most of us proceed with caution and a different approach. However, experience with cactus doesn’t teach you that fire will hurt. 

This combination of a deep understanding of our prior work and natural tendencies carries over to projects and process improvement.

Overcoming The Past

Overcoming our inclinations to prevent pain is ultimately more difficult than it sounds. Our natural tendencies are a potent force. Begin this process by:

  1. Identifying the largest past pain points. (What Hurt the Most?)
  2. Review the upcoming roadmap and priorities. (What will be common?)
  3. Figure out what pain points will likely exist in upcoming projects.
  4. Plan efforts around upcoming projects. (Optimize for the Future)

What Hurt the Most?

Start the conversation by acknowledging that past problems must be part of the conversation. Ensure that the team knows they can factor those lessons into our future projects. Bring the information and data from those lessons as you start planning future projects. 

Review your data and look for the places where the team put the most effort. Collaborate to clearly identify the key factors that cause those scenarios.

What Is the Roadmap?

Openly share the product plans and requirements with them.  Allow time for the team to review and think about the challenges they foresee with those projects. Be available to answer any clarifying questions they may have.

What will be common?

Next, look for common elements of your future projects.  Create an opportunity for the team to identify if we will encounter any of their large pain points in future projects.  Prioritize these for optimization and tie metrics to the projects that will benefit from the improvements. Find a way to understand if the team improved.

As an aside, it is important not to optimize for every possible pain point, even if it will occur in future projects. I often ask my team to solve the problem for only 51% of situations we will encounter. Using this definition, we can say anything else is an outlier and should be considered a special case. It is not possible to reliably optimize for special cases. For special cases, encourage your team to focus on the situations they will encounter more often and optimize for those.

Optimize for the Future!

Next, it is time to start talking about where you can optimize the process. Be sure to remind everyone that the projects in the upcoming plans must take priority in deciding where to optimize. They must explain where a concern will likely exist in a future project before we can tackle solving it.

If none of the future projects likely include our pain points, then it doesn’t benefit us to solve a problem we are not likely to encounter.

Span of Control and Sphere of Influence

One last area to consider is that as you and your team work through the solutions to the problems they are likely to encounter, ensure they are looking to solve the root of the problem as much as possible. Often, the pain points our team voices are related to inputs or outputs to the team. If your team depends on information from someone else who provides unreliable timing, does it make sense to solve the problem with internal processes? 

Things We Just Live With

Avoid falling into the learned helplessness trap. Look for opportunities to re-evaluate the intent of rules or assumptions that are in place.  There may be decisions that were made in the past about our products that are no longer important or have a different goal now.  If something takes a large portion of time, it never hurts to ask if doing that is still important or if there is a different way to accomplish it.  In the worst-case scenario, you continue as is.

Wrapping Up

We are naturally wired to prevent pain, especially things we have encountered before.  Battle this tendency by embracing where those lessons can apply to upcoming work. Review upcoming work with the team and analyze it against what they are most concerned about and what will be most recurring.  

Solve the problem for 51% of situations. All other situations are special cases that must be handled as they come up! Frequently remind your team of these ideas as they plan where to optimize. Watch for a tendency to optimize for situations that are unlikely to occur in future work. Avoid solving problems with inputs by adjusting internal processes alone and occasionally question time-consuming requirements.


If you are looking for someone to help you identify ways to improve processes at your company, consider connecting with me.

Comments

Post a Comment

Popular posts from this blog

What Does a Good 1-on-1 Look Like?

Image
I have been talking about one-on-one discussions with other leaders more often lately. Nowadays, people can easily switch teams and companies, making  building a solid relationship between managers and team members more crucial than ever . Have you been wondering how to encourage your team to open up more about what's happening? Are you concerned you're losing touch with your team's day-to-day activities? Or are you aware of what they are working on but don't have enough information to determine if they're making the right decisions on the ground? You may have also noticed that your team members' skills aren't improving as they should. Regular and well-structured one-on-ones can be a great way to establish better relationships and more robust communication channels with your team. Throughout my career as a leader, I have held regular one-on-ones with over a hundred individuals and found the timing and structure that works well for me. A one-on-one is not!
Read more

Working With Your Micromanager - The Taskmaster

Image
Working with a micromanager can be a stressful experience. Especially when the manager constantly asks for updates and pushes you to meet that next date. While this can be distracting, aggravating, and demotivating, there are things you can do to make it bearable. Use this information to understand what drives your Taskmaster and how to adapt your communication style. Ultimately, Taskmasters micromanage because they are uncomfortable with uncertain timelines and outcomes. If you haven’t yet, check out this overview of micromanager types:  It's Your Fault You're Being Micromanaged . The Taskmaster Taskmasters are one of the more common micromanager traits. These managers need to know the plan and how much progress has been made. If they don’t see every step the team takes, the project's outcome is not certain enough to satisfy them. Taskmasters hold many meetings and impromptu check-ins to get updates on short-term progress. Taskmasters are battling some key concer
Read more

Hey Boss, Stop Solving the Team’s Problems!

Image
This is a weird situation. You were likely promoted into leadership because you excelled at problem-solving and getting things done. You have naturally used those skills to help your team succeed, but at what cost? Do you want a vacation, but your team stalls when you are not around?   Are there projects you can’t get done because you are busy answering questions for your team? Have you been overwhelmed by the number of decisions you have to make? How well does your team accomplish goals without you consistently following up with them? What’s the common factor in all those questions? That’s easy—it is you! Your choices and actions keep your team from sharing the burden of problem-solving. There is hope, though. You can start changing how you interact with your team to help them run smoothly, even if you cannot be immediately available. Your Job Is Not to Solve Problems First things first, it is time to acknowledge that your job is no longer about solving problems.  You are supposed to
Read more