There is evidence to suggest that many teams are currently working through a period of intensified change as the legacy of online mismanagement is finally put right.

While local considerations like company culture and internal politics can influence how Governance works, many useful insights into effective Web Team structures are also available.

In this article we will explore the configuration of a typical Web Team - including the skills, staffing, structure and leadership systems it requires.

As with so many other aspects of Web Governance, the starting point for building such a team is the concept of Website Scale.

Website Scale

Website Scale is a measure of the Size, Complexity & Levels of Engagement on a site.

The usefulness of this concept is that it exposes similarities between sites of different types and thus allows us to plan Governance for them in essentially the same way. That is, if any two sites are of the same Scale - it does not matter what they are about - they will share many similar Governance features.

Click here to learn more about Website Scale & how it influences governance in my article 'Activities, Resources & Scale: Web Governance 101'.

In rough terms there are 3 levels of Website Scale: Large, Medium & Small. For the purposes of this article I am going to use the example a Mid-Large scale site relative to the UK market. Such a site is typical of the online operations of a large corporate, a nationwide charity or a local government authority.

As a rule of thumb such sites attract between 500,000 - 1.5m visitors per month, are generally highly complex (incorporating login & personalisation features) and require a dedicated Web Team to keep things going.

Note: Please note that these traffic figures are approximations only. The aim is not to create precise numbers (though that would be nice) but to support deliberations about the type of Governance system that is needed to support your site.

To arrive at a configuration of people that is appropriate for a website of this (or indeed any other) Scale, we need to consider 3 criteria...

1. Skills & Staffing

  • What skills are needed to operate this site (based on its Scale)?
  • How much manpower is needed to ensure all operations can be completed to the quality desired?

2. Roles, Responsibilities & Team Structure

  • How should roles & responsibilities be assigned among staff?
  • How should they be structured as a team?

3. Control & Leadership

  • What overall leadership & control systems are needed to ensure the site can be managed to a high standard and achieve its overall goals?

1. Skills & Staffing

In the last article we saw that many Web Teams are run on wishful thinking.

Inadequate resourcing means that the only thing that often keeps the show on the road is the flexibility & adaptability of staff. The problem with this is that when things go wrong, they can go badly wrong.

For example, if a staff member suddenly goes sick or some new initiative demands unforeseen attention, no redundancy is available. A team that has been stretched to the limit suddenly snaps - and everything falls apart.

The aim of good people planning is to equip your team with the right number of staff and the right mix of skills in order to meet the demands of online operations.

As regards skills, it is interesting to note that the same type of core expertise is seen again and again on Web Teams of almost every scale. These skills are:

  • Content ... incl. Journalism, Social/community.
  • Design ... incl. Graphic design, User experience.
  • Development ... incl. HTML/CSS, Server-side/client-side, Database scripting.
  • Marketing & CRM ... incl. SEM/SEO, Social/community, Analytics.
  • Infrastructure ... incl. Hardware & software management, Data security.
  • General management ... incl. Strategy, Operations.

Happily, this consistency means that (despite differences in emphasis) deciding on the expertise you'll need for your team is often the easiest part of Web Governance to plan for. For a Mid-Large Scale, at the very minimum you are going the basic skills listed above.

The next step is to decide how many people to hire.

If we consider the most basic of sites - a Small Scale Brochureware site - its supervision requirements are so simple that all activity can be carried out by a single person. Indeed, it is still common to find sites where a 'Jack-of-all-trades Webmaster' designs, codes, writes content, posts on Twitter, manages analytics and a lot more besides.

Yet, this 'all-in-one' model becomes less and less appropriate as a site grows in Scale.

A single Webmaster simply does not have the time to expedite all the tasks needed to manage a large site. In addition, as a site grows in complexity, some activities demand specialist skills that probably lie outside the ability of the original 'Jack-of-all-trades'. As such, more people must be hired to keep pace with operational needs.

By way of illustration, the following chart shows how skills and staffing tend to evolve as a site increases in scale.

What we find is that as a site grows in scale, the skills of Infrastructure, Design, Code and then Content tend to emerge in (rough) order as distinct roles - and also to attract the greatest concentrations of manpower. (Other areas of expertise are either less demanding on staff or better able to scale-up as a site grows.)

