Leadership churn

There was a lot of people at the leadership level churn. Folks in these leadership roles left in the last two years:

Cofounder and COO, CTO, General Counsel, Head of Design, Head of Product, Head of Marketing, Head of Direct Sales and Head of Auctions Partnerships.

That’s almost every business, technical and product lead in the company. I’m sure everyone had their reasons for leaving, but when the folks deciding the long term vision are in deep disagreement to the point of leaving, it becomes real hard to get actual work done at the levels below them of the company.

These vision disagreements caused fissures down the orgs via job role ambiguity, low morale, or defensiveness within teams which feel threatened by the jostling. When I reflect back on how some of my work relationships soured over the last two years, I now think of them as symptoms from this cause.

There are ways to have successful teams with a good culture in this environment, effective middle management can provide clarity umbrellas under their org and on engineering we did a reasonable job there. At least, my one on ones with folks in our org treated most of these departures as abstractly related to our work. Engineering was lucky there, but it’s not great for cross company relationships when there’s a set of folks who are always safe from worries.

Now I’m on the outside, I keep tabs on how things are going at leadership level. It’s harder to know, but I generally trust my instincts. Artsy’s replacement for a COO eventually landed a new CEO instead. I’d bet this will bring about leadership stability in the company.

Perhaps that’s for the best, most folks who I talk to are optimistic.

Even knowing all this, I still bought all my stock when I left. I struggle to see Artsy failing, but maybe not to the same level of potential it used to have.

Mismanaged Introduction of a Product Org

Artsy got real far with just design and engineering. A typical tech company would have three sets of roles for the building of user-facing products: Design, Product and Engineering. At a gross simplification: What it look and feel like (design), what it should do (product) and how should it work (engineering.)

Artsy’s older organization structure stems from the perspective of Robert Lenne, the company’s original head of product and design. He built a culture of product design within the design team, effectively giving the designers in Artsy the responsibilities of what should be built within the company. This worked very well when the company was smaller, but the concept was starting to stretch at the seams as design and development doubled in size.

The answer from leadership at the end of 2017 was that we needed to split those responsibilities and become a more traditional organization structure. I agreed with this idea, we’d had real positive experiences in the past where someone had taken up a product management role within the auctions team.

The first six months at the start of 2018 of changing the team’s structure were pretty disastrous. For the first time, people who I had hired left the company and the aspects of engineering culture which I liked most took a hit from which it never really recovered from during my time. It felt like quite a lot of new people were under a lot of pressure to show results very quickly from these team changes. This pressure created incentives for people to take shortcuts, or make culture changes hard and fast without necessarily covering all their bases. People in all aspects of the business felt a loss of control and we spent a long time trying to find ways to get that feeling back. Gradually, over the last two years the organizational structure became a hybrid of the old and the new as the perspectives became more pragmatic.

Obviously, I don’t think there’s a world without pressure of some sort - but we’d had many successful and considered re-orgs within the company over the last 8 years. Every product person and most dev leads involved in figuring out what that transition should look like (myself including) aren’t with the company anymore. Looking back, I keep thinking there a few places where maybe I could have stepped up more, and I regret I didn’t. I even expressed worries about it on two years ago in On Being 31.

It’s worth stressing that Artsy engineering was in a solid place as I left, this transition happened close to two years ago and I wouldn’t have left if it wasn’t going to be OK. The folks working at Artsy today are fun, interesting and making the art world a better place. If you’re considering a job there and somehow found this first, you shouldn’t consider this to be a blocker. The company is different from when Artsy started to appear on people’s radar via our Open Source, it’s more stable and mature now - but it was just time for me and 2 years of shaky foundations was enough.

My Role at Artsy

I’m an Engineer who has been at Artsy since close to the beginning. Artsy has a few pretty complex businesses, and I’ve touched most of them in some way. I’ve always aimed to ensure that engineering in Artsy doesn’t feel disconnected to the rest of the company, and I spend quite a lot of time talking externally (I account for over a quarter of the blog posts on this site for example) about our work.

