The Team

Posted on August 31st, 2015 by The Erstwhile Developer

What does your team represent to the rest of your organisation? It's a question I’ve been mulling over in my head for a while now and I wanted to put those thoughts into a blog post. I’m sure that these points have been made many times, by many people, in more terse language than I, but as I'm in the process of transferring to a new team lead role myself I thought I'd take a minute to think through things again.

The anatomy of a team

I’ve been a development team lead now for a while in various guises, and at various companies in both the UK and Australia. In that time I’ve managed an interesting cross section of teams. From teams of 1 to distributed teams of 5 or more. From teams that rotate on a quarterly basis to those that are fixed but work on entirely separate projects. Every team is different, with its own dynamic and its own personality; moreover each team has been perceived differently by those around it.

Externally we may perceive any loosely formed group with a shared project as a team, but a team should be greater than the sum of its parts. There are lots of things that we can do to ensure that we have a team that is seen as being effective. This has a lot to do with the way that the team works internally but it's important to realise that your team is more than the people who you work with directly. Your (wider) team will also include PMs, designers, dev managers, QA, analysts, and Technical writers, so when we think of our team, we need to include the wider context and not just those in our immediate vicinity and how these team members view us and our work.


Building trust within our teams is one of the keys to making it effective and successful. But that trust is equally important ourside the team. As a team member I want to ensure that my team is seen as being trustworthy, a safe pair of hands that can be relied upon to deliver excellent work consistently.  For me as a team lead there are three things that I like to focus on in order to build that trust: Getting a shared understanding of problems and scope, communicating progress, and delivering as expected.

Shared understanding

Within a team we all need to trust in the direction we heading. If people don't trust or believe in the direction of the team then work can become infinitely harder. Having a shared and clearly defined goal is important

for a successful team. It's equally important that that those goals and that direction are also shared by the wider team. Without that clarity our team is in danger of of not being able to deliver as expected which will almost certainly impact negatively on the perception of the team.

To try and ensure that everyone has a shared understanding of the work my team is trying to address I now try to ensure that we have a very clear statement of the problem that we're going to be soliving. Ideally this is defined in a single sentence. Equally important is a clear and concise end goal. This definition of problems and goals helps with my teams external communication and prevents those situations where part of the business has a misplaced expectation of what the team is delivering.


A team needs clear and open channels of communication. Most team leads are acutely aware of the need to communicate within the team, we have planning meetings, retrospectives, 1:1s, standups etc to handle this but over and above our internal communication it's important to ensure that our teams keep communicating to the wider organisation. If we fail to communicate out to the wider team then it increases the chance that incorrect assumptions will be made on the status of our work, and this can lead to distrust in the team.

The place I like to start when it comes to communication is estimation. Like it or loath it people what to know when your team will be finished with a given piece of work. Without estimation this can be difficult, especially if your team is new. Spending even 30 minutes a week with your team doing estimation will, over time, give you a lot more confidence in being able talk about completion of a projec. This information can be invaluable when you need to negotiate more time to complete a given project and you'll likely be aware of that situation a lot earlier in the development lifecycle.

Estimation is great because it helps to highlight earlier when things aren't running according to plan which gives you more time to adjust and bring things back on track. Another good early indicator for project status is milestones. These are relatively easy to define, and can be communicated out to the wider team easily though any one of a number of tools. Setting regular milestones gives you a point in time to reflect and see whether you are tracking against your expectations. Missed milestones are usually an indication that you need to look at the project plan and make adjustments

Plans are constantly change and so communicating ever shifting project status is a pretty important part of ensuring that everyone is on the same page with regards to your teams work. The key here is having a centralised location for all projects. Somewhere where you can be confident that all the right people are going to see your updates.

In addition to these having regular points in which to involve the wider team is good for increasing awareness of your team, its work, and it’s current status. If you are using milestones to help track the teams progress these can be a great opportunity to run a demo to the wider team. Not only does this allow you to show the progress the team is making but it also provides an opportunity for the wider team to feedback to you and this can be useful for ensuring that you’re moving in the right direction.


Speaking of delivery, ensuring and helping to ensure others deliver and follow through is something else that is important having a team that is perceived as being effective. If the wider team can be confident that you will deliver as expected and that any problems will be highlighted and dealt with as early as possible then that can only be to the benefit of all.

Teams are often assessed on their ability to deliver, sure individual contributions are important but the whole is greater than the sum of its parts. A project is not complete unless its delivered so it’s important to help teams realise this and help them work together. Having clear goals for the work that the team is doing helps to build this sense I also like setting regular milestones which allow us to measure and communicate progression. I also started talking to my team about success, if you want to be part of a successful team - one that delivers consistently and at high quality - then it’s imperative that we deliver and to do that successfully we need to work together rather than as individuals. 

The team

A lot of what we can do to be or become part of a team that is perceived as being successful involves working with external forces to ensure that they are aware of where we're coming from, what we're doing and where we're going. In the heat of development this can be easy to forget, but if we can stay on top of our communications then it will help to ensure that our progress always meets expectations and sets the team up for success in the current and all future projects.

← back to the blog