Kevin Hughes

In any effective team a variety of people with different, but complementary, skills and experience come together to achieve a common goal. There may be overlap of skills and experience, but each person on a team will bring some strength that the other team members do not have. The team members may rotate roles as needed, but should be allowed to focus on their strengths which may preclude some members from fulfilling some team roles either by personal choice or a management decision. All should use their strengths to support the team effort – participating in idea generation, problem solving, and decision-making. They should respect and trust one another's skills and abilities, but also respect each other as people. Each should take actions and perform work that is necessary to reach team goals.

The SharePoint environment is best deployed and managed in an enterprise through the use of an effective team. In smaller deployments, one individual may take on multiple roles, but usually will be less effective in some than others – again they will have strengths as well as weaknesses. My experience leads me to believe that in an effective team dedicated to deploying and managing an enterprise SharePoint environment there are five distinct roles of an effective SharePoint team. These are Architect, Developer, Administrator, Site Designer and Manager.

This is not to say you need five individual team members, as some persons may be able to fill multiple roles, or your environment may be large enough to need multiple persons filling some of the roles. Likely roles to often cross over in a single individual team member are Developer & Site Designer, Architect & Developer, Architect & Site Designer, Architect & Administrator. Note that I didn't mention that the Manager should be one of the cross-over roles. I believe that the other four roles are often too focused on the technical aspects of the environment to be effective at managing the team. Of course there are exceptions. Also, it may appear from the example above, that the Architect role may be considered superfluous if it can cross over to most any other role. This all depends on the strengths of your team members, the size of your environment, and the goals of the team. This type of team, as any Information Technology team, is most effective if there are individuals dedicated to the separate roles, although, again, roles may shift or rotate as needed.

It's easy enough to describe these roles using technical terms, discussing programming languages, operating systems, computer hardware & software specifications, network diagrams, etc., but that is only informative to those technical enough to understand what all those things are, how they function and how they work together. Since I currently work in a firm dedicated to designing and building bridges, interstates, airports, stadiums and conference buildings, I thought I would use analogies with a civil engineering spin to describe the roles in an effective SharePoint team.

Architect -

A SharePoint Architect is an Infrastructure Architect and is very much like an architect for a highway interchange or interstate system. This is a specialist in designing transportation infrastructure to allow the most people to get where they need to go as quickly as possible as safely as possible.  He needs knowledge both wide and deep regarding the capabilities of all the associated technologies, materials and skills that go into building this infrastructure. He has to know what materials work together to create sturdy, enduring surfaces. He must know how much load they can bear at what weather conditions over how much time in order to use the correct materials for flat roads vs. overpasses vs. steep grades, in desert heat or blizzard. He must know how to take information about population distribution and growth trends and turn that into traffic patterns to be able to project and/or alleviate congestion areas. He must understand meteorology, geology, chemistry, physics, & calculus, to be able to determine grades, inclines, drainage, structural stability, wind shear, friction, expansion, etc. so that rates of speed can be maintained around curves, bridges, and interchanges without having cars slide down, or have to drive too fast to keep on the curve, or have pylons that fall under the lateral stress. He must know the men and machines that lay the asphalt pour the concrete, and hang the steel - their capabilities and limitations in order to not design something that can't be built.

He uses existing materials and technologies for his designs. He may apply them in traditional ways or come up with new innovations in how to use particular material combinations together or how to apply techniques and technologies to different materials than they had been intended for. He must keep up to date on new techniques and new technologies and also know when to phase out the old ideas and machines. He may create designs that take upcoming innovations in materials or equipment into account. He must also know when the requirements call for something completely new and different. He doesn't build the new technology or come up with the new recipe for concrete. He looks for any technology that someone else has built or that may be coming available. Or he specs out what is needed and hands that off to scientists, chemical companies, vehicle manufacturers, and steel mills to develop the new slip-resistant, super strong, last forever, asphalt guaranteed to never crack between -50 and 150 degrees.

