Trends in our industry, and especially in SharePoint world, go in cycles. We can all remember all too well the times when the basic principles of collaboration were reduced merely to file versioning and workflows, without any need for communication − heck, there was even a SharePoint comic suggesting it. Just to ditch this principle – in less than two years’ time – and replace it with enterprise social mantra, where the whole concept of collaboration has been reduced to *only* communication. In the SharePoint 2003 times, everybody was praising the democracy of SharePoint, where almost everyone could freely create data structures. Two years later, we promote strict governance and control as a dominant direction in SharePoint deployments. Back in the times of SharePoint 2010, there was that guy on Twitter suggesting ditching the SharePoint user interface completely, and reducing SharePoint to a set of APIs. Those were the times when everybody wanted to be a SharePoint developer. Only a few years later, we’ve got a new (this time particularly dangerous) mantra: don’t customize at all.

Well, it would not be true to claim that we don’t know where this mantra came from. It came from the highest authorities – from Redmond itself, back in the times of SharePoint 2013 and the early versions of SharePoint Online. Even if Microsoft has effectively abandoned this stance (I’ll come to the reasons for both accepting and abandoning it), a lot of my colleagues still promote it, each for their own reasons. This has been proven to be wrong, for many different reasons.

The whole reason for promoting this mantra (almost always backed with a flat, semi-humorous sentence such as “You don’t customize Word/Explorer/[Insert any other product] either”), was that customizations more often than not caused problems: problems with operations (badly developed customizations could really mess up SharePoint deployments), even more problems with migration and upgrades, etc, etc. These problems then lead to substantial risks and financial losses on all sides: for end-customers, implementation partners, and – at the end of the day – Microsoft. Each customer who didn’t upgrade to the next version of SharePoint – because existing customizations would not support it – meant a small punch in that $2 billion per year business, plus much more for the implementation partners (if they were not migration specialists, that is). So, the answer to that challenge was logical and easy, and at the same time the worst possible one: don’t customize! You don’t customize Explorer and Word!

But, even if it might sound unreasonable to us on this side of the fence, corporate intranet is a very sensitive and touchy topic with customers − especially the large ones! They are very particular about how it should look and behave, since they consider it a part of corporate identity, a “common place” for their employees, and, as such, something that needs to look and feel like *their* corporate intranet, and not some third-party feed. It is one of the major identification points of the company. Lots of my colleagues try to blame customization and branding requirements on the Corporate Communication staff, suggesting they are the only ones promoting it − this is also plain wrong. Corp Comm is tasked and paid to do exactly this, and with some very good reasons. There are numerous studies showing that corporate branding – on cars, polo shirts, and – yes – intranets, increases identification with the company, and thus employee loyalty. One doesn’t even need studies for that − just go and talk to an average Jane or Joe; they will tell you that people love to identify themselves with the companies they work for, especially the good ones – the same way they identify with football clubs.

So, customers’ requests for branded intranet, which will include their own brand, data, information and processes, are legitimate and valid. Any attempt to dismiss those requests as “overrated”, “unnecessary for internal facing sites”, “CSS showcase” which “comes from Corporate Communications” and “not really wanted” shows a lack of understanding of the corporate vibe and corporate culture. A lack of empathy, if you want. There are many reasons why some implementation partners push customers not to do customizations – it can get dirty; it is a long process; not always very well paid; and sometimes there’s a lack of knowledge and resources – but at the end of the day, each time, every of those reasons it is plain wrong.

One of the reasons why SharePoint was such a successful product from day one was the fact that customers could make it “theirs”. It was never the most user friendly, it was certainly never the fastest, but it was always theirs! Since Microsoft decided to promote the “don’t customize it” mantra for the above-mentioned reasons two-to-three years ago, we saw a sharp decline in SP Online usage in Office 365; SharePoint was the least-used product in the suite (!!!). As soon as SharePoint became “the platform” again, as soon as we got good and supported customization and development possibilities, we began to witness SharePoint Online adoption skyrocketing again, becoming the second most used product – just after Exchange. Both adoption growth and numbers of downloads of PnP (SharePoint Development Patterns and Practices) speak a very, very clear story. Customers want SharePoint, and they want it customized.

And that is what we needed from day one: if customization didn’t work properly, don’t abandon it – fix it! Microsoft has got it right now and I hope that implementation partners will follow that same path. We are customers’ trusted advisors: it is not our job to judge them, but to understand them, and to advise them and help them to implement it on a most appropriate and cost-effective way. Tell them not to use custom master pages for branding, but don’t tell them not to brand.

So, yes, for God’s sake, let’s not condemn customization, and let’s not ridicule customers who insist on it. They are right, and they have every right to do so.