Managing morale of software engineers without customers

I recently worked on a greenfield project that went almost a full year before we saw our first paying customer. I had the opportunity to work for a company that took a smart risk to re-invent its technology to compete in a fast-moving world.

The project started like any greenfield project--full of hope. Our engineering team was replete with the excitement of "doing things right." Rumors swirled about the company that all our problems would be solved "in the new architecture." Sales was chomping at the bit to have those features that had denied them that last sale. Our customer success team was looking forward to helping customers succeed and dealing with fewer issues. We would have what everyone had always wanted, without compromises. Uh...right. Right?

We had built the engineering team seeking members with the qualities of intelligence, drive, and collaboration. The team was solid. So solid, in fact, that it created some healthy, and not-so-healthy, conflict of opinion. Some team members thought certain unaddressed issues were vital and pressing issues that needed solutions. Others disagreed that they were problems at all. Members of the team pushed for what they thought would address the problems. Some of the proposed solutions conflicted and left little room for compromise. We had entrepreneurial-minded engineers (hooray!) conflicting with product management, technical leads, architects, and our leadership team. This conflict led to some painful discord between various groups. "You don't trust us." "We're going too fast." "This is a dumpster fire." "Engineers are taking too long." "Product doesn't know what they're talking about." "Executives don't care about quality." Ever heard these (or said them) before?

The Problem

The project wasn't perfect and in some cases it was messy. We had made 1,000s of significant architectural decisions in the first few months with a newly-formed team of 50 engineers in two countries. Most of the decisions were solid. Some decisions were not--and some of those were mine.

As a leadership team, we spent time mitigating these concerns through 1:1 chats, creating alignment around objectives, and repairing the most pressing decisions. The work we did was helpful in calming some of the team's anxiety and conflict. But, we all knew one thing...we needed a customer so we could move from theory to reality.

We consistently ran into two theoretical arguments.

The first type of argument revolved around guessing at what the customer really wanted in the product. This argument typically occurred between those same intelligent, driven engineers and equally attributed product managers. There was doubt as to whether we really understood the customer problem. There were arguments as to how to best solve the problem for the customer.

The second theoretical argument was debating whether a given technical decision would be sufficiently flexible and scale-able for unknown customer needs. Sometimes it felt as if the customer problem wasn't well understood, so the team felt a solution and design had to leave room for future expansion and flexibility or face major rework. Some team members were absolutely certain that the decisions we were making were idiotic and would sink the ship.

Our original project estimate put us out a year to have the features we would need to on-board our first customers. Requiring our product development team, executives, and board to wait a full year in faith would be just too long. So, we de-scoped and found a 5-month path to release.

To the team's credit, even in the face of making thousands of significant decisions and dealing with looming uncertainty, the de-scoped product was released in 5 months as promised. Unfortunately, the product features were insufficient to bring in paying customers. While we could assuage some angst in conversation, the unrest of not having a customer with whom we could test our theories continued. We had to push the product further to get a customer on board and continue without real-use customer feedback.

Resolution

After a 12 months of intense development, we released with a bang. Our first enterprise customer came on board and we started getting that long awaited nectar of customer feedback. From our first customer, we knew what was working, what was buggy, and what was scaling based on real customer-use patterns. Our executive, product, and engineering teams were having their theories tested and able to sink their teeth into live problems. Quickly following launch, more customers came on board.

Attitudes in the team improved realizing that 1) some of the things they didn't think would work did, 2) some of the things they thought would work didn't, 3) and some things they didn't think about became things they had to think about. The positive and negative feedback helped the team from across the organization gain some trust and respect in each other. The feedback even included some rave reviews from our customers around the usability, innovation, and responsiveness of the system. The team was ecstatic and ready to serve the needs of our customers.

I share this story to help others see the team-morale challenges that can result when building a product where live-use customer feedback lags.

What We Did Well

We managed to keep a developer attrition rate under 5%. We did a few things that I think worked to help hold the team's morale despite the lack of customer feedback. While not executed perfectly, these are a few that come to mind:

• Aligned the team around a common vision. We were improving patient and provider experience in enterprise healthcare. That was a great social motivation.
• Lowered the cost of being wrong. Gave them a base development approach that allowed for quick iterations. This allowed us to say, "we'll worry about it later if it becomes a problem."
• De-scoped the project to get feedback faster. Shortening the initial launch was great to validate the important features.
• Chose the right kind of engineers to take on an adventure of this complexity and intensity.

Do It Better

What would I do differently to help the team feel less anxious and more confident? I know for some I failed them and they never found solid footing. If you were on the team and are reading this, you would know I made my share. Some of the things I would do differently are:

• Tell the team ahead of time, "it's gonna be challenging with no feedback." Let them know that we'll make mistakes and we'll recover. Prepare them to challenge, but trust each other.
• Create a group of customers to get feedback earlier.  For Product: Demo mocks to that feedback group earlier. For Technology: Have technical decision makers within those customer groups to get quick feedback on what's important.
• Understand non-functional requirements (especially around scale) sooner. This would have helped us free up time by spending less time on theoretical concerns that weren't yet important.
• Spend more time educating the engineering team about our target customer and their problems. This would have allowed our engineers to be more effective and confident contributors to the customer solutions.
• Clarify technical priorities to allow teams to spend less time on certain aspects of "technical goodness" that weren't important yet.

Wrapping Up

When you don't have live customers, building the confidence of your team in each other is a special challenge. Be aware that you will need to be vigilant of this challenge in a project that will stretch more than a few months. Feel free to learn from my mistakes. And please, I'd love to know what you did or would have done differently when facing this type of challenge. Thank you!