That's f***ing teamwork!

#team #teamwork

Our team is comprised of a team lead, four engineers, and a product owner. We've been together in our current form for around six months, and we deal with flight bookings for a Travel Management Company in the UK.

A few days ago we had a problem in an application that our team is responsible for. One of our external suppliers had (incorrectly) removed our company's access to a specific part of their API, consequently breaking our booking flow, as every booking was routed through this particular piece of functionality before being confirmed. This rendered the application in question pretty much useless, so we had to turn it off.

Two hours later we deployed a fix to production. We had to disable the piece of functionality that our supplier had turned off, but bookings could resume. In addition, we had added a feature toggle that allowed us to feed our bookings through the new flow we'd created without attempting the functionality that had been turned off, in case of this happening again in future.

The fix itself wasn't trivial, but crucially there wasn't any sense of a panicked "just throw anything at it to make it work" sort of mentality. Two of us started screen sharing so we could talk about what we could do to fix the issue, we split the tasks up, and then we made the necessary changes, whilst reviewing each other's pull requests – unsurprisingly this happened out of hours – at each step.

When I thought about it later, I realised that this situation highlighted a lot of positive things about our team. It wasn't a case of "it's lucky we do these things", it was a case of "without these things in place, this would've been a very different story":

Every member of the team is trusted to deploy to production

Our team lead didn't need to stick around and wait for us to fix this issue (although they did offer), because any one of us could have deployed this to production, and none of us would have been afraid to. I've worked in organisations in the past who treat "deploying to production" as something to be fearful of, and it's easy to be fooled into thinking that this is the right approach. But it doesn't take much to see that instilling a sensible set of practices – and empowering each engineer to be responsible for their own deployments – removes significant bottlenecks, whilst engendering a far better team culture.

We don't say "I didn't work on that bit"

I'm sure that everyone has worked on a team before where individual engineers are considered "responsible" for certain bits. "Oh, you'll have to get Alex to look at that when they come in tomorrow, that bit isn't mine", that sort of thing. We don't have that at all; we consider each one of us to "own" every bit of code the team has written, and we don't seek to blame anyone on the team for "messing it up" when things go wrong.

We are confident that any part of any of our applications will be easy to understand

This is obviously linked to the point above, but one of the things that has made our team so cohesive is that we have meaningful conversations about our coding preferences. These conversations eventually got to a point where we were able to write a team style guide based on the way we already coded, and because we had that dialogue going already, we're finding that those conversations are still happening regularly, and that style guide is still evolving, today.

This makes our pull requests very smooth. We don't have to waste time talking about naming conventions, or indentation, or paradigms, or really much of anything; our PRs get to be focused on business logic, and ease of understanding. Many of our PRs get merged without needing any comments at all, and where there are comments they never end up going back more than once.

Our automated tests give us confidence that we haven't broken anything

We care about automated testing, and we care about doing it well. And we definitely appreciate this when we don't have to go through and manually check every corner of our application when we make changes.

We enjoy each other's company enough that we were happy to stay after hours to fix a problem

That may sound trite, but this absolutely makes a difference to every single day and makes a huge difference when dealing with issues in production. No one on the team had to volunteer to stay behind and fix this problem, but there was no hesitation to do it. Our team lead has always been clear that they think team morale is of the utmost importance, and that productivity improves as a result of this being protected. I'd find it very hard to disagree.

Our team places a lot of importance on working well together, and that makes for a fantastic working environment (especially for me, as the only member of the team that is 100% remote), but more than that, it makes us far more effective – and significantly reduces our recovery time from bugs/issues – than if we were just a group of people that all worked on the same thing. Having placed so much importance on "the team" has made everything else far easier.

In case it isn't clear, I feel very lucky to be part of the team that I'm in, and it makes me feel bad for anyone who can't say the same of their own teams. If you don't feel that way, then perhaps it's worth having a serious conversation with the rest of your team about why that is. I really can't stress enough what a massive difference it makes to your code, your working environment, and your overall job satisfaction.

If you have any particularly effective habits that make your own team better, I'd love to hear them.

Top comments (8)

Yann Rabiller • Dec 6 '17

Thanks for the article. I love it. I feel like it's really close to the ideas I also shared in my series about Bus Factor ( dev.to/einenlum/lessons-learned-ab... ). It strengthens my beliefs in the team work.