A few weeks ago, every engineer at Artsy went to work for a different team for two full days. We called it DevSwap. In this post, I’ll go over why and how we did it.
If you’ve read about Artsy’s Engineering Team before, you might know that we organize ourselves into product teams that serve different parts of our business. Today, Artsy employs 26 engineers, spread across four product teams — Publishing, Auctions, Collector GMV, and Partner Success. We also have a Platform team that is responsible for systems, infrastructure, and data, among other things. Across these teams, we share systems and apps. To stay cohesive with one another, we also have what we call “practices,” which are cross-team groups that meet and discuss shared tech.
Around two years ago, we didn’t have product teams. Back then, most engineers worked in a variety of stacks. As our business models changed, so did the way we organized ourselves. Interestingly, the number of engineers has not changed drastically, but the way we work has. We have greater focus now that we are organized into product teams with specific business goals, but that means there aren’t as many opportunities to work in other stacks.
Earlier this summer, the engineering leads received some feedback from our engineers about wanting more cross-team collaboration and knowledge sharing. In our weekly engineering-wide meeting, we get to hear what features each team is working on, but it can sometimes feel like there’s missing context. Within our practices, there is a better sense of the details, but usually the work itself is deeply nested in another team.
We brainstormed several ideas related to knowledge sharing and cross-team collaboration. What stood out the most was that being in product teams meant fewer opportunities to work in other parts of the business. This led to the question: What would happen if we redistributed ourselves into entirely new teams?
Setup
Over the course of a few weeks, the engineer leads devised a plan for DevSwap. Here are some questions we asked ourselves:
- How can we become closer as a team while learning something new?
- How can we keep ourselves as engineers nimble, flexible, and full-stack?
- How can we reduce risk in our systems by spreading knowledge?
- How can we have fun before summer is over?
For the first iteration, we decided to spend two full business days swapping. Every engineer worked with a different team. Each team contained the same number of people as the original team. The leads of each team stayed to onboard, provide support and facilitate work.
The Monday before DevSwap, we had an engineering-wide meeting to go over some guidelines and pick teams. Here are the guidelines we shared:
- DevSwap will last 2 days. 🕑
- Product managers have been notified so don’t worry about your regular work. Hopefully a new member will pick some up for you 😄.
- If possible, try and sit by your new team and if not, coordinate meeting times with remote members. 📞
- See this as a pairing opportunity! 👫
- In terms of work, it’s business as usual. Your new lead will give you guidance. 💼
In this meeting, we also had our leads “pitch” their teams. The goal of this was to get people excited about joining new teams and to get a sense of what projects they might work on. To choose the actual teams, each engineer picked their top three choices and we drew names out of a bucket. If their first choice was already full, we would place them in their next available choice. The following Monday and Tuesday, we were all writing code for different teams.
So what happened?
Our EU engineers kicked off DevSwap on Monday, tackling both the struggle of learning new stacks and being remote (our headquarters is located in NYC). Leads mitigated the latter problem by prepping EU folks on Friday so they had some direction come Monday morning.
There was lots of Slack-ing, Screenhero-ing, and pairing. It was wonderful to see people interact in a new environment with new goals, even if it was temporary. Some got to learn about how teams operate and learned about issue prioritization and even attended meetings with stakeholders.
Some people worked on modernizing codebases with projects like server-side hot file swapping and the introduction of a GraphQL endpoint to our consignments app. Others worked on building features like setting up Slack notifications when we receive customer feedback and adding ElasticSearch indexing to projects. We learned new languages by building features and updated many docs.
All work aside, the fact that we were having conversations with each other about the details of the technology while gaining a fresh perspective of someone else’s experience was valuable.
Feedback from Engineers
I learned a lot and had fun, but I wondered what everyone else thought. At the end of the second day, I sent out a survey to all 26 engineers and received 14 responses. Here are some of those results:
Did you get a chance to collaborate with someone you don’t normally work with?
Did you gain a better understanding of a piece of Artsy Engineering you don’t normally interact with?
If we were to swap again in 6 months, how long should it last?
“Would make the swap slightly longer – was a short timeframe to get through a project.”
“Onboarding took up most of the time. It was hard to get anything beyond that done.”
One clear piece of feedback was the desire to spend more time on an assigned team. Some engineers had trouble onboarding, setting up projects, and accomplishing meaningful work within the two days. If engineers can’t spin up a dev environment within a day, what does that mean for usability? These are solvable problems — we could think about dockerizing apps or having better READMEs. During the session, some folks went back to their old teams to help new members with problems. While this was great, it meant less time for their own learning. One option is to extend the duration of the swap. But by extending it too long, it could remove the hackathon mentality that kept people highly focused. It seems like a combination of tweaking the duration, providing better initial setup, and clearly communicating expectations might help for next time.
We also requested feedback on the leads. Responding to a multiple choice question about what their newly assigned lead did best, most engineers chose “Assisted me when I got stuck” and “Checked in with me frequently.” The least chosen answers were “Taught me something new” and “Made the work enjoyable.” It’s possible that taking more time to prepare for new teams (i.e. introduction meetings, dev environment setup workshop) could provide more opportunities for deeper learning.
When we asked if there were any good takeaways that could be applied to your own team, we had some interesting answers.
“Partner Success does a ‘show & tell’ where you just casually mention something you learned, dev/tech related. That was fun. We should do that on [Collector Experience].”
“Finally got to play with Redux in a production app, which I’d be very happy to see implemented in Positron.”
“I’ve been thinking a lot about GraphQL and what it could mean to the [Partner Success] team. Also thinking about what it means for Kinetic and how our projects talk to Gravity.”
Finally, what did people like most?
“Working with people that I normally don’t get a chance to work with on daily basis and also working on the areas of our systems. The fact that now each engineer knows how to setup and run another part of our system by itself is a huge win.”
“The tight time period forces projects to be very granular. It also forces repo set-up time to be minimized (e.g., via setup/bootstrap scripts, docker, etc.).”
“I liked feeling like I was able to figure out a codebase that was completely new to me and add value even in the short time that we had to work with. It made me feel like something intimidating was actually within my reach and that made me feel smart. :)”
“I wasn’t sure if we should expect to get much accomplished but was pleasantly surprised to ship a small but useful feature.”
“Awesome idea, it feels great to be part of the team that takes risks like this to increase teamwork and knowledge share among engineers and give engineers chance to get out of their comfort zone.”
Despite a few issues with onboarding and timing, it seems that most people found DevSwap to be valuable. This feedback gives us a lot to consider when planning the next one. We hope to bring it back soon!