Building a Delivery Team
Back in March 2017 I was asked to lead a project team here at edX. We were a small team who had never worked directly together before and we had a pretty ambitious deadline of May for our first project, internationalization. Sounds like a recipe for disaster. I knew we would have to do things a little bit differently if we were going to succeed. Now cut to May where we delivered more than the original scope in time for our big international launch. Pretty great! But that’s not really the interesting part. What’s interesting is what we did differently. So let’s dive in.
Communication
In order to hit our goals we needed to figure out how to work together, fast. “Working together” really means “communicating well with each other”. So we started meeting regularly and hashing out all of the nitty gritty details that past teams I’ve been on had to figure out over the course of 3 to 6 months worth of retrospectives. This manifested itself in the form of a team charter or what we call our “How We Work” document.
Why it’s important
This document is where we all built out and agreed to all of the social norms for our team. The shared understanding allowed us to jumpstart effective communication as we worked toward our goals. There was no ambiguity about who was doing what or how to communicate something to someone else. If someone new joined the team they could very quickly ramp up and know how to contribute on this team. Additionally, it provided a venue to talk about things that I’ve never explicitly talked about with any other team before like emotional workplace safety [PDF], conflict resolution strategies, and how we like to celebrate team successes.
The thing is, your team is going to develop communication habits and their own culture with or without this document. The difference between explicitly documenting what that culture should be and letting it evolve implicitly boils down to accountability. For example, if the entire team tracks engineering progress in comments on the tickets but I only discuss progress in HipChat that might be frustrating to members of the team.
By being upfront about documenting our expectations the whole team has the tools to hold each other accountable and someone can gently remind me that using HipChat is not what we agreed upon. Without it there is nothing but personal opinion to say that I shouldn’t do it that way and the amount of friction and effort it takes to resolve becomes much greater.
Creating a “How We Work” document
That all sounds great, but how do you create such a thing? Where do you even start?.
First, a disclaimer: what went into our document was very specific to our goals and personalities. Yours will and should be different. Here are a few articles I would recommend reading for inspiration on effective team charters.
Between ideas in those articles, and our team free-form adding things we wanted to be clear on based on past team experiences, we created a pretty good list. Then we grouped those items into like categories and scheduled as many meetings as it took to flesh out each item.
Here are some important topics that our team hit upon:
- Agile process
- Internal team communication details
- External team communication details
- Logistics (meeting times, seating arrangements)
- Roles and Responsibilities
- Conflict Resolution (emotional safety, escalation)
If you are a devops team you might include on-call rotations and procedures. If you are a team without a product manager, like a performance team, you might want to be explicit about how you want to identify and prioritize work. It’s important to let the needs of the team drive the conversation more than just filling out some standard template.
Once you’ve finished creating this document it is up to the whole team to hold each other accountable to following these norms. You did remember to talk about how your team holds each other accountable, right? Good. You’ve just figured out in a week, or two, of long meetings what takes many teams many months of trial and error.
Working with Product
We are a product team, so working with a product manager is an important aspect of all of our projects. This section is still relevant for non-product teams because there is always someone playing the role of work identifier and prioritizer.
Building a good relationship with the Product Manager on your team
This is another exercise in building trust and strong communication channels. If someone on your team isn’t having at least a weekly 1:1 with your product lead you aren’t talking enough. You’ll both need to make some compromises along the way. Be honest about what your team needs and always assume best intent. Build trust by really listening to their needs and their context.
One differentiator that I think helped our team succeed was being pretty fluid about responsibilities. If there were a LOT of stories that needed to be written I would help. If I needed to focus on an engineering effort our PM would schedule meetings or send status updates that would normally have fallen to me. Having that give and take allowed us to do things that would slow down a project where everyone had rigid siloed roles. Being accountable for something getting done is not the same as being the one who has to do all of the work. I was the one accountable for making sure we have certain agile meetings the whole time, but it was nice to have someone schedule them for me when I was swamped.
Think like a delivery team first. If that email doesn’t go out it’s a team loss no matter whose job it was. If that code doesn’t ship on time it’s a team loss no matter who was assigned to the ticket.
Project Scope
Especially on a tight deadline doing early discovery and being strict about the value statement for what you’re doing is vital. When you are clear about what the value is it becomes a lot easier to understand which things are necessary and which things aren’t. One thing we stated early on was that we were not going to worry about scale. Things that work when you have 2 languages may not work when you have 30. But for now we only have 2, so we were willing to sacrifice full scalability in the interest of getting things done faster. We also agreed that if taking on tech debt saved us significant time and didn’t make “doing the right thing” harder later it was okay to take on that debt and we would spend time cleaning up after the launch. If the debt made doing the right thing harder we would opt to take the time to do the right thing.
If you can come up with some clear guiding principles it can be an effective way of thinking about the work and making decisions.
Communicating with Stakeholders
Talk to them early and often. Know whose role it is to talk to them. Make sure that you’ve correctly identified the stakeholders. Give them a plan and a clear update of what’s on track and what is changing as time progresses. I’ve found that the biggest reason this doesn’t get done is because everyone assumes that it’s someone else’s job.
But you talked about whose role it is in your How We Work document and you’re meeting regularly with that person to know if they need help with any of it and you’re willing to help because you have a delivery team mentality. You’re good.
Team Focus
There will be some hard stressful days when you are dealing with deadlines. That’s life. Team morale depends on the WHY. Why is it important that we hit this deadline instead of pushing it? Why is the work important at all?
For us we knew how this work directly related to our mission.
That’s why our work has value. The deadline was not arbitrary, it was based on impact. Launching in June after our international conference would have had far less impact than launching for that conference. The whole team was focused and empowered to make decisions because they knew the answers to those questions.
Pulling it all together
Communication is key. Set social norms based on what’s important to the team. Make sure you are all talking to each other, but more importantly make sure that you are listening to each other. Pair that with a critical eye for the value of the work you’re producing and you’ve got a recipe for a successful project with any team.
BONUS
If you’re interested in working on a team like this… we’re hiring!
