The Trouble with Enterprise …

Many years ago, I started consulting for a startup that was mired in newly-minted technical debt. The drive for engineering help was coming, strangely, from the Director of Product, not someone in engineering. She had been reimagining their main application to be more viral. She had developed an impressive lean-startup plan for validating each features as it was built.

What she lacked was confidence in engineering. Odd things were happening in the development cycle. When a feature would be proposed by product, it could not be executed by engineering. Product concessions were necessary that would make the feature not particularly useful. For example, it was not possible to delete a record and see that deletion reflected in the app. Instead users needed to wait ten minutes and reload the page. The engineers explained that the system was not made for these real-time actions.

Usually, when someone outside of engineering wants me to come in and fix engineering, a disaster ensues. No one wants change imposed from the outside, but in this case, engineering was suffering too. The priorities seemed to shift from moment to moment. Engineers didn’t feel they had the leeway to really do their work thoroughly or correctly. Everything was a rush. The Director of Engineering was eager for change. He seemed distracted, harried, overwhelmed, but open.

Described like this, side-by-side, it sounds like the marriage between product and engineering needed couples counseling. But product and engineering worked amazingly well together. They were very collaborative. When they arrived as a team at that realization that they could not represent real time record deletions, they worked together to find the best solution that could be done.

So, why were both sides so unhappy, and more importantly what does this have to do with enterprise?

The Trouble with Debt …

Software companies talk all the time about technical debt. It is a well-worn phrase that tumbles out of the mouth as if it is also a well known idea. Developers think of technical debt as the large refactoring that their business leaders won’t give them time to fix. Non-technical leaders often think of it as something mysterious that engineers use as an excuse to not deliver. This disconnect is painful.

Both sides see debt as inevitable. When there is no time for its pay down, both sides are able to shrug it off. More than a problem that will lead to bigger problems, they treat the unavoidable debt like a religious failing, feeling appropriately guilty and then continuing with their bad behavior.

The name debt is aptly chosen. Debt has interest and that interest can compound with viral ferocity. Without careful oversight, it is very easy to become a technical nation where all the wealth goes to interest without any hope of paying off principal. The people of this nation are poor, and so lost in the struggles of work-arounds that they don’t recognize their predicament. Engineering and product at this company had fallen into that impoverished state.

I set to work with them paying down debt. It was grueling work. When we investigated the problem with non-realtime record deletions, it turned out that the team had encountered an impossibly slow SQL query that forced them to push all their database queries through Solr. So when a record was deleted, it had to rebuild the Solr index in order to then find that data. Because the index rebuild was quite expensive in time, it happened in a background process. That lead to a 10 minute delay in seeing results on the page. When we dug deeper into the original offending SQL query, we found that the join had been created incorrectly. It was returning millions of duplicate records, and choking. We were able to delete all the Solr related code.

I went home exhausted every day, having had circular discussions trying to figure out what was important. I would ask, “Why do we need to do it that way?” and the answer was, “Because we do it that way.” No one could derive the real answers, and so engineering did its best to clean up while reducing risk.

We started to see patterns in the code where the product was holding us back. The product was over-complex so the code was too.

But again, what does this have to do with enterprise?

The Trouble with Debt, Part 2 …

While technical debt is a well-worn concept with an entry in wikipedia, no one has ever approached me and said, “How should we handle our product debt?”

This company had built an advertising platform. Turnkey, white-label, managed or self-hosted, were some of their buzzwords. I don’t know much about advertising, but apparently it was a big innovative concept back then. There were two main user groups, advertising administrators and consumers. For example, a company like Starbucks, might buy the advertising platform. Starbuck’s ad professionals would use it to create coupons. Consumers who liked Starbucks would volunteer for this coupon consumption.

