Thank you, Squarespace

I left Squarespace at the beginning of July, which brought my tenure to roughly 7 years and 8 months. Life has been a whirlwind since then - a house move, a new job, the persistent chaos of young kids - so I haven’t had much time to slow down and write about my time there.

When I joined Squarespace in 2017 I was excited for something new. After witnessing the first major round of Etsy layoffs as a manager, it was the cap to a sense of frustration and burnout that was growing for months. I resigned without a job lined up and decided to take a break.¹

I took a 4.5 month break between jobs (not having kids was truly a different planet of optionality), and while I have zero recollection of how I spent that time other than exploring food courts in Flushing, it was the reset I needed. Eventually it was time to find another job. Our pregnancy was half over and given what I already knew to be true about the unpredictable time intensity of the management track, I started explicitly looking for jobs on the IC track. I was also excited to code again. After interviewing for a bit, and a very fair and pleasant interview experience, I accepted an offer from Squarespace.

I was part of a massive engineering growth push; the mandate was to increase engineering headcount from 100+ to 300+, and I was somewhere in that range. Commensurate with that growth were growing pains: they had just split up long-standing core teams into smaller teams (with tenured ICs becoming the new Team Leads of those teams), engineering levels were recently introduced, and the manager to IC ratio was in the ballpark of ~30 -> 1. But the chaos (and most growth-related chaos) was a lagging indicator of a fundamentally successful business, so while the specifics were messy, the future was bright, and times were exciting.²

I was lucky to land on a team led by Jake, who will always be one of my favorite coworkers ever. From the start we had an intuitive alignment in technical smell, management smell, and “wtf.” I landed on a team called “Interface Architecture,” which was the team that owned all horizontal frontend concerns. Libraries, build tools, interfaces, DevEx - it all directly aligned to the work I cut my teeth on at Etsy.

Before I arrived the team had been tasked to build the first version of internationalization libraries to translate the product. I didn’t have any previous International experience, but I did have significant “roll out a technical pattern that everyone has to use and anticipate why it’ll be loved or hated” experience. And in the first couple months I remember reading the code of our translation workflow and following up with Jake in a 1:1 - “Hey man; I don’t think this will work.” I foresaw various pitfalls around determinism and DevEx that I knew would become really problematic. I had some ideas as to how the workflow could be improved, and with the team’s buy-in I started to prototype a different solution. This proved serendipitous as my parental leave was rapidly approaching and I was eager to demonstrate impact on a meaty, important problem.

In a lot of ways the translation workflow was the ideal IC project: business critical, engineering critical, far reaching in technical scope, and complicated enough that I’d think about it in the shower but bounded enough that I could make meaningful progress everyday. By the time our son was born I was very close to completion - maybe 85% - but not quite there. Thankfully during my leave a teammate of mine - Karim - took it to dev complete.

When I returned from parental leave several months later, Karim and I pushed the workflow across the finish line. Not only deploying it to prod, but creating all of the ancillary parts (docs, presentations, linting, etc) to operationalize it fully. The end result was the Unified Translation Workflow (UTW) which remains how translations are extracted and consumed across codebases today.

Shortly afterwards I was approached by someone in Engineering leadership - “UTW is a great step in the direction we’ve always wanted to go with International. Are you interested in starting and leading an International Engineering team?”

To which I replied, “can I work with Karim?”

And we were off to the races.

In a vacuum International feels like an easy and obvious growth lever – “we have a product that works very well in America, all we have to do is translate it and everyone in [countries] will love it as much as they do here!” – until companies learn the hard way that localization is not nearly that straightforward for both technical and operational reasons³:

• International customers have their own cultural norms and expectations around UX and product experience. Your core brand identity may not resonate at all in a different market. And Marketing matters - a lot!
• The same language (and numbers, dates and currencies), can be rendered and formatted differently in different locales (e.g. Spanish in Spain vs Spanish in Mexico).
• Those APIs/UIs coded 10+ years ago, that nobody on the current payroll has touched (and has no tests), that consume en-US only dates / numbers / text? They need to be carefully updated to work across all locales.
• Let’s assume most of your customers are US-based, but the company wants to strategically prioritize building for non-US. How do you incentivize product teams to deprioritize their current largest customer segment - US customers - for a promising but undeniably smaller customer segment (international markets)? How do you align that choice to their incentives?
• Are you shipping different the same product to all locales or different products to different locales? Your choice here will ultimately impact building and deploying code, monitoring, alerting, and team topology.

Ten years ago conventional wisdom in tech was to change jobs every 18 months. There are pros and cons to long tenures at tech companies, but one pro I realized at Squarespace is that a long, focused, undisrupted tenure is what it takes to realize a multi-year vision and do something really big.

When we started International the cross functional team was hilariously small - me representing Engineering, no one from Product or Design, and two coworkers from Marketing. I stumbled my way through my first reps of setting cross-functional alignment with non-PED stakeholders. I have a distinct memory of one of our first meetings where they started with their top ask: “We’d like to build multilingual websites.” To which I (too) honestly replied, “Multilingual websites?! We can’t even properly format a date!”⁴

Fast forward seven years later, and we did ship multilingual websites, in addition to a huge number of other product, engineering, and workflow improvements across our entire product suite. There was no silver bullet to making International a platform that other teams could build on - only the lead bullets of diligence and persistence over time. To get to multilingual websites, we had to build proper formatting libraries. To build formatting libraries, we had to build locale abstractions. To build locale abstractions, we had to determine how we wanted to build and deploy code for N new languages. All milestones built upon the incremental milestones before them, and powering through changes within unowned and untested codebases became less of a reluctant chore and more of a hallmark of our team identity. A shared vision and a trail of well delivered outcomes is a hell of an incentive to continue to push.

It was a massive team effort. What started as Karim and me sitting next to each other and grinding through tickets eventually grew into multiple PED triads, a cross functional effort of 100+, and 300M in revenue. We hired, transferred and promoted a talented, resilient, kind, and diverse distributed team across the US and Dublin. I worked with excellent engineering managers, engineers, product managers, designers, and localization specialists. These teams set my bar for what I now know is possible for teams at the nexus of technical rigor and psychological safety.

When International first started I would often reiterate my belief that it’d change the face of the Squarespace business, as the data around international customer growth made that seem obvious. But seeing the potential in something and realizing its potential are different. It was exciting, stressful, joyous, and frustrating, and we rode those waves together. And it’s been the privilege of my career to date to play a role in that story.

It’s impossible to catalog all of the lessons I learned at Squarespace, but some that stick out:

• Narratives run the world, and make or break teams (and companies). There is always a narrative, whether you as a leader choose to own it or not. If you do not own a narrative, teams will create one for you, and it often bias towards being uncharitable. Your responsibility as a leader is to own, and drive, a narrative.
• Nobody is more accountable to your career growth than yourself, and there is more growth outside of a career ladder than within it.
• It’s a better investment of time and energy to focus on what you can control.
• The key lesson from Covid is that work cannot happen when human needs are not met.
• The biggest cost of a leader’s unwillingness to address underperformers is the disillusionment of their highest performers.
• The greatest work life hack is to genuinely enjoy the company of the people you interact with most.

Footnotes