Putting it all together for a Mid-Large Scale site, we arrive at a Web Team with the key roles shown below based on a manpower equivalent of approximately 12-15 fulltime staff.

  • Web Manager
  • Content Editor
  • Content Producer
  • Content Producer
  • Social Media Producer
  • User Experience Designer
  • User Experience Designer
  • Graphic Designer
  • Back-end Developer
  • Back-end Developer
  • Back-end Developer
  • Front-end Developer
  • Front-end Developer
  • IT Architecture Engineer

(Bear in mind that this is illustrative only & that other skill clusters such as Marketing or Analytics may also be observed.)

Please note I do not suggest that a Web Team with a requirement for +/-15 fulltime equivalents means that you need to hire 15 people. It is possible for your team to be smaller than that and to contract-in additional staff as needed to address short-term projects. Indeed, experience suggests it is common for between 15-30% of total manpower requirements to be met in this way. *

You should also note that the actual responsibilities of individual team members may be wider than suggested by the above descriptions. (For example, analytics may be compiled by a Content Producer even though it is not strictly a content activity.) Most Web Teams incorporate some woolliness in this regard. On the whole however, the larger a site is in terms of scale, the more specialist & focussed is each individual's role.

As such, it is important to make sure that roles are well defined and that staff understand their individual responsibilities in order to have a team that works effectively.

2. Roles, Responsibilities & Team Structure

In the last section, we saw how teams evolve as a site grows. As online activity increases, more and more people come on-board and skills begin to disperse into groups. What was once a close-knit team becomes fragmented. In order to keep pace with this change, basic Governance structures also need to be updated.

The problem on many sites is that this never happens. The result is individuals with badly described roles & overlapping responsibilities, jostling for position along unclear reporting lines.

Thankfully, this historic mismanagement is now being exposed. While uncontentious anachronisms may easily be fixed (e.g. a designer who has traditionally managed analytics but wants rid of it), it is also easy to find instances where change is vigorously resisted (e.g. a designer who wants to retain control of content rather than surrendering it to a new editor).

Indeed, wars have been fought with less bitterness than some organisations experience when attempting to update their Web Governance.

Although retraining and incentivisation can go a long way to easing transformation, in the worst cases it may be necessary to throw everything in the air and start from scratch. That is, to design a new Web Team with new roles & responsibilities and require existing staff to reapply for a position.

Inevitably this process is very painful and is likely to see some staff side-lined or excluded. But magic wands do not exist and such tribulations seem to represent the birth-pangs of a new standard of Web Governance - a standard where Web Teams have clearly delineated roles, responsibilities and reporting lines.

In this sense, it is useful to think of a Web Team as the most appropriate clustering of roles & responsibilities needed to expedite the 4 Primary Activities of Governance based on the known scale of a site.

By way of illustration, the type of Web Team that may emerge for a Mid-Large Scale site is shown below.

As may be seen the central role is that of the Web Manager (who reports to a senior executive). He/she is the individual responsible for all Governance activity on a site. If something goes wrong, the buck stops here.

The Web Manager role emerges directly from that of the original Webmaster. As the scale of a site increases, the Webmaster starts to find he/she does not have the time or skills to do everything required, so new expertise/manpower is hired in support.

Overtime more and more responsibility is devolved until the Webmaster assumes a managerial position; overseeing the activity of staff whilst driving design & development from the high end in pursuit of online goals.

It is up to the Web Manager to allocate responsibilities among his/her staff based on core competences and to structure them in a way that works in terms of reporting. Inevitably, solutions tend to cluster around common skill groupings (as above), with a senior staff member in each area overseeing activity and reporting to the Web Manager.

  • Content Editor
  • Content Producer
  • Content Producer
  • Social Media Producer
  • Senior User Experience Designer
  • User Experience Designer
  • Graphic Designer
  • Senior back-end Developer
  • Back-end Developer
  • Back-end Developer
  • Front-end Developer

As may be noted, not all roles reside fully within the Web Team. For example, external contractors may be hired to meet short term needs (e.g. to produce an online video) or internal groups may act as 'suppliers' for some services, in particular web infrastructure. **

Which is all very well - but even the most resilient and philosophical of managers may be ground down by the realities of trying to co-ordinate such a team in the face of often competing organisational demands.

For that reason, we need to add one additional and critical layer to our governance structure to ensure it has the leadership, direction and control necessary to deliver on its objectives.

3. Leadership & Control

The purpose of online leadership is to ensure that decision making systems are in place to prevent the unseemly and wasteful mess that has occurred on many Web Teams.