Strictly speaking, none (and all) of these are in my job role which has evolved over the years to a kind of architect-ish role of knowing a lot about everything and mainly assisting people work on those, plus making infrastructure which allow others to do more with less. Which makes leaving leaving a bit tricky, I might not own a lot of things, but a lot of my value has been in the soft-skills in-between.

On Leaving

Reasonably speaking, I’m a pretty open book. For the last 9 years I have publicly written a pretty personal annual write-up of the ups and downs of my life, my relationships to Open Source and Artsy. Almost all the engineers who I spoke to about leaving said that it generally fit with my last write-up.

However, I didn’t want to leave until I had deprecated myself.

As engineers this should be a constant goal for yourself. Doing so leaves a lot of space for personal growth for yourself and for the people who will take up the mantle after you. You should always give away your LEGO

Throughout my career at Artsy I’ve changed roles regularly as Artsy has grown and changed. When Artsy needed an iOS engineering team, I became a manager, then when we moved to React Native and de-siloed the team - we didn’t need that anymore and I went back to being an individual contributor and someone who made more sense took those responsibilities. This is one of my favourite things about start-ups, they change often. If you’re creative, put the time in and are open to being uncomfortable occasionally then there are all sorts of experiences ahead.

In 2018 what Artsy needed was someone to look holistically at the Engineering team from the inside. I picked up a chunk of soft-skill responsibilities in order to ensure Artsy’s Engineering was in tip-top shape, working on everything from hiring to team cohesion.

Rebasing Responsibilities

8 years is a long time! I found quite a few ways to distribute my responsibilities, these aren’t just useful tactics if you’re leaving, but valid when your circumstances change.

Split your roles into smaller pieces, and with a tighter and more obvious scope

A good example of splitting roles came from owning all of the front-end practice at Artsy. Effectively making sure we had common goals and were sharing our best ideas across web and mobile. I realised that there were people interested in owning subsets of the global front-end practice and if I split it into web and iOS they would have the opportunity to give each platform more focus.

Build process changing tools, use them yourself to set an example, then lay off the gas

Throughout 2018 I spent a lot of time improving Artsy’s engineering culture, mostly using RFCs. In 2019 I stopped creating new RFCs and only worked on RFCs as a co-signer which was owned by someone else.

In 2019, we started to see a much more diverse set of engineers writing new RFCs which give the team access to a lot of new and interesting ideas and the RFC process has never been as active. I’m really proud of the work others are doing with this process.

Create working groups to allow many people to work on a problem collectively

I have always been a good fallback for ownership of projects which fall between the gaps between teams. For example, I own our company dashboard and our internal team navigator. While these projects are important but they would really need an engineering focused on internal tools to get changes added to a roadmap. Given Artsy’s size today, that’s not likely to happen.

To try mitigate a single point of failure, I created one of the first engineering working groups in Artsy. With the focus being an intersection between our workplace team and engineering to keep track of any high impact easy wins for internal culture. Anyone was welcome to join from engineering, and over time new folks started showing up and helping.

Since then working groups have popped up everywhere in Artsy,

Mentor potential successors

I didn’t expect anyone to directly replace me, but this is a common tactic when leaving, but when someone shows any related interest - dive in and offer anything to help them. Mid 2018 I opened up some extra 1 on 1 spaces in my calendar (by consolidating them all to one single day every 2 weeks) and specifically targeted folks who I think would do a good job at taking some of responsibilities over time.

On top of that, we specifically targeted getting at least one person who would care about tooling in a way that echoes my opinions when hiring, and that worked out well. I’ve always been a fan of hiring around missing skillsets and strengths, and this can narrow the gaps.

Document everything

If you do enough defensive OSS, you learn the value of the up-front cost of docs vs long term questions from people. Even internally I try to write docs for someone’s question rather than answering directly either through GitHub gists, or docs sections on particular areas of code. This pattern of externalizing answers inspires a hefty amount of my blog posts on the Artsy blog. While writing this way can be slower, that answer can be more thoughtful, better articulated and externally visible. In engineering we rarely face a truly unique problem.

Given I was planning on leaving then, I took the time to focus a lot of Artsy’s documentation across all of engineering into two centralized places (one in the open (default) one private (fallback)) which dramatically increased the number contributors to team documentation across the company.

