Deploy 2022

I feel like every year’s retrospective opens with “this year was special,” but this time I really mean it. A lot changed, big and small, at work, in my career, and in my personal life. So I’ve organized this one around a few keywords that stuck with me.

flex 2.0 and thinking about collaboration

The flex product today isn’t the one I joined. In August 2021 we started rebuilding the whole product as the “2.0 project,” and it didn’t fully wrap up until February 2022.

We were improving almost every part of the product while shipping new features on a deadline we’d promised, so everyone ran hard, nights and weekdays, to build faster and build well.

That period made me think a lot about priorities, time and collaboration. I kept asking myself what kind of teammate I needed to be to earn people’s trust, and to be able to trust them back.

Around then I had a coffee chat with Heejong, our frontend chapter lead at the time, and got some great advice. It helped me look at the question from different angles: what would actually build trust with the people I worked closely with, in each discipline?

• What kind of teammate do I want to work with?
• What kind of engineer would my teammates want to work with?

That year was about working out answers to those two questions.

Design Platform team

From March to October, I was a design engineer on the Design Platform team.

A bridge between designers and engineers. We build the design system as a shared language, and help design flow smoothly into engineering.

That’s the definition of a design engineer the team came up with together, plus a bit of my own take. The role helped me sharpen what I want my career to be, and I learned a lot while contributing to the team.

The design system we built on that team is a project I poured a lot of thought and effort into. Even before the team existed, I’d wanted to build one properly, since a design system is the raw material so many services are made from.

We worked through a lot together: which components to define and how to build them, how to deliver them, and much more. I remember it as a time when everyone worked intensely around one center, the design system, without caring much whose job was whose. Side note: it was the closest I’ve ever worked with designers. I wanted to go beyond what they had in mind (…), and I also wanted to develop a designer’s eye (?) myself, so every now and then I’d ask the designer next to me some very open-ended questions, like “What makes a design good?” or “What matters most when you design?” I’m grateful to the designers who never seemed to mind and always had something to teach me.

Between my own ambition and wanting to turn what the team had worked out into the best possible result, I spent that stretch, only slightly exaggerating, thinking about how to design and build components every hour I wasn’t asleep.

On that team, we almost never all agreed on something the first time. But the friction made the product more solid, and it taught me how to find a rhythm with my teammates. There were three designers and one engineer, and by talking through problems every single day we got to know each other’s tendencies, ways of working and priorities. (We never actually said this out loud, but that’s how it felt to me.)

I was happy to be part of building the system, rolling it out, spreading it, and watching it take root. But I’d been running flat out for so long that at some point I ran out of battery. Around September, I found myself “definitely doing something fun, yet exhausted.” Though if I’m honest, I didn’t just find myself there. I got myself there.

The first version of the design system, the one you could call a “draft,” came together pretty quickly. After that came iteration, as more and more teams adopted it in their products. Iteration meant new components, features existing components seemed to need, and bug fixes. And that’s where things started to creak. I wasn’t managing the scope of that iteration well. Building new components while also supporting the existing ones was more than one engineer could handle. Even so, I didn’t want to admit I couldn’t keep up, and because I cared so much about the design system and what our team was making, I tried hard to hide how I was really doing. (…) I think it came from a sense of responsibility and wanting to keep doing well. That drive has pushed me to grow, but sometimes it’s also what wears me down. I didn’t want to admit to any version of me that wasn’t doing well. My work is my responsibility, yes. But that doesn’t mean I have to do all of it alone. It took me quite a while to accept that.

I wrote that on my personal page, looking back on that time. Luckily, a teammate noticed and reached out first, and that’s how I got through it. I’m grateful to them in more ways than one. Later, with some distance, I was able to figure out why it had gotten so hard, and what I’d do if I ever ended up there again.

Looking back on how I wrapped up my time on the team, I still have some regrets. But it was a team where I learned a lot, both as an engineer and as a teammate, so I wanted to write it down in some detail.

Switching jobs

As I write this, I’ve already left flex. After about six months with “design engineer” as my title, I wanted to experience more of what that role could be and keep growing in it.

If I’d brought this up with the team earlier and we’d found a direction that worked for both of us, maybe I’d still be there. Maybe an earlier conversation would have changed things, but I can’t shake the feeling that that’s just hindsight talking.

Every organization cares about different values and different problems. For my next step, I want to be somewhere the work I want to do also matters to the team. I’m excited to see what stories a new team and new experiences will bring.

I don’t regret the decision. I thought it through, and from here, isn’t it just a matter of making it the right choice?

The gap period

When I left, I didn’t have my next job lined up yet, so I naturally ended up with some time off.

I didn’t set any goals for it. At work I’d spent so much energy thinking about what I’m good at and how to do things better, and I didn’t want to start thinking about how to rest “better” too. It was fine if the time wasn’t especially productive.

I went to exhibitions, took some one-day classes, coded whatever I felt like, wrote, worked out and cooked. With that much free time, I spent a lot of it thinking about myself.

I was anxious about what would come next, but I knew that kind of anxiety only goes away once things are settled, so I didn’t try to force it away. And sure enough, once things were settled, it was gone.

Words that stuck with me

Things I heard from people around me, or thought up myself, that stayed with me.

• Don’t agonize over what someone’s words or actions (or anything else they do) really mean, or assume the worst. Ask them directly, or if you’d rather not, just take it at face value.
• Don’t try to invent everything yourself. Plenty of good answers already exist. What matters is reading a lot and looking things up.
• Don’t try to predict change. Build things so they’re easy to adapt when it comes.
• Imagineering (Imagine + Engineering)
• If it’s a problem you can’t solve, hand the problem over to someone else.
• A job is like a coin. One side is making a living. The other is deciding “how I want to contribute to the world” and “what value I can offer.” And the rim that connects the two is, roughly, “what I want to do.”

Things I want to keep on record

• I gave a talk on design systems at FEConf 2022.
• I’ve been taking swimming lessons since August. I’m still learning butterfly, but maybe by next year’s retrospective I’ll have a few times worth writing down.
• I started a side project with the motto “slow and steady.” Whenever I want to try something at the size of a component or a single page, I build it and post it there.

Wrapping up

In past retrospectives I’ve laid out, in a lot of detail, what I want to write about the following year. For 2023, I’m leaving a vaguer goal instead: “I hope to keep walking in a clearer direction and grow through lots of happy accidents along the way.”

There’s no predicting a new environment, or the many choices it’ll ask of me. I just think the work of making each of those choices the best it can be is what will make it meaningful.