Know Thy Customers' Org Structures

Having the best technology and solution to a problem is by no means sufficient to ensure success.? If it were, we would all be using Betamax tapes today1. Anyhow, jokes aside, as engineers, completely ignoring the business side of technology is a recipe for disaster.? The day-to-day decisions we make can be made better if we take the time to understand how, where, and why our technology will be used.? Today, I will talk about one aspect of that business for enterprise management software: customer org structure and how getting it right and wrong can make a big difference for your product or service.

I’ll start with a simple example that most people familiar with enterprise software will think is obvious, but newcomers to the space take a little while to grasp.? Most IT departments of a certain size have different teams managing the network layers (switches, firewalls, DNS, etc.) and the servers/clients running on those networks.? So making a simple change like opening an inbound connection or adding a new external endpoint to an allow-list is a multi-step process involving multiple teams that typically takes several days to complete2. I can’t tell you the number of times I have hung my head in shame as I realized my team hadn’t correctly listed all endpoints needed by a new/updated feature.? This simple mistake would typically result in a planned deployment of our service being put on hold and engineers sitting onsite twiddling their thumbs waiting for a support ticket to be approved.?

Having a good understanding of our customers’ organizational structures can and should influence software design.? Recently, at Google, a determining factor in choosing one design over another was the number of different service endpoints an appliance running in a customer’s data center would need to access. We also prioritized an ‘offline-mode’ feature because we knew some customers would find it easier to use under certain circumstances.

One of my biggest professional failures was due, at least in part, to a lack of understanding of how my customers’ organizations operated.

??Back in 2010, a few years after the original iPhone had been released, it was clear that mobile devices would play a significant role in the enterprise.? At Microsoft, we had been trying to make in-roads into the market for quite some time (starting with the Device Feature Packs for Systems Management Server 2003 and the ill-fated System Center Mobile Device Manager (“affectionately” known as Scum Dumb)).? None of these offerings was particularly successful. Partly because, as a company, we were still treating phones as mini desktop computers and partly because deploying internet-facing servers on corporate networks is challenging.??

We felt we could address this by combining our System Center Configuration Manager product (ConfigMgr) and our fledging desktop management service (Microsoft Intune) in a hybrid configuration that would allow the Intune service to serve as the Internet-facing edge for ConfigMgr.? The teams joined forces, and over the course of a year, built a brand new solution that would enable ConfigMgr customers to manage iOS, Android, and Windows Phone devices.

We launched to great fanfare and watched and waited for the customers to come rolling in.? And to be fair, we had some success, but we were not getting anywhere near the attach rate we had hoped.? Over time, we found that a more significant percentage of our customers were adopting our standalone Intune solution instead of hybrid ConfigMgr – even though the former had significantly fewer features and did not scale as well.

Why was this?? In large part, it was due to our customers’ org structures!? You see, prior to iOS and Android devices showing up on the scene, most large enterprise customers used Blackberry devices.? Blackberries were primarily messaging devices, and the software integrated very closely with the customer's email servers. As such, the responsibility for mobile device management usually ended up being part of the same teams that managed email (as opposed to the groups responsible for desktop management).? Our hybrid management solution required these teams to work together – and it was often easier for the mobile device management team to just “go it alone” and use a completely separate solution like AirWatch or Intune Standalone than to try to partner with another team in their organization.

In retrospect, it is obvious, but I completely missed it at the time.? We caught on eventually, and the team shifted our focus to improving the standalone version of Intune, and we ultimately deprecated our Hybrid solution.? We continued to add desktop management solutions to Intune. Ironically, many customers face the opposite challenge today (trying to figure out ways of integrating their desktop management team into their mobile device management team).

The story above is a sad tale of what happens when we fail to take our customer’s org structure dynamics into account.? But it can go the other way, too: you can use knowledge of your customer’s org structure to your advantage.? Tanium is an excellent example of this.?

Mr. Niehaus will probably give me a hard time for this, but when Tanium first launched, it should have failed right away. ? The product used an innovative peer-to-peer system to enable IT Admins to run real-time queries on devices. Still, since it lacked many basic management features, it could not replace any of the existing tools.? This meant that customers had to keep all of their existing infrastructures and pay Tanium a bunch of extra money for a fancy query engine that brutalized their networks each time a query was run.

So why is Tanium now a $9 billion company?? Simple: they didn’t try to sell their software to the teams responsible for desktop management. Instead, they sold it to the new “security teams” created inside large enterprises to combat malware and cyber-security threats.? To these teams, the lack of integration with existing tools was a feature and not a bug.? Having their own tool to run queries and enact changes without going tough, the bureaucratic, change-adverse desktop management teams was a benefit.? So even when ConfigMgr released a similar feature, most cyber-security teams continued to use Tanium.

When I worked on the ConfigMgr team, we made sure that we sent engineers out to customer visits within their first six months.? Not to sell anything or solve an urgent support issue, but to learn and understand the mindset of the people using the product.? Building a true understanding of how enterprise customers structure their organizations is essential for every engineer working in this space.? Make sure you take the time to do it!

Be Happy!

Like this post?? Please consider sharing, checking out my other articles, and following me here on LinkedIn for more articles on software engineering and careers in tech.

Footnotes:

1. You know you are getting old when you have to start hyperlinking to stories and write footnotes to explain your analogies.? I used to tell new hires at Microsoft a story about how Microsoft saw itself as the “Anti-IBM” and was always willing to cannibalize its products to ensure success.? As part of this story, I would talk about the Word vs WordPerfect battle, but I had to stop telling this story a few years ago when I just got blank stares and realized no one knew what WordPerfect was or could conceive of even having a console-based word processor anymore.
2. I haven’t mentioned the security team yet, which feels they have the God-given right to weigh in on every decision <jk/>.

Please note that the opinions stated here are my own, not those of my company.