In terms of code documentation, I ended up sneaking documentation updates to as many projects as I can. For example, on a project with a pretty low number of contributors, a new idea I had on a pretty isolated project was specifically aimed at providing coverage of features per-screen.

Cleaning the backlog

When there’s a time limit, it really helps you focus on getting some of those long running PRs in. I shipped a feature that I had been working on and off for 5 years last month.

I went going through a process of hitting all my backlog posts for the Artsy blog, as well as trying to cement the reasoning for technical and cultural choices which I think are worth keeping around. Ultimately though, it’s up to the rest of the engineering team to decide whether a cultural pattern is worth keeping or a project is worth maintaining.

Give your company the best chance to make a competing offer

I wanted to give Artsy the best chance to compete with an offer like the one from TypeScript. One of the best strategies for this came up when speaking with Samuel, our VP of Engineering. He recommended that I imagine that I didn’t work at Artsy, and figure out the job role which would be the most attractive to me.

We explored this idea and created a really compelling job role which fit for both Artsy and me. It was a refreshing take what I’ve enjoyed from my time with Artsy, and things I’m interested in doing in the future. It ended up like this:

## Head of OSS at Artsy

Roughly:
- Make Artsy OSS Awesome
- Help ship big things in parallel work streams with product
- Make it fun and full of growth to be at Artsy

Goal: Ensure Artsy OSS thrives.
Aim: Externally cement that Artsy's tech credentials are solid, and provide external stimulus for Art-world folks to work with us

- ~ 4–5 tech conference talks a year
- ~ 1-2 arts conferences/fairs/panels a year
- ~ 12 solo blog posts per year

- Also:
  - Ensuring every major tech launch has a write-up (e.g. New Selling Options, Show Guide )
  - Ensuring all libraries we OSS are documented, tested, and usable outside of Artsy
  - Helping internal engineers from those teams write public talks about the launches and what we had to build

Goal: Help ship longer-term perspective which runs parallel to the roadmap
Aim: Help make the team make less short-term choices

Work with one other person to ship some of the things Artsy has found difficult to work due to
roadmap tradeoffs, but that we feel needs to get done eventually:

- Explore building standalone services for model domains (artworks/partners/shows etc)
- Work on how we can we standardize admin UIs
- Provide a technical roadmap, and own what it takes to ship an android app
- Own the third party API (handle legal rights, own docs + evolution)
- Consolidate JS tooling into something which sits above express/rails/react-native

These are projects we've regularly said "want to do that, but it'd block shipping X or Y", where
as a team we consciously decide to continue a larger technical debt in favour of shipping something.

Goal: Maintain and improve Artsy's culture
Aim: Make Artsy feel like an awesome place to work

Run events:

- Demo Days
- Lunch & Learns
- Provide more support to initiatives like Artsy Learns to Code
- Explore

Cohesion:
- Focus on 1on1s with product + designers to help them grow
- Run workshops for all of Artsy to help raise technical awareness

This takes some of the things I was already doing on the side, and moves them forefront as well as trying to work well with the rest of the company and ship some big things. I think the idea of “what is an optimal offer for your current company” is a pretty good pattern for anyone who has a long tenure at a company to explore. It gives your current company a way to show off it’s best attributes and you already have the existing relationships to make it work.

Looking at it 6 months later, it feels a lot like a mix of internal cheerleader, ad-hoc contributor and dev-rel. Had I been hired into that without the baggage of many years, I’d probably have loved it.

Letting People Know

I spent a considerable amount of time thinking about this. I’m not sure there’s a perfect way, but I can at least talk to what I did. I had a few aims: tell people individually then in groups, strive for as natural a setting as possible and make it easy to know who knows so far.

I structured my timeline to look roughly like:

• Inform my manager + direct collaborators when I was taking informationals (maybe 2-3 months prior to signing)
• 1st week after signing - all collaborators, this came to roughly 120 people across the company
• 2nd week, Monday - ensure all dev knows by announcing it at our team stand-up
• 2nd week, Tuesday - email most of the team
• 2nd week, Wednesday - let the internet know

For the first week I used a private slack channel (called the oort-cloud) where I added people as I told them, it turned into a pretty fun support group channel for light-hearted jabs and interesting discussions.

