When all you have is one Success, every problem looks like the one before it.

Throughout my career, many of the projects I’ve been involved with started as internally-facing greenfield projects. This granted an appreciable amount of leeway in how a project was tackled, and when we were lucky, completed. I would like to share a few of my observations related to what happens after the team coalesces, clients begin using the software, and new features and expectations arise.

When a team, especially a young or inexperienced team, has success, it is common to replicate the tooling and process used during the creation of your first victory; that’s not only what helped make the project a success, but is familiar and has a trivial learning curve for new features. Maybe non-technical members of the team are comfortable with and feel empowered to talk about the more technical parts of the platform. Perhaps managers believe the Developers can easily solve new problems since they have already tackled a few. Your customers, especially if you worked directly with them throughout the project, also feel comfortable with the Developer’s language and can relate to why a particular solution was chosen to solve their problem.

Unfortunately, after you have had success in solving a problem a specific way, it can become more difficult to see your way to a different solution for a new problem. This is especially so with a team having relatively few successes or experiences in their toolbox to draw from. Two fairly well-known anti-patterns converge in these circumstances where any new problem (X) can be solved with your existing solution (Maslow’s/Golden Hammer, or Y). In trying to replicate success, you start inadvertently skipping many of the steps that set you up for success in the beginning, notably gaining a root cause understanding of the problem you are trying to solve.

This problem can manifest itself in many different ways; these are a few I’ve noticed that stand out in my experience:

• The team is presented solutions instead of problems.
• Managers start to expect continuously increasing velocity and sprint density instead of customer value and platform quality.
• Developers not asking enough questions or “staying in their lane” instead of finding out why they are building a feature.
• Focus on features instead of value.
• Features are added without addressing platform complexity.
• Little to no collaboration in creating stories.
• Little to no time for refactoring or incrementally improving code.

Here are a few questions and comments that may be potential red flags along with a few possible strategies forapproaching them differently:

• “We need to build This”, instead of “The customer wants to be able to do That”
• “We need an automated process just like the one we just built”, instead of, “Our customers would like to find ways to improve This workflow, how can we help them?”
• “We need a new column/endpoint in our Database/Service”, instead of, “The client has a new piece of information they would like included in this report, what are some ways that we can make it happen?”
• “We already built something like this, it should take less time than the first time”, instead of, “Does it make sense to use our existing framework here?”, or, “If we make the improvements we have been wanting to make to our existing framework, will that allow us to extend the existing framework for more use cases, even if it takes longer to implement this new feature?”
• “We had 40 story points in our last sprint, let’s try for 45 this time”, instead of, “There were a higher number of bugs reported {or http error codes, or whatever measure your team uses} last sprint, let’s slow down this sprint and discover why and address how this increase occurred”
• “We got some feedback from the customer on the new page and we need to allow them to copy this report to their clipboard”, instead of, “We saw the feedback from the customer and were wondering why they need the data on their clipboard, and after talking with them, it turns out they just want to paste the data into an email and send it to the team. Let’s look at ways we can help them disseminate information to the team.”

At times, it absolutely makes sense to use familiar technology, tooling, and process. When it doesn’t, certain techniques and processes can make it easier to reduce the likelihood of falling into the Golden Hammer solving your XY problem trap. Here are a few, again just from my own experience, that may help:

• I can’t guarantee you will make friends, but try to always ask “Why”, even if the answer seems self-evident. You will likely uncover something someone did not know.
• Good monitoring and visibility will help you understand existing problems you didn’t know about; good communication and relationships with your team and customers will help you get in front of problems before they exist.
• Do not guess or assume you know what is meaningful to your customer. This is sometimes difficult, especially if you do not have direct access to your customers. If you do, talk to them, watch them (with permission), shadow them, follow-up with them, and generally be there for and with them.
• Work with agility, leanness, and a DevOps mindset. Your customers are anyone who uses your software. Your customer’s customer is a customer. If you are on the team, you are responsible for ensuring the right thing is being built. Understand the problem, understand the value, work on a solution, deliver the solution, validate that the solution works, then start again.
• Ensure your team is focused on continually learning, including technical approaches, new tools, introspection (meaningful retros), and changes to customer workflows and requirements.
• If it doesn’t need to be built, don’t build it. If it possibly needs to be built, build a minimal version and measure whether it needs to be extended. If it needs to be built in the future, build it when it needs to be built.
• Try to create a hypothesis for new features that is both meaningful to your customer and measurable by your team. After you’ve released the feature, determine both the accuracy of your hypothesis and that you positively impacted your customers.

Ultimately, we are creating products to make our users successful, fitter, happier, and more productive. We also want to feel purpose in what we do. By making creativity and problem-solving a major part of our approach to developing software, everyone should benefit by ensuring we are growing our technical skills, interpersonal skills, and our product.

Thanks for taking a moment of your time to read my observations and ideas. I would be curious to know, what your experiences are with this phenomenon? How have you dealt with it? What advice would you give teams encountering this problem?