How we built a great team in 3 months

I’m going to state the obvious – working together is hard work. You have to communicate your intents, work out internal timing issues, learn how the other people in your team work, and a bunch of other things. This can be hard in the best of times – but in our case, it was about to get even more challenging.

Our team was put together in a rush, to meet a hard deadline 3 months out. Sure, we’ve all heard about the different phases of a team – storming, norming and performing – but we had to figure out a way to deliver a great product within an incredibly challenging timeframe. The team had never worked together before, we were a good cross-functional mix of junior and senior people, and all we had in common was this one crazy mission.

Although what we developed will be a bit secondary to this article, our mission was to set up a new website (with Remix), a new CMS (Sanity), and redesign about 1,000 pieces of content within a 3 month period. It was a challenging task for even the most performant team out there, and as a new team, we knew we had to get up and running quickly.

This story will take you through some of the major things we did to build trust, gain psychological safety and start performing as quickly as I’ve ever experienced in my 10 year career.

Although there was a bit of work done previously to this team starting out, the main effort started in mid August. Initially, our team consisted of:

• Two content editors
• Two senior frontend engineers
• Two senior platform engineers
• Four fresh-outta-college engineers
• Two designers

That’s a pretty big team if you think about it 🤯 Getting to know each and every one of these people was definitely going to be a challenge, and making us work together in a performant manner even greater.

The first thing we did after an initial “who am I”-session, was to go through a pretty detailed brief of what we were expected to deliver. We discussed different tactics for how we could launch, a few technical decisions that had to be done early on, and made sure to make everybody’s opinion and voice were heard even then. This was a great way for everybody to feel included, and take ownership to the task at hand.

After the initial meeting, we started creating features, and pair programming quite a bit. We made sure to pair the senior engineers with the less experienced ones, so that everybody knew at least most of the stack and technology choices made. Pair programming isn’t a new technique, but it definitely helped us get going in a few dimensions:

1. We shared knowledge and experience more quickly: Sitting together and doing some development work is one of the best ways to share knowledge between team mates, and especially when we had both senior and junior members on the same team. The junior engineers asked important questions that often changed the direction of both the technical choices and the product as a whole, while the senior engineers shared some hard-gained knowledge to the less experienced team members
2. We got to know each other: Sitting next to somebody, working together to solve challenges, is a wonderful way to bond. We shared stories and jokes, talked a bunch about stuff outside of work, while still getting stuff done.
3. We worked across domains: Even when people weren’t pair programming per se, the engineers made sure to sit with both the editors and designers to hash out challenges together. This made the team more tight-knit, and made the feedback loop even tighter between the different disciplines.

Since we were on such a tight timeline, we knew we had to deliver. And the most important thing for a team to deliver, is that all members know and trust each other to give valid feedback, without feeling corrected when you make a mistake.

We had a bunch of activities to make this happen. One of the first things we did, was a “getting drunk with the team” night. Now, we didn’t really get all that drunk, but we definitely went out to get a few beers and share war stories from both work, studies and our personal lives. We started making inside jokes, and made sure to have a bunch of fun.

The next thing we did was to create a team logo. Since we were on a crazy timeline, and migrating to a new CMS (Sanity), we called our team “Team Insane”. We even got our own logo – and had custom stickers made for everybody’s laptops.

Having this little sticker on our laptops, made us less of a team, and more of a motley crew – we were our own little gang, and helped creating this bubble of trust and fun. It created an internal identity for us to bond around. We even made our own ugly Christmas sweaters at some point, just to drive the point home.

We were a new team, and we had no idea how to work together in an efficient way. That meant a lot of iteration. After the first couple of weeks, we had our first retrospective. That let us reflect on what aspect of the way we worked that worked for us, and where we had opportunities to improve.

One thing we quickly realized, was that we had to have complete control over our backlog. There was so much to do, and so little time, we had to make sure to prioritize our work, and re-prioritize often. That made sure we worked on the next things that led us closer to putting the first couple of pages in production, or help the editors create content quickly.

We also found that having lots of small, attainable milestones was great for keeping us motivated. From implementing the first content schema, or putting the first page in production, to launching the most viewed pages – we always worked towards meeting some small goal. And we celebrated every single time.

Getting to production early was important for us. To achieve this, we implemented some pretty impressive routing logic, where we were able to launch one page at a time, while keeping the “old” page up and running for the remaining pages.

Doing all of these things combined, let us ship quickly, and feel like we were achieving something every week – not only when we reached our deadline.

Even if we kept shipping features, we realized we had to move a bunch of content from the original CMS to our new solution. Therefore, we put aside two whole days (with a few weeks in between) to do just that.

But instead of just hunkering down, we made some pretty cool events. We called them Contentchella – a play on the Coachella festival – and dressed up as both festival goers and LAN attendees. We put on music, sourced a huge bell to ring every time we launched a new page, and just had a bunch of fun.

Even though the rest of the office might have silently hated us, we sure bonded as a team because of it. It put us in one of those modes where we put most discussions aside, and we focused on what had to be done.

Doing this was a great boost for both team morale (we got a lot of stuff done), and how we worked together. And I can’t really emphasize this enough – it was a bunch of fun!

Sharing something uncomfortable together is also a great way to bond. One quirky thing we started doing, was a daily morning status, where we stood in a semi circle and talked about what we were doing for a particular day. A standup, of sorts.

However, once we were done, we always did something weird together as a group. Examples included jumping as high as we could, doing a silly dance, dabbing and running on the spot for 20 seconds straight. What a way to start the day!

Something much more uncomfortable happened a few weeks ago. We went to Barry’s Bootcamp together. Now, if you don’t have a Barry’s where you live, it’s a super intense full body group workout session in a dimly lit room, with techno music blaring and a very fit instructor screaming at us. I’m not the fittest guy in the group, but sweating it out with my team mates definitely helped me share an even deeper bond with the rest. Hurting together helps!

When we weren’t hackathoning or jumping around, we were diligent about celebrating every major launch and milestone in our celebration channel on Slack. Doing this helped our common sense of pride, and seeing praise from our department heads and a bunch of other “top dogs” certainly didn’t hurt either.

We didn’t stop at the “big” launches – we celebrated even the small wins, like finishing designing and implementing a reusable component, improving the editor experience and improving load times. This gave us a non-stop feed of motivation, and when we had something big to share, it felt like just another win to celebrate.

At the moment of writing, we met our deadline, and launched the new website – saving the business hundreds of thousands of dollars a year, and providing a much more future-proof solution for the teams around us. We’re still working on our product, iterating and making sure everything’s as performant, accessible and maintainable as it can.

We’ll probably split the team up in the coming weeks, but having this experience with this wonderful group of people has been one of the greatest experiences of my professional life.

I hope you take this story back to your own work, and implement a few of the ideas I’ve mentioned in this article. Work to build up trust, gain psychological safety and ship features fast by working together in the closest way possible. We did it, and I’m sure you can too.