As online has grown in importance the realisation has dawned that a Web Team with no clear lines of authority will be pushed and pulled every-which-way as various departments vie for influence. It is no longer good enough for a Senior Management Team (SMT) to simply sign off on an annual web budget and walk away. Someone needs to be responsible.

But who?

It would be nice to say there is one group to which a Web Team should always report. The endless debate about whether a Web Team should be 'owned' by Marketing, Communications, Product or IT is reflective of this desire. Personally, I don't think anyone can give a definitive answer as too much depends on the emphasis of an organisation.

Nevertheless, a useful model for arriving at a solution is to consider whether your Web Team is primarily a 'Service Provider' or a 'Service Leader'.

Service Provider

A Web Team that is a 'Service Provider' has no mission other than to serve the needs of customers within its organisation.

The purest instance of this may be a government department where a Web Team has no independent agenda of its own - it exists merely to facilitate the Housing Office, the Water Office, the Transport Office, etc.

The Web Team may advise how to do things online (design, content, etc.), but it does not decide what to do.

In such an organisation, there is no obvious home for the web. Being a shared service, no-one really 'owns' it. As a result, it is likely to gravitate towards the department that most closely matches the type of work it undertakes.

For example, if its work is mainly communications - then PR, Marketing or Communications may take ownership. Alternatively, if its work is mainly about providing online applications, IT may take ownership. ***

Service Leader

In contrast to a 'Service Provider', a Web Team that is a 'Service Leader' has its own agenda and may work independently.

For example, a Web Team in a financial services company may be told to maximise revenue regardless of what product or service contributes to that goal.

In this sense, the Web Team operates as a standalone entity and gets to choose which departments to work with, e.g. Pensions, Credit Cards, Life Assurance, etc.

In an instance like this, it makes sense to break out a Web Team on its own and allow it to operate separately - or as an independent section within an existing department, e.g. Product or Retail.

On the whole, my own experience is that the era of IT Departments 'owning' the web has mostly expired. Web Teams that are broadly autonomous but closely linked to Marketing, Product or Communications are more common and tend to work best for the current state of online development.

Yet, no matter where a Web Team resides, strong cross-organisational links are vital to ensure multivarious needs can be met. At the highest level therefore, a structure of linked-up leadership is required, perhaps reflecting the diagram below.

In this system, leadership responsibilities are as follows...

  • The Senior Management Team approves online strategy & monitors high-level adherence to business goals.
  • The Executive (within whose remit the Web team is placed) is responsible for achieving this strategy.
  • A Web Steering Group (chaired by the Executive) brings together departments with a stake in the web in order to thrash-out development priorities.
  • The Web Manager expedities these priorities & supervises operational activity.

While ultimate online decision-making authority rests with the web executive (who reports to the SMT), this does not mean that he/she acts alone. As may be seen above, in order to ensure organisational interests can be aligned and to maintain a degree of 'online peace', a Web Steering Group (WSG) is required.

The Web Steering Group is composed of senior managers representative of all departments with a stake in the web. Its purpose is to agree development priorities, but also to act as a forum where frustrations (that could trip up the Web Team) can be aired. In this sense it acts in a 'collegial' way both as guarantor for the website and as a 'Court of Last Resort' for any conflicts that arise.

This collegial agenda is important, as there may be a temptation for the Executive who 'owns' the web to prioritise his/her department's objectives. But this cannot be allowed to occur, as the Web Team must operate cross-functionally if online is to be successful for the organisation as a whole.

Indeed, it may make sense for this to be formally iterated so that the web performance can be measured in two ways.

Firstly, performance may be measured based on the quality of web operations. All else being equal, how well does the Web Team expedite the 4 Primary Activities of Governance (based on available resources & budget). Does it make sure everything is carried out to a high standard and in a timely manner?

The Executive in charge of the Web Team is wholly responsible for this.

Secondly, web performance may be measured based on the achievement of online goals.

Responsibility for this may be shared by all members of the Web Steering Group (chaired by the Web Executive) as they have equal input into setting priorities at their scheduled meetings.

Conclusion

Inevitably, such a (short) article cannot go over all the many exclusions, qualifications and caveats necessary for the topic of Web Teams. Suffice it to say that each organisation is different and requires its own solution.

Nevertheless, there are useful patterns to follow (particularly for skills) and it makes sense to use them as a starting point on the long road to reconfiguring a Web Team.

But if it all becomes too much, don't forget the wise words of the 'Webmaster's Desiderata'...

With all its sham, drudgery and broken links,
It is still a beautiful World Wide Web!


Reply or comment on this article on my blog...