Forgotten Rules on Successfully Managing a Web Development Team

Every day, the majority of internet users visit a massive number of websites. Most of these sites are the end result of a team of web developers working together to build them nearly from scratch. And, as all serious sites built today (and maintained) are considered major projects due to the huge amount of code, integrations, content, database entries, etc., it’s truly impossible for them to be built by only one person. This requires a team of many people with different skill sets.

This team can consist of a manager, some developers, and a team-leader. But, at the same time, it also can consist of hundreds of managers, a small town of developers, hundreds of team-leaders and additional specialists of more specific disciplines (Business Analyst, UX Designer, Drupal QA Tester, etc.). Regardless of the size of the team, a project manager on a large site build can or will need to gradually have more and more control over the work of each new employee. Among many other best practices, this person can make their life easier by adhering to the following rules:

Every employee must know the project background and the client’s goal(s). From a practical standpoint, it should be obvious that having a general, high-level understanding outside the codebase would be helpful in making contextual designs as needed.

From a technical standpoint, this can assist developers in deciding, for example, what code pieces or sections/blocks of pages need to be built more extensible — i.e. to allow maximum customizability for the client post-site launch (i.e., needing ACF functionality for WordPress). This also helps prevent the risks faced by potential team member changes in adapting to the pre-existing code.

Five developers will not complete the task five times faster than one developer. This information is very important for estimations and managing client expectations. A team leader should know the web development team inside and out, and should, therefore, estimate the correct working volume for the scope and for any potential scope changes.

The team may feel unorganized — at first. It’s normal for this to happen at the start of working with a new full team on a brand new project. Over time, the team members will coalesce with each other as a greater quantity of the project is completed, increased communication and co-problem solving, all while becoming experts on the project itself. Have patience and work to get the team to this point as fast as possible — but not too fast — by measuring the team’s comfort (i.e., adjust the amount of text communication, meetings, and expected work to be completed to strike a balance in comfort with the project’s benchmarks and timeline).

A web development team is an organism; it can become ill or become a super team depending on many different factors. The health of an organism always affects its performance. If your team is new to you or each other, be patient. If the team was established 10 years ago and is extremely stable and dynamic, you should not try to impose your will in changing too much in how they successfully work together. Not deferring to experience and shared successes can damage your ability to effectively manage results.

After you have formed your command and assigned roles to employees, it is important to know what part of the job every developer does. He or she is not just a “a front-end developer” or “back-end developer”. The specific sections, platforms, languages, used and managed by engineers determines their much more specific role and responsibility on the project.

It’s important to always achieve this common understanding among all team members as well: who to contact first for urgent issues, who is responsible for making decisions in specific situations (see the next section), etc. The easiest way to do this is by planning from the start, and if needed, gathering a kick-off meeting with all team members from the start to voice those responsible and answer any questions (these responsibilities should be enumerated post-meeting and shared with all attendees).

On the project, someone needs to be responsible for making final technical decisions (i.e., a “senior tech lead”). Even if there are only two developers on the team, one of them should be appointed as the lead. Otherwise, project conflicts will be provided to the PM and not worked out by the technical team. Disputes can arise around any question: which tool to choose, who will do which specific task, which framework to employ, etc.. Having discussions on these items are not bad, but the tech lead must always make a competent final decision to end the debate as opposed to raising questions unnecessarily to the PM — or the client.

• It is necessary to approach the choice of senior employee deliberately and carefully based on their perceived leadership and technical acumen. Otherwise, a hidden leader can sometimes emerge who will initiate conflicts with the formally designated lead. This person can even sometimes sabotage the project and team.

It is necessary to follow the emotional mood of the team. If moments of stress or conflict in the team are not properly managed, the project participants can argue, resulting in lower-quality work (due to poor morale) and/or late deliveries. Even if team members privately do not like each other — but at the same time still perform their work — it can undermine the overall morale of the team, reducing work efficiency. Therefore, it is important to identify and eliminate these bugs in the project by reconciling the participants in the confrontation — and if not possible — withdrawing one or both parties from the project team.

These rules are simply guideposts to shepherd the way of any complex project and are certainly not exhaustive of all best practices needing to be used by a project manager in performing their role on a web development project. They are — more appropriately — a few lesser-mentioned rules that can sometimes be forgotten while managing the day-to-day progress of a balancing web development team management against client communications and expectations.