The Architect can direct the building of the interstate. He may be able to teach others how to use the technology he's applied to his designs, but that's only because he knows how it all works together. He probably knows enough about running the machines to be able to pour concrete or lay asphalt. Maybe he even can do some steel-work. But that's not his specialty. He may know enough about so many different things that he may be able to develop his own new technology such as a new composite concrete-plastic foam mix. But, he's probably not as good at that as a dedicated scientist. He may make his interchange aesthetically pleasing or at least not offensive. But, that's not his primary concern. It's functionality and efficiency that he's after. Can he design and/or build a school? A shopping center? An industrial park? Perhaps. In a pinch. But it's not his specialty and it may not be pretty...not many like asphalt-colored grocery stores. And kids don't color within the lines – so how are they going to walk down hallways and obey all the traffic patterns laid out so nicely in yellow paint on the floors?

The Architect's customers are entire population centers, municipalities, counties, states or countries.

Developer -

A SharePoint Developer is very much like any Software Developer. And Software Developers fill the role of the scientists, chemical companies, vehicle manufacturers and steel mills in this analogy. They may be proactive or reactive. Proactive scientists and companies would come up with the new formula of asphalt because it can be done. Or, because the need is being projected for all future projects. Or because they want something to sell. Reactive scientists and companies would be taking requirements from someone, like an architect, construction companies, or even another scientist and coming up with a the new asphalt that fills their need. Oh, they need to make sure the color is right. That it hardens in a certain amount of time. That it can either be used with current equipment or they specify, and maybe even design, new equipment. They're not so concerned about existing technology unless part of their requirements require some sort of integration. They are coming up with new technology. New building materials. New machinery.

The developer has plenty of knowledge about existing technology. But probably is a little light on techniques, real-world uses, and actually applying the technology to a problem. The developer may be able to explain the uses of his new tech. Or, he may have just built it and left it to the engineers to figure out how to apply it. If making it pretty was included in the requirements he will make it pretty - but otherwise is just coming up with new, amazing things for himself or others to use.

Can the developer run the machines? Pour concrete? Hang steel? Maybe, but I would guess probably not. He knows about it and may be able to watch it for hours, but that's not his thing. That's old. It already exists. It's boring. Now what about a truck that plows the earth, breaks up rocks, unrolls rebar, pours our new quick-drying concrete, smoothes it flat, then paints those irritating lines in 7 different colors - as long as they're yellow? Hm? Call it the RoadMaster 9000.

The Developer's customers are whoever asks for, or will purchase, this new and amazing stuff he just came up with.

Administrator -

SharePoint Administrators are like any other systems administrators in IT except instead of knowing only one or two systems, they have to be skilled with 4-5 and very familiar with dozens and how they all interact. To continue the analogy, SysAdmins are like the engineers, heavy constructors, and road crews that build and maintain the infrastructure. They are there to take the designs, the machines, and the materials and come up with a plan of action, implement that plan, and get the roads, bridges, interchanges, ramps, ditches, tunnels, etc. built. They are the ones that drive the trucks, pour the concrete, lay the asphalt, weld the steel, and paint the lines. They don't come up with new designs...they just build. They may come up with more efficient methods for working. They are probably the best source of information about deficiencies in current tech or materials. They will even have great and wonderful ideas on how to improve designs, or know exactly how a plan will fail unless modified.

They know how things really work in the real world. They have to build it. Then they have to fix it when it breaks. When the deep cold creates potholes, they have to fill them. When the scorching heat expands a bridge beyond its joints' ability to handle, they repair the cracks. When the surfaces need to be stripped off and reapplied because of normal wear-n-tear, they are the ones that bear the brunt of hazardous drivers, heat, rain, and cold to tear off only the upper layers without damaging the foundation. Then they apply a new veneer using that new asphalt that someone bought for them to use. But, at least they get to drive that new RoadMaster 9000. Boy it sure can lay some road. And it's air-conditioned.

The Administrator's customers are everyone that drives down that road.

Site Designer -

