How Much Automation Is Too Much?

I started working with collaboration technology in the late 1990’s, and in early 2001 was hired as a product manager to create a hosted collaboration platform. Over the next two years, while deploying our platform to customers in the US, Japan, Taiwan, and South Korea, a couple of my customers asked if I had been paying attention to what Microsoft was building. I started digging, and in early 2004 penned a whitepaper on my thoughts on the company’s latest platform: SharePoint.

A history lesson

My first real experience working with SharePoint was in 2005. I had friends at Microsoft who talked to me about it prior to then (I met Joel Oleson in August 2004, who walked me through the latest build at the time), but 2005 was my first real experience playing with it, and, more importantly, deploying it for a customer (WSS 2.0) alongside Project Server. The latter was not a pleasant experience, but I definitely caught a glimpse of the future with SharePoint. A year later, I started my job in Redmond.

The SharePoint platform has gone through some major changes over the past two decades, from a loosely tied collection of disparate tools (Tahoe), to a limited product implementation (SPS2001, 2003, and 2007), to a dynamic and powerful platform (2010 through 2019) — and even now continues to evolve as a cloud-based, evergreen infrastructural component of Microsoft 365.

At the time I got into the space, SharePoint was a much more limited offering , with specific use cases and limited options (I’m being nice) for enterprise content management and line of business application integration. Most folks took what came out of the box and chopped it up to meet their intranet needs — which caused problems later down the road when time came for upgrade, but that’s a different story. Think of it as one of those weird machine screws that requires an allen wrench, but instead you try to force it in with a Phillips screwdriver, only to strip it bare. It works fine for now, but when you find you need to remove the screw, the head breaks off and you spend hours digging into the hardwood with needle nose pliers trying to get to it and remove it.

Yes, there is some personal pain behind the machine screw story. But my point here is that SharePoint was much simpler then (albeit less functional/powerful), with more clearly defined uses. Jump forward 16 years, and we now have a robust platform that provides an exponential number of solutions compared to that earlier version.

Building on SharePoint

One of the more common “best practices” shared with SharePoint newbies is to use out-of-the-box capabilities first rather than jump straight to customizations. It goes back to the adage that a .Net developer does not equal a SharePoint developer. Yes, technically you can do what we did back in the 2003 days: utilize the basic SharePoint framework, but break the model and build over SharePoint a complex .Net-based website or platform. Because it’s just a website, right? You do this, however you’ll experience the same problems that we had back on the 2003 version — you’ll create a one-off, a custom website/portal, and potentially lose many of the core benefits of SharePoint, such as permissions inheritance and management, centralized management of web parts and other solutions, as well as consistent look and feel.

The SharePoint community has been pretty vocal on this one — I think most people “get it” that you can do a lot with SharePoint, both out-of-the-box and by building SharePoint Framework (SPFx) customizations. But the one area where we’ve seen massive change has been in our dev and IT Pro-centric views of SharePoint into an end user / employee-focus on productivity solutions. We have moved from spending the bulk of our administration time and effort to keeping the platform up and running, to a focus on delivering more value to our end users.

In my most recent CollabTalk Podcast, I interviewed Tim Kulp (@tim_kulp), Chief Innovation Officer at Mind Over Machines, and asked him the question: How much automation is too much automation? As organizations seek to improve productivity through automation, will they once again fall into the same trap that we saw with the over-building of SharePoint, creating solutions that will, once again, become difficult to manage, upgrade, or migrate?

Fundamentally, it comes down to asking questions about what you are trying to deliver, both in the short-term (productivity solutions) and the long-term (supportable, repeatable, scalable). End users often ask “can we do this?” But administrators and developers should also be asking “should we do this?”