2020-02-08~6 min

Building a Team - Part 1

If you could get all the people in an organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time.

Patrick Lencioni wrote this in his book "The Five Dysfunctions of a Team". He goes on to describe how achieve that, how to build a team where everyone rows in the same direction.

The result is an extremely effective team. Being just one such team in a company won't revolutionize industries, but it will achieve things others can only dream about.

Recently I became the lead of the frontend team at Bitmovin. Besides that there were many other changes, in total big enough that it catapulted us right back into the forming state.

team building stages

Since I'm the team lead now the responsibility to rebuild the team falls on me. I'm lucky to have amazing people reporting to me, every one of them. Otherwise this job would be a lot harder.

Now that all changes are done and the environment for the team and its members is stable again, I can start taking inventory and create a plan for change.

Current Team Structure

The team is made up of 3 fullstack developers, 1 designer, a product manager and is responsible for 5 frontend projects and about 10 backend services required to power these projects. So even though it's called 'frontend' team, we also work quite a lot on the backend.

The work we do is ok, we fulfill the business needs and are able to hold deadlines when we have them. Nonetheless there are areas we can improve upon. Most of that is how we arrive at the results.

Collection of Individuals not Working Together

First of all we are a collection of individuals, not a real team.

During the past years everyone built up their expertise in specific projects. To keep development fast people would usually work on the same projects. Everyone else would take far longer.

In itself that's not a bad thing. If there are at least 2 or 3 people who can work on each project. Since we're small that's not the case, which means that for many projects we have a bus factor of 1 right now.

We worked like that with the best intentions. It had a few unforeseen consequences though. First, it was often hard to discuss issues of a project as only one person knows about it, and backlog grooming was mostly one person talking with the product manager to figure out what is needed. No talk about how to solve it technically.

Consequently the estimates of these issues were quite big, as there was no reason to break them up. That one person will anyway have to work until it's done. For the same reason there was also no point in asking for help. The person with a lot of knowledge doesn't ask one with little knowledge for help. Brooks' law applies quite well here.

Adding people to a late project makes it later

That has the effect that we have high estimates on our issues. And we all know that humans estimating big tasks works perfectly. So there was one thing we did right, we always planned perfectly what we will do in a sprint.
Just kidding, a little bit of sarcasm thrown in. We routinely underestimated issues because they were so big. Not only that, but big issues make you vulnerable to scope creep. The feature is already so big, so why not just do this little thing, and that little thing with it?

In this setting it's not hard to imagine that we usually couldn't finish issues in the sprint, and they overflowed to the next one. Which made us simply not commit to the sprint any more. Saying that we'll absolutely finish the issues we have in the sprint with unplannable ones would create a huge amount of stress and overtime, and no one wants or even expects that. Bitmovin is a great place to work after all 🙂

We could make the sprints longer, but that would only mask the problem.

So it seems that many of our problems are caused by us having siloed expertise and would be solved by having everyone at least being able to work on all projects we have.

Problem Consequences

That's my current theory. That's what makes sense to me from the behavior I've seen. I might be wrong though, only time will tell. I'll write more blogposts on my efforts to improve the teams and report back if it really was the issue.

Having no Context of Work

Another big thing I see is that there is no shared knowledge about where we go and what goes on besides the development tasks. A lot of information the product manager and team lead have through meetings and other communication channels is not passed on to the team.

Our standup took the form of a progress report on current tasks. While that is important, it's also a missed opportunity to share knowledge and align everyone on the same goals.

Another thing that inhibited information flow was having a separate design and development sprint, with separate sprint meetings. So whenever we talked about issues, there were either designers or developers present, never both, resulting in little design<>development collaboration.

Improvements

I've written a lot now about our problems. It makes Bitmovin, or the frontend team specifically, kind of seem like a bad place to work. It's not. I wrote about them because I think it's important to acknowledge problems so that you can fix them.

The goals are clear, improving teamwork and give everyone more knowledge about what goes on around their work.

Context

No one needs to know everything that goes on in a company. That's impossible. But it is important to have some information of what goes on around you, especially if it affects your work. It's good for the company because it aligns the people with its goals so they can make the right decisions.
For example, if a roadmap view is urgently needed and Jira will have it in 6 months, there's no need in making it technically perfect since the code will be removed again. Knowing that, the engineer can separate the code so it can be dirty as hell and easily deletable.
Besides that it also makes employees happier because they know better why their work is important, and that it is important at all. Which, incidentally, also helps the company by reducing staff turnover.

So the benefits of giving employees context around their work are

  • better alignment, employees making better decisions for the company
  • higher motivation
  • lower turnover
  • increased efficiency
  • and probably much more I don't think of right now

One quick win that we can and will do is changing the format of our standups. The product manager and I (team lead) will talk also about the meetings we had and what the results are. For me that would be about changes in our processes, hiring, planned projects and so on. Our product manager can give insight into future features, how customers perceive our products and also what other product teams are doing.

The second part is unifying the design and development sprint. Having all sprint meetings together fosters collaboration, helps understanding of the difficulties the other party faces and may even create some solutions to problems that otherwise would not have come up.

Yes, sometimes when talking about engineering tasks the designer won't be able to contribute, which theoretically is wasted time. But that's hyperoptimizing to the minute which I don't think works, and anyway a small price to pay for the additional communication we get for other tasks.

Teamwork

Improving knowledge sharing is relatively easy compared to improving teamwork and well on it's way.

The root problem we have with our teamwork is that there's little shared knowledge. There are different ways to improve on that, the one we chose is pair programming. Martin Fowler wrote an excellent article about it in case you're interested. This is something new for us, and I expect it will take some time until we get it right. We didn't start with it yet, so I'll write more about it in a later blogpost.

One thing I can say though is that it will reduce our velocity in the beginning. I'm happy that we have the full backing of my manager to do it (it actually was his idea :D ). Which is crucial, without it would be a non-starter.

Final Words

Assigning tasks to people is easy. But that's not what leading a team is about. Building an real team is way harder. The feedback loops are long and problems and solutions are often not obvious. I'm glad I have an amazing manager who supports me in this journey, provides input and is someone I can bounce ideas off.