In my career I've been part of a lot of different development teams. When working with development teams, I noticed that many teams struggle, and the source of most of those struggles is a lack of clarity. What is expected from the team or individual members? Who is responsible for which part? What is the context of the project or client and which problem are we going to solve for them?
That's why the first thing I focus on when working with development teams is creating clarity. Not just about a single task, but about ownership, priorities, direction, workflow, and communication. When there's clarity in a project, the whole project team benefits from it, including the stakeholders, and the team will be more efficient.
Without clarity, the project will drift and/or be delayed, and you might not see that coming, leaving you unable to keep people accountable. If the team members don't know what is expected from them, they won't be able to fulfil those expectations.
Clear ownership#
When looking at a project, you'll see many different parts that need to be developed, combined and delivered. Each part could be a new feature, an integration, or even a deployment. The bigger the project, the bigger the team, the more parts and the easier it is for a part of the project to drift away from its original goal.
That's why every part of the project needs someone who is responsible for it. Not in a hierarchical way, but as a practical responsibility. Every part requires someone who understands the context, is the first point of contact for that part for the team, someone who identifies risks, ensures follow-ups, and knows when something requires attention. The owner of that part can also escalate it in an early phase when serious issues or risks appear for that part, so the team is able to take action before it becomes a major problem for the project.
Clear priorities#
When developing a project, there are always many parts that need to be developed and sometimes these parts depend on each other. Some parts are more important or require research before being developed. That means that some parts need to be developed in a specific order, while other parts can be developed in parallel.
A team cannot work efficiently when everything is equally important. If the priorities aren't explicitly defined it could result in the team starting to work on parts that are less essential or on tasks that depend on other work that has not been completed yet. This significantly reduces the efficiency of the team and might even result in a project not meeting its deadline.
A significant part of managing development work is helping the team understand what the main focus is, what can wait, and what should not be done at all at this moment. This should not only be clear to a few people but to the whole team. Especially on bigger projects, it is useful to discuss this with the team to help understand the dependencies and the impact of the priorities.
Clear technical direction#
To make proper use of the expertise and experience of the developers in the team, you need to provide them the freedom to make their own decisions. When you don't allow them the freedom to make their own decisions, or you don't include them in the process, they will automatically feel less ownership over the result. Less ownership results in a team that just works on specific tasks without thinking about the bigger picture and being less motivated to achieve the goals of the project.
So you need to provide freedom to the team, but that freedom works best when the team is aware of the boundaries. These boundaries are there to prevent drift or too much focus on technical solutions instead of real product value. Otherwise, every developer may solve problems differently, which reduces maintainability and introduces more tech-debt.
That's why a development team needs to have shared standards about the main architecture, maintainability, testing, naming, reviews, and deployment. Those should not depend on personal preference, but every choice must benefit the goal of building a maintainable project that meets its goals.
Clear communication#
When talking about clear communication, people seem to solve that by having meetings. A meeting is not the same as clear communication. More meetings do not automatically result in better communication. When the project is not proceeding as it should, people tend to arrange more meetings or ask people to report more often. Those meetings usually won't solve the problem and can usually even reduce the efficiency of the team.
Clear communication in a project is about making sure the right people know the right things at the right time. Clear communication could be a single-line message on Slack, for example. A project must have agreements made with the team about how and when the team communicates. That could be daily standups, daily check-ins, weekly meetings, etc. The actual method depends on the needs of the project team, as long as it works for the whole project team.
Enough process, not too much#
A project team without processes defined won't be able to achieve the goals of the project in an efficient way. But a project team with too many processes will also fail, as they are spending more time on processes than on the actual work. So keep in mind: the goal is never to create bureaucracy, but to solve an actual existing problem. Each process introduced in the project should support the project and must not become the work itself as bureaucracy results in an ineffective team wasting time on processes that won't benefit the project or team.
The goal of each process is to improve clarity. The project team and the project itself should benefit from that process. A good example is how to team is able to perform a release. When that's properly designed and clear for the team, a release is way less scary than it is without that process. A good process should make the team faster, reduces anxiety, and makes it more reliable. That means avoiding repeated questions and unclear repeated actions, while reflecting on the process each time it is executed so it makes delivery easy and predictable.
Conclusion#
A well-organized development team is not something that will happen automatically. It requires technical judgment, rules about communication, follow-up, and a team that shares the same understanding of what good delivery looks like.
For me, managing a development team is about creating the conditions in which developers can do their best work. That means clear ownership, clear priorities, clear technical direction, clear communication, and processes that help the team move forward.