With two different user bases, the spread of features can get out of hand. For example, embedded in the administrative app was an email client. It started as a well-meaning, small feature. Admins wanted to be able to contact consumers within the app. The first version, which was meant to appease the asking admins, sucked. It looked like a stripped down version of an email client from years earlier. Admins balked. Lots of new emergency features were shoved into the top of the engineering workload. Meanwhile the essential things that the app needed to do, consumer advertising, was being horribly neglected. An email client did not improve consumer participation, and the admins were not gaining more data about their advertising efforts. The email client was a distraction for everyone, but it was a distraction that they wouldn’t give up.

There was a wide flourish of half-built, half-forgotten features, that nonetheless could not be removed because maybe a customer was using it.

So, how did these features take priority over the core business values? It has to do with money … and (finally) enterprise.

The Trouble with Money …

In enterprise software sales, the process is long and the price tag is crazy high. Every sales seems like a colossal win. There are seemingly endless sales meetings with seemingly endless approvers. Layers of requisitioning happen. Sometimes the IT department gets involved, with a host of scrutinies. There are lists of things the software must not do, and others that is has to do.

The most interesting thing about enterprise sales is that the buyer is rarely the person using the product. They usually have been tasked with getting a fill-in-the-blank product for the company and have a list of features culled from all the competitors in the industry. Buying is a matter of meeting to scrutinize features on the list. On the flip side, the sales process for software companies becomes explaining the product’s performance against the list of features or distracting from that list.

In this company, features on the buyers list were paramount, because sales depended on those features. After that, priority went to random features generated by sales meetings, because these could be used to distinguish from the competition. Features for the admins who were using the setup side of the app came next, because they were well connected to the ear of the buyer who will be renewing. No one was advocating for a good consumer experience except the Director of Product who was largely powerless as the sales demands were piped directly into engineering.

The Trouble with Money, Part 2 …

I advised the company to focus on the consumer and change their sales strategy to promote the product actually being effective. I was sure that eventually enterprise would realize the emperor and all his competitor’s had no clothes. They needed to be a disrupter. Isn’t that what startups do? They innovate, while enterprise acquires or buys.

The problem with startups is that they are always running two business at once. First they need to attract and maintain venture capitalists who will fund their vision. Next they have to build a sustainable business.

On a meta-level, the focus of the business is divided between two customers, just like the enterprise product is. This company had always attracted funders based on their impressive sales traction. Dumping the feature war, loosing some sales and focusing on the consumer was a hard sell that didn’t succeed. At least, that is what they told me. Of course, staying sales focused made fundraising with other venture funds less tenable.

Unfortunately, my intervention had given them the vocabulary to talk a good consumer focused game while continuing with their sales feature prioritization.

And then what happened?

I stayed connected to people at this company for around 3 years. I was able early on to work with engineering to reduce their technical debt. We created practical processes for keeping the debt down.

The product team knew exactly what to do and fought to get the consumer features in the pipeline, but the company as a whole continued to prioritize enterprise buyer demands. They went through five product owners during that time, and not because the product people left in frustration. The CEO switched people out imagining that the next magical unicorn could solve the intractable problems he had created. During that same time, they turned over engineering leaders four times, for the same reason.

So while there was a revival and a cleansing in both product and engineering, eventually the product decayed back into a state of debt, lead by their focus on short-term gains.

Enterprise buyers did eventually realize that the product and the competitor’s products did not work as an advertising platform. Since there was no product in this area working as proposed, they started thinking that it wasn’t a real product need. The market shrunk.

It may seem like the trouble with enterprise software development is absolutely everything. How can a company keep their priorities straight?

It turns out that enterprise focused tech companies often do the right thing, and succeed in business. In the last six months, I talked to two engineering managers in companies focused on high-stakes corporate sales. These companies keep their focus, most of the time, on the long-term priorities. Occasionally, sales would promise a feature not in the roadmap. The company would acknowledge this as a failure of the sales process. Then the promised feature would be done on time, and without resentment. Engineering looked to sales as the future of the company, because they wanted to be revenue generating. Sales acknowledged that product and not sales should build product.

The trouble with enterprise happens higher up when the company thinks of sales feedback as user testing; when the company prioritizes short-term gains over long-term vision. The trouble with enterprise, when it happens, is the leaders.