A week is quite a while to keep the announcement somewhat secretive, but in general it held. This gave me the chance to answer a lot of questions, and I came home drained every night. I feel like I did the right thing.

Final Days

When I considered what the right thing to do with my final days, I felt tht some of the best value I can give to Artsy is in providing historical context. That’s why I’ve been shipping so many blog posts in 2019. I’d like to try dig deeper and pull out some interesting stories from other long-standing at the company. I took the time to improve our alumni network (poke me if you’re not in it, it’s hard to keep track on the outisde), so it’ll be easier to keep in touch with Artsy folks in the futurer because I’m going to miss a lot of them.

I got a lot of recommendations to take time off between jobs, considering I have been focusing my thinking around Artsy for a very long time then finding a mental space where you can ercharge sounded compelling.

It sucks leaving because I feel like I knew almost everyone in the US office, it was just about the dunbar number and I felt like I knew how most people ticked. I loved company-wide events and hanging out with all of the other teams in the company. As Artsy was mission driven and the mission was easily applied to most of our jobs then, a lot of people were really trying to improve interacting with the art world. I’m proud that I got to hang out with all these folks and got to know a lot of them really well. It can be easy to just stay in your lane, but I got a lot of friendships by not doing that. 6 months on, I still to try find a reason to go back for events every 2 months or so.

In the last year, I spent quite a lot of time trying to dig into the history of Artsy to make it easier for others to get context on what we built in Engineering. One of my favourite examples of this is the highlights document I created for Artsy engineering. This document showcased most pivotal moments in Artsy engineering, or at least the ones I could remember (and could poke others into adding) - I’m looking forward to seeing it in a few years time when someone else picks it up and tries to match the timelines.

We really did make something special with the iOS team, and we kept our global reputation as we moved from a native focus to react native one. We were a diverse team with everyone having some polymathic tendencies. That made it a pleasure to get up for work every day. It’s kinda intense that for 4 years the iOS team was a tight team, then within a year all but one of us left the company.

I scheduled my final day to correspond with a regular internal event I used mc and booked myself a speaking slot in it. I used it cover all of the projects I had worked on and how proud I was to have worked with everyone, and wrapped it up with an anecdote that now everyone gets to be orta. A friend followed up that I should make stickers with that phrase and now they’re everywhere in the company.

Interviewing

I chatted with Artsy’s leadership folks last year about planning on leaving, and I did the same at the start of 2019 too. In part, I was open to changing my mind but things just didn’t really fit anymore. One of the main reasons I stayed through 2018 was to ensure that leaving didn’t break things. I’m sure there’s the occasional “argh, this is an orta” thing happening in the dev team, but I think the time I spent on trying to leave elegantly was worth it.

I’d been wondering what to do next for a year or two. Danger and I narrowed my ideas down to three main options:

• I stay full-time employment and we stick in NYC (because I like NYC, and the city is kinda growing on Danger)
• We both take a break from work and take a break year
• We move back to small-town england, and I try take Peril full-time

While you might know the end-result, these were all pretty solid options. However, to get a sense of what full-time options there were I took the time to do some informational interviews at some of the places I mentioned last year.

The first was a private messaging company, and it went bad, the person on the other side of the informational hadn’t taken any time to do research on me. This was disappointing, and not even in a “I’m kinda dev-twitter famous” way. If you don’t take the time to prepare to meet someone who could be working with you for years, what other parts of the culture are not going to be thought through?

I wondered if people just take informationals less seriously than we did at Artsy. Our then CTO was adamant that we treat informationals critically as they are the first point of contact to a new hire. That night, I tried to make sure that Artsy continues to do great informationals by documenting how I prepared for informationals and calling a best practice.

The next few talks went much better. When split across many amazing opportunities with really cool folk, I had to figure out some mental tools for providing focus on what I should do. I repeatedly asked myself two core questions:

• What team would I feel the most proud to be a part of?
• What team would get the most impact from the sort of engineer I am?

Through these two questions and about 3 months of thinking, I narrowed down my set of options to TypeScript if I was going to do full-time employment. Which subsequently made the next question: TypeScript vs Peril vs a year off.

