Using Our Own Software First Here at New Signature, we often say we are “drinking our own champagne!” (the exclamation point included, of course) to refer to our practice of deploying early code from Microsoft in our production environment before we do so at a customer. By contrast at many firms, especially technology firms, one often hears a different refrain of “Drinking the Kool-Aid” when it comes to new technologies pushed by any software vendors. Microsoft itself for many years referred to its own internal testing of software as “Eating our own dog food” which the less is said about, the better. Fortunately, now their beta testing group is called Microsoft Elite. It’s important to note the distinction though, between many other software vendors and Microsoft, precisely to drill down on the two metaphors at work. When referring to drinking Kool-Aid, one is consuming something sweet and pleasant, but ultimately fatal. It’s meant to convey a sense of naiveté that a more serious individual or organization would avoid. Often, it is also linked to great marketing efforts to imply that the reason one makes a decision is surface based, rather than upon deep reflection and analysis. Drinking our own champagne, has a completely different sense: one of craft and mastery. Rather then referring to a specific tragedy, every good maker of spirits knows that sometimes things will align perfectly, and other times an experiment will produce something that is less than desirable. There’s no value judgment here: every batch of champagne has potential until tried, and no one would suggest that a maker distribute bottles that had not been tested first. Historical Changes Microsoft’s investment in the cloud space has made this process far easier for us, which has increased the number of different products and services we use internally while still in beta (or alpha) code form. From operating systems such as Windows 10, to management platforms like Intune and Operations Management Suite, to more traditional cloud areas such as Azure, Office 365 and Dynamics 365 – almost every single product Microsoft makes – New Signature is testing the next version, in our production environment, before we ever migrate a single customer. Ten years ago, only a handful of codebases could be tested in this way, and experiences varied wildly between different customers. The result of all this testing is simple: we remove all of the marketing spin from our conversations with customers because we have real-world experience with deployment. We’ve essentially taken the two largest pains away from new technology deployments: we handle the change management in a robust, agile way, and where newer software tends to have fewer features, we can help customers understand where the limitations are. Bugs! I often hear customers say “well, that must mean you are forced to encounter a large amount of bugs”. While it is true that bugs exist in any software deployment, the fact that Microsoft has already tested their software inside of their own organization, before deployment to partners such as New Signature, reduces the chance of any sort of “blocking” bug we might have to deal with. A much larger issue, as noted above, is when new software doesn’t have something that customers consider critical. The great news on that front is that by enduring the pain of a missing feature (or two) for a few weeks, we can pass feedback on directly to Microsoft product teams when something needs to be prioritized in advance of general availability. Even better, most new bugs or feature gaps are often associated with new functionality in a platform, so the pain point is far more minimal. As an example, when new functionality was deployed to Azure to help manage mobile devices in Intune, any bugs or lack of control could always be performed in the legacy Intune console with full fidelity. The console was better, to be sure, but any customer that needed to keep their existing processes the same didn’t have to change a thing. Customer Champagne Finally, we work with customers every week to help them internally adopt the same sort of processes that we use at New Signature to help adoption and change management. Just as a new bit of code will be tested at Microsoft, then deployed to New Signature while still in beta, so too can code that has been made generally available to consumers widely, be deployed first to a subset of commercial users. Helping firms identify the types of staff who should receive updates more frequently (historically folks we’d call “power users”) across all lines of business can help an organization with change management concerns. From Windows to Office – selecting a subset of folks to test out new features before they are broadly deployed to an organization can help build momentum and excitement. In the past these folks might have had to break an organization’s control to get the latest and greatest, but now firms can identify who participates in various “First Release” programs to trial items before they are ready for everyone. Interested in having your organization make this transition? Reach out to New Signature today to learn how you can increase staff satisfaction, improve productivity and build a stronger business with a modern approach to software upgrades and training.