The SharePoint Site Designer is very much like any other web designer - just with different tools at their disposal and a need to understand a multi-layered hierarchy for creating final pages displayed in a web browser. They are also akin to urban planners and real estate developers. They're very, very interested in that new highway system. In fact, they may have even asked for it. They certainly will take advantage of it. They don't build the roads. They use them. They don't care about what machine lays what type of asphalt in what temperature how fast. They just care that there is a new roadway system that they can build around. They design and create the places people live and work. They design and create the "surface streets" that connect to the highway system, the shopping centers, the business & industrial parks (where the developers all work), the traffic lights, the turn lanes, the parking lots. But they also design and build the houses, the restaurants, schools, grocery stores, recreation centers, hospitals, parks, and bike trails. They beautify the neighborhoods. Landscape the roadways. Erect and paint the privacy fences. Use a particular shade of red for traffic lights.

They function very much like the Architect - but their efforts are scoped and scaled to a completely different customer. Their customers are individual communities, businesses, city councils, neighborhood associations, etc. They work with the people. They listen to what the people need. They may contract the company that has the architect to design a new interchange to lower traffic accidents. They certainly complain about the potholes and traffic delays. They are the ones the people go to when they a new place to shop, a new place to work, new sewer systems, a new place for the kids to play, or a new way to get to work. They are also the ones people go to improve and revitalize the old downtown areas and make them thrive once more.

Manager -

I won't presume to tell you managers how to do your job. That is not my place. However, to differentiate the Manager from the Architect -

In this case, the manager is the strategist, the government, the banker, project management, sales, marketing, and collections. They coordinate all the efforts. Determine the rules. Set the standards. Determine the budgets. Pay the bills. Sell the product and collect the money. They know the technology and can sell it or know when someone is blowing smoke in their general direction. They know how to get things done with how many people in how much time. They know how much that RoadMaster 9000 costs. They also know where to buy it cheap. They know how many of them to buy because they listened to the engineers and road crews (SysAdmin) complain about those ancient things they had that were almost 4 years old and didn't have air-conditioning. They know how to get the money, or how to say no. They sell the architect's designs and set the schedules for the road crews. They determine when it's ok to close which lanes during rush hour so the bridge can be resurfaced and take all the heat of the whining and complaining at the city council meetings. They set the shade of the traffic lights because they need to be standardized so we can get a good price.

They tell the Designer that they can't put a chemical plant next to an elementary school playground no matter how much that business pays in taxes...wait, how much was that again? Maybe we can move the school. They set the pay scales, draw up all the contracts, procure all the resources, enable the workers, fight the unions, and wave the flag. They make sure the Architect's designs can be built within budget and that they are not so new and progressive they can't be sold. They ensure that the Developer builds things that are actually useful and sellable, that the Administrator delivers that new road on time and under budget, and that the Designer plans the community with the people in mind. No matter how pretty that tree would be in the spring it can't be in the middle of a major intersection.

But mostly, they keep the team functioning as a team. They recognize the members as individuals. They encourage them to excel and guide them to becoming better people, better employees, and better members of the team. They keep the team on track – techies tend to find tangents, over-think, and "go that-away" unless kept on the straight and narrow. Techies also tend to be a bit literal, which comes from working with computers that don't care what you meant – they know what you did. This often can lead the technical expert to misinterpretation of requirements, ideas, or anything else that isn't spelled out in writing.

The manager's toughest job is figuring out how to make the team mesh together and share knowledge and ideas. Technical experts also tend toward being very confident in their abilities and protective of their knowledge. This usually comes from very few others knowing what the techie is talking about most of the time and having the ever-present danger of someone else taking a piece of code, a drawing, or a recipe, claiming it as their own and getting credit for something they didn't do, or worse, making money from it. Too often the poor manager will be just that culprit, not necessarily intentionally, but because they are the public face of the team to customers and executives, they tend to be associated with what the team produces. And the poorer manager will revel in that glory.

Their customers are basically everyone.

Final -

So, this is my take on SharePoint teams in the enterprise. It is just my opinion based on my experiences and the stories and anecdotes related to me over the years. I'm sure there as many different opinions as there are people that care about this topic.

So, share some good times and go build an effective team – no matter the form.