Keeping Up with Microsoft: Realistic or Not?
Have you ever had a blog thought that you spent days, weeks, and, in my case, months deliberating if you should write it or not? This is that blog. I have tossed around the idea for some time now, and only recently, after some great conversations with Christian Buckley, felt like was time to get it out there and see what kind of feedback comes in. Before I dive too deep into it, I must first clear up a few things before some people get overly excited….and not in a good way. If you know me, you also know I am a huge fan of Microsoft and all the great technology that they put out into the market. I am also a Microsoft MVP, so clearly I am in this for the long haul. However, that does not mean I can’t have an opinion on how some things are handled in various situations.
Constant Change
When I initially heard the term and theory of “Evergreen” I was excited by the fact that we no longer had to wait months or years for new features and functionality to be released. It’s like being a kid on Christmas morning, wondering what awesome new toys will have my name on them. I will admit that I am not as patient when something new is being “released soon” or is back-ordered due to high demand, and I didn’t get my order in quite fast enough. But admit it: we ALL love new shiny things!! Especially when it comes to technology.
However, as time goes on and every Tuesday there is a new change to Office 365 that adds, deprecates or modifies functionality, the harder and harder it is to keep up with this pace of change. I have participated in many presentations in the last year about how to keep up with the ever-changing O365, and they have all been great — but in every one of them, I have the same thought running through my head: “This is just like trying to Keep Up with The Kardashians.” Funny thing is, I don’t even watch the show, but know many that do, and let’s face it — social media can’t shut up about it. Never in my life would I have thought that Microsoft and the Kardashians would in any way converge, but there it is, and I’m sure that I am not alone in feeling this connection.
Keeping Up
I utilize the Admin Panel, blogs, Facebook groups, MVP sites, Teams, and other platforms that you could ever imagine, all in an effort to try and keep up. The reality is that it is impossible for individuals who are in consulting and have a 50 to 60+ hour work week to keep up with the community events and, most importantly, spend quality time with your family, which should be the most important thing. In other words, there is NO possible way to have any kind of work/life balance if things are changing weekly. It may be easier for the individuals who focus on 1 area of SharePoint or Office 365, but if you must look at the entire platform, keeping up with the rate of change (at least to the degree we did back when we just worked on SharePoint) is just not possible. On a daily basis, as I am talking to a client or a prospective client and showing them the new ins-and-outs of O365, I find something that worked a day or two ago during a different client meeting no longer works, has been moved, or is simply gone. It makes me feel a little like this:
Not Easy to Sell as Expected
What’s even more difficult is selling the concept of evergreen software. My company is about 50/50 between On-prem and O365. However, at this point I would of thought that O365 would be taking the lead. Recently, my curiosity on this data point got the better of me, so one evening I reviewed our client data and identified the ones that were “on the fence” and reviewed the notes of the various meetings we had on “what solution is best for you.” What I found is that with each decision to stay on-prem or move to the cloud, I found comments from the clients such as, “our users can’t handle that much change.” Those responses make me think of the many migration projects where companies wanted to upgrade to the next version…..but not change anything else, because that would be *too much* change. They wanted a slow, gradual, bit-by-bit implementation. Thankfully, we don’t see that many like this anymore, but clearly there are some limits on the volume of change that people can handle at one time, and the frequency of change.
Beyond volume and frequency of change, there is another piece that I feel gets pushed to the side, and I always imagine someone from Microsoft saying, “Ignore that for now, it’ll be gone soon” and that is all of the reported bugs and issues within the application. Yes, there are avenues to make Microsoft aware of bugs, and yes, some things are fixed eventually…but not as rapidly or as frequently as new functionality is released, and each release tends to come along with additional list of issues. So, between the new functionality, the changed functionality, or the deprecated functionality changes every week, we also get more issues and bugs. When do you “truly” know if it is a change that was intentional vs an oversite and a bug? The old saying “It Works as Designed” has kind of taken on a whole new meaning.
The Potential Solution
I know this sounds like I am not a fan of the “Evergreen” model, but I truly am. However, I also believe that we need to do it in a way that works for everyone. One option would be to give the consultants and community members who lead many of these deployments more insight into the roadmap so they can continue to draw new clients into the fold, and help users to get caught up on training and understand “what’s new” in each release without having to be in a constant state of regression testing.
Personally, I would like to see something like what one of my past companies had implemented which we called “Moratorium.” Starting in November of each year, all server maintenance (unless outage issue), updates, upgrades, etc. would come to a halt. They did this for many reasons, and I like them all and think they fit with this situation. First, it limited the number of mistakes that were being made as individuals were trying to work at the speed of light, so they could get their work done and go on vacation for the holidays. Ever notice how many issues occur in software at the end of each year? Coincidence, maybe…but doubtful. Secondly, it gave employees time to breathe and get caught up on tasks that were getting pushed to the side due to upcoming outages, DR testing, upgrades, etc. They could just focus on getting caught up, take some training, or read without being bothered to stay up on the latest technology, and most importantly really have dedicated time to figure out those annoying issues, error messages and bugs they so desperately needed to figure out. After the holidays, individuals are more refreshed, relaxed, and can essentially start with a clean slate for the new year.
I believe that if Microsoft was to implement something similar, they could still be considered “Evergreen,” but for a couple months of the year that had more of a focus on issues and reported bugs instead of pushing out new, changed, or deprecated functionality. Things are still ever-changing, but the changes for a brief period are for the things that cause distaste and sometimes even anger with the users. During this time, all of the consultants, administrators, developers, etc. can get caught up on all of the changes within the technology and feel like they are up to speed when communicating with others, and reduce the possibility of having to say, “Well, it worked yesterday.”
Walking into a meeting to discuss on-prem environments, my confidence level is usually very high. It’s a breath of fresh air to understand every bit and piece of the platform — because it only changes when you decide to make the change. That on-prem environment capability can go stale at times, but it is becoming a huge advantage for some clients to be fully educated on what works and what has changed. As a result, my team is fully educated, and clients don’t feel like they are adding a whole new role to their job to ensure they can stay up on all the changes, communicate them to others, update governance, and test new features with their current design, development and requirements.
Clean Slate
At times, we all need a clean slate. Wouldn’t it be nice to get caught up and have a healthy attitude, improved work/life balance, and feel confident in the technology that we support?
There is a lot of truth to what you have posted. I often mentor those coming into IT and tell them they need to try many aspects to see what is a good fit for their personally. Not everyone is a code junkie nor a hardware geek. Trying to explain these issues to newbies makes difficult for them to become experts because they don’t get the satisfaction of determining root cause. Instead, Microsoft must have changed something is now the best reply they can come up with. And leadership doesn’t like to hear that.
Thanks for the discussion
This is very true. As an MSP owner, I can only wear so many hats. For 15 years we have been repairing computers, cleaning viruses, patch management, software installs, server installs, and other misc. IT troubleshooting.
A year ago I would probably log into the Office 365 portal once or twice a week. Six month ago, I would log into the Office 365 Portal five or six times a week.
Now I am logging into client portals for Azure & 365 five or six times a day.
So, I see the light. But where does someone in my position – as the MSP owner – move forward? for 15 years I have been the expert in what we do. I have been the lead technician. Do I now become an total Azure/365 expert or do I hire someone?
Here is the next question. Who do I hire? An expert in Sharepoint/OneDrive? Intune? Windows Defender? Office 365? Azure? Is there someone who is an expert in all or do I hire experts individually?
Crazy times ahead!
I could not agree with you more. I think the cloud is failing us and our clients dismally! No other company has 50 000 engineers changing (and breaking) the platform daily. No-one has any hope of keeping up.
Long live on prem!
the SP product team has several issues (which are also common to the entire app dev industry)… developers *like* to work on new shiny stuff, they don’t like to learn and understand someone elses’ code, and they don’t like to support backwards compatibility.
the outcome is that new tools are added, instead of improving existing tools.
Examples
– workflow (wait – is that 2010, 2013, or Flow?)
– search (2007’s engine vs FAST), UI redesigns (2003, 2007, 2010, 2013)
– search results web parts (XSLT) vs content search web part (display templates), wait weren’t they originally List View templates (which were themselves designed to be extensible but never given the support)
– SSRS integration (web parts, then integrated mode, now back to web parts and iframes)
– list form templates, or was it IP forms, or FoSL, or maybe just some JS
– PerformancePoint – no, not shiny enough, let’s build a new tool called PowerBI… and apps, even though PPS had mobile support (eventually – the only update it ever got)
The “solution” is that they make things available to try, wait for community feedback… but we’re in a guessing game of knowing whether something will survive or get killed off.
what NEEDS to be done is to prioritize IMPROVING PRODUCTS instead of replacing them. This is accomplished by shifting their development from Agile to being Zero Defect (https://www.simplilearn.com/concept-of-zero-defects-quality-management-article) – basically, fix bugs before adding stuff… then address UserVoice requests on the basis that it should ENHANCE THE EXISTING rather than build something new.
This was effectively the strength of SP2007 (the pillars) and the reason it took off – all the tools of the ecosystem came together and worked together, regardless of where you were.