While a break would have been nice, the TypeScript team said they really weren’t sure if or when they might get headcount again. I’ve been in that position, and I could empathize. Given that the timing was lucky for me and it was something I really wanted to do. I said let’s give it a shot.

Peril would have been an interesting choice, months later GitHub continued to do an even better job at replicating all of the features I built (IMO these are convergent ideas, not ‘they stole my idea’) and while I could have been a niche player - that doesn’t fit my goals. I care about communities and ecosystems, building a small but well used niche tool might not satisfy my drive. Could I risk that vs working on something on TypeScript?

Why TypeScript?

Well roughly: It’s a small team building important infrastructure for a lot of people in the open. This is what I’ve done in my spare time for the last 7-8 years, and maybe it can work out for full-time work too.

If you don’t know what TypeScript is, I’d recommend reading this non-technical post on what TypeScript is and why it’s needed. I created it for Artsy folks when I was telling folks I was leaving. Basically JavaScript is the “English” of the programming world, all programmers are forced to learn it for some reason or other - no one speaks the same version but everyone kinda gets it. Like English, it’s not an elegant language. But, TypeScript is like a good dictionary and proofreader for your writing, and it turns out you can make some extraordinary prose with time and patience. TypeScript makes that easier.

I have a fundamental love for developer tooling, and arguably a programming language is the purest form of tooling. Within the JavaScript eco-system, TypeScript found its niche by accepting the flaws in JavaScript. TypeScript goes out of its way to not fundamentally change the language. The compiler will give you warnings if it thinks you’re doing something you shouldn’t, but it kinda lets you just get away with whatever you want.

This idea of acceptance extends really far, to the point where most developers using JavaScript are probably using TypeScript with the errors turned off and don’t know it because their editor is doing it “for free”.

Before interviewing I had my reservations about Microsoft, but once I realised it might be a real option I started to do more research than my simpler idea of “TypeScript and VS Code are good, so maybe Microsoft has changed?”. Now I’m fully indoctrinated, but it doesn’t feel like the evil empire borg from the slashdot era. Microsoft lost, and got humbled - that’s better for everyone.

Life at TypeScript

I started in June. I joined the compiler team, which means I work on a program which “compiles” text written in the TypeScript programming language into a database. This database is used to create something a machine can easily understand, and to provide information back to programmer’s test editors.

The TypeScript team is a different bag culturally from the Artsy Engineering team. The TypeScript team is full of incredibly smart engineers with an exceptional depth in compilers, type-theory and JavaScript’s underlying warts. Months into joining this team I’m regularly in over my head in conversations about how things work in different parts of the compiler. It’s likely to be many years, if ever, that I’ll get a similar level of familiarity with the intrinsic (and essential) complexity involved in a project like TypeScript.

There are many verticals in this one codebase, someone could easily spend many years only working in one part of the compiler.

For the non-technical, working on TypeScript is working on a compiler - and compilers are kinda like the “rocket science” of building software. ( I wouldn’t be surprised if modern rocket science is probably 70% software nowadays ). Here’s 44 people replying to why it’s so hard to work on a compiler if you want a baffling mix of “I’m smart, look at my comment” vs “Hrm, yeah, it is kinda tricky”. I’m including my favourite quote for you:

Writing a compiler is the software equivalent to taking LSD.

It fundamentally alters your perception of the world. Hard problems get simpler. All the mysterious, arcane, and unknowable pieces of computing are reduced to a small, easy to grasp set of principles. And once you understand well how the machine executes code, your ability to reason about the performance of other code improves dramatically.

Basically it’s hard enough, you think everything else is easy because it’s not rocket science and you’re now Neo from the matrix - ha!

This sort of technical depth is not quite my bag, I’ve always prided myself on breadth over depth, but it’s hard to overstate issues which pop up due to the network effects of creating a compiler. Since I joined the team, the number of weekly downloads went up from 6 million downloads a week to 8 million. The set of folks who are using TypeScript are now pretty solidly into the early majority of the programming language’s lifecycle.

I’m learning, but it’s definitely overwhelming on the days I devote to compiler work where the most I get done is a lot of notes on how the compiler works and a bunch of tests which one day will be green.