The 31 Flavors of SharePoint Skills
Almost every day, I see a job requirement come in for a SharePoint Developer/Architect and it hits me that there is a great gap in terms of how people think they should hire for SharePoint. Equally so, I get resume after resume with this same job title, “SharePoint Developer/Architect.” This is misleading. SharePoint architects have a different set of skills and responsibilities from developers. Anyone who works with SharePoint has to become knowledgeable about a plethora of skills, to varying levels, but each person should have a primary job function. And each job should likewise have a primary goal, which in turn should set the terms for the skill set of the position to be filled.
There are a number of generalized job roles for SharePoint, which are distinctive enough as to credit a section below.
This administrator is the most numerous role, at least it should be. The admins manage the content hosted by SharePoint. Good SharePoint strategy puts user adoption as a major component for measuring success. A core tenet is to empower the users who have a vested interest in the content SharePoint contains. In your organization these people may be known as power users, or SharePoint champions. Identifying and training these people is the best way to grow your network of admins. This in turn will drive greater user adoption.
These people generally come from the business, not IT, and this best represents how SharePoint can become what the business needs it to be. IT should not be the driving force for SharePoint growth, business users should be.
Good admins need to know a few things. They should become familiar with SharePoint security and privileges. They should know the different types of lists and libraries that are available. They should know how to customize lists and sites; how to make these into re-useable site and list templates. They should learn about web part pages and the web parts available in their SharePoint environment. InfoPath and SharePoint Designer are also great add-on skills.
Admins also need to understand the new ways to store files and content. In a nutshell this is more columns and views, and fewer folders. If you have folders in a SharePoint list or library, you are generally doing it wrong.
User adoption is generally measured with metrics related to clicks and returns, and this is a good quantity-based measure. For a quality-based measure I look to how many and how empowered your Admins are.
The SharePoint Analyst
The analyst is a much passed over skillset with SharePoint. At its heart this is a Business Analyst. This role is for people who want to represent the best business interests of their client, even if the clients do not know where their own best interest may lie. They are there to make sure that every project in SharePoint is conceived with some breadth of vision. Will the changes we are doing here affect other systems or projects? Should we look at this project on its own, or should we be heady of other projects on the horizon and then assess how implement this project with the greater plans and strategy in mind? These are the type of questions a good SharePoint analyst is mindful of.
The skills that business analysts need are many. However, there are a few things they should know in particular. First they need to know the basics of Information Architecture. Yes, it sounds very complex, and it can be, but there cannot be a well-designed SharePoint solution without some basic knowledge in this area. Without this the analyst will be severely limited in knowing what is feasible within SharePoint.
The Designer aka The UX Expert
Anyone who has ever developed a fantastic custom solution in SharePoint has come across the following feedback. “Yes, yes this is exactly what we want, this is great. But it looks like SharePoint! Can’t we have a SharePoint solution that does not look like SharePoint?” Quite simply, most customers want their investments to not only work well, but to look like they work well. Not only to be cutting edge, but to look and feel like it.
In steps the designer. The designer is responsible for two key components of any web experience; the look and the feel. Let’s start with the feel as that is the key concept that is far too often overlooked. The designer wants to make every view, every tool, as easy to understand as possible. Solutions should be developed so as to minimize the need for training. When you look at a well-designed page in SharePoint you should intuitively know what you can do on it. This can be difficult and it requires a studied skill. This skillset is officially known as User Experience (UX). A great beginning resource to UX concepts is Don’t Make Me Think: A Common Sense Approach to Web Usability, by Steve Krug. It is fantastic, and it is easy to read.
Next is the look. SharePoint is notorious in terms of the difficulty to design out highly stylized sites. And while this is improving greatly in SharePoint 2013, it is still a fact of life for the vast majority and will be for years to come. Web designers are used to using fantastic design-oriented tools like Dreamweaver, but when they find themselves with SharePoint they quickly realize that this is not an option. Instead designers are forced to use function-focused development tools like Visual Studio, SharePoint Designer, and InfoPath. At best these tools have poor to mid-level design features.
The skills to master here are CSS, XSLT, Master Pages, and SharePoint Layout Pages. A great resource in terms of SharePoint specific CSS is Heather Solomon’s blog, which can be found at http://blog.sharepointexperience.com/.
Beyond these practical skills, a good designer should have some understanding of Information Architecture. IA is your strategy for maintaining and storing information to maximize the value and use of that information. Why store information in SharePoint and have it restricted so that only a few people can leverage it? IA steps in and provides models and methodologies to increase the availability of your company’s information, all the while keeping it secured and trustworthy. What do I mean by trust-worthy? Simply this, information can only be trusted if the right people provide it based on the right information. There are many strategies for providing this ease-of-mind, but know that there is no template for this, and for good reason. Every scenario is different and requires planning and thought.
A developer is a go-to position for SharePoint. There are few projects that do not require the expertise of a SharePoint developer. The developer is called on for a wide area of different types of solutions, all of which have their own SharePoint-specific needs. This person is far too often forced to act as project manager, farm architect, and UX/IA expert. In this section I will focus on the actual development skillsets someone should focus on to do well in this space.
It would be a mistake to believe that a good SharePoint developer needs to just know .NET to get by. This is absolutely not the case. Knowing .NET does not inform anyone of how to develop for SharePoint. It just provides the correct syntax. Knowing the rules to properly construct a sentence does not mean a person knows how to communicate. With SharePoint development is much more restrictive than general web development. There are more confines to work within. On the other hand, there is a lot more out-of-the-box functionality which can be leveraged than with traditional development. The value of SharePoint does not come from ease of development. Rather it comes from the ability to empower users to manage their content and their teams’ content. SharePoint developers need to learn about the strengths and weaknesses of lists and libraries, when to leverage them to store information, and when to use databases. They should become knowledgeable of the model SharePoint uses to present pages; Master Pages, Page Layouts, Web Parts and the SharePoint Ribbon. They should learn about the particular intricacies of developing in SharePoint’s version of the Windows Workflow Foundation. The way in which external data is brought into SharePoint is generally done either via Business Connectivity Services or in the case of user information, via the User Store. A good SharePoint developer needs to have a basic understanding of how this works and how to develop these solutions. Finally, there is the SharePoint Object Model (OM). This is the way you interact with SharePoint via code. Learning this will be an on the job experience, but this is the right way to develop in SharePoint.
There are a number of core development tools available. Check out The SP Developers Basic Tool Belt for a quick introduction to them.
The Farm Architect
The farm architect or the farm admin is the networking person. This person can chart out the layout of the SharePoint Farm itself. This position should not be overlooked or left to the developer, as often happens. When a company implements or upgrades SharePoint this is one of the main people to consult. The decisions coming from here have everything to do with how scalable, reliable and fast your environment will be. Getting this wrong will be costly down the road.
A good farm admin will need to have an understanding of the roles different servers play in a SharePoint farm. I would love to give a brief overview of this here, but this is complex and being brief could lead to oversimplification and cause more harm than good. In the meantime to learn more some good search terms are: Web Front-End, Application Server, SharePoint Farm, and SharePoint Services Model.
The farm admin will need to understand some basic networking items. SQL clustering, Active Directory, Claims-Based Security, Disaster Recovery (even better is Business Continuity), and Load-Balancing are good areas to have experience with. A good Farm Admin should know about Information Architecture, which I briefly described in The Designer section above.
Finally, a great skillset to beef up on for farm admins is PowerShell. The SharePoint team has put a huge amount of time and development into providing scriptable SharePoint administrative functions via PowerShell. In fact there are many things that can only be accomplished this way. Knowing how to leverage PowerShell with SharePoint will make your life much easier.
Different Flavor Combinations
Clearly there is some give or take here. There are designers/developers. There are analysts who also know a thing or two about development or networking. However some skillsets are not as complementary, the architect/developer being one.
Hopefully understanding this will help you identify the resource you need for your particular project. Or maybe it will allow you to better define your own role. Feel free to comment below, and share your own experiences regarding the demands and skillsets required of different players in the world of SharePoint.