Interview with Patrick Joyce, Director of Engineering at Stitch Fix

Location: San Francisco Bay Area
Current Role: Director of Engineering at Stitch Fix

What’s your background and how did you get into management?

I’m a programmer. I always liked computers and from the time I was a kid, I thought programming was just the coolest thing.

I went to school for comp sci, then got a job at a big defense contractor, because if you graduate with a comp sci degree in the DC area that’s just what you do. After that, I started a company to help restaurants manage their web presence.

When that fizzled, I joined a company called LivingSocial as the fifth engineer. We were building Facebook apps. A few months later, I got asked to build our Deals app. That took off and we started growing like crazy. A year and a half later we had 30 engineers and basically no management structure. I gravitate to whatever is the highest impact problem to solve. At that time, it was figuring out how we were going to work together as more than 10 people sitting in one room. We kept growing and pretty soon I was leading 30 engineers across 6 teams spanning from Hawaii to France. I made a bunch of mistakes, learned a ton, and I’m very proud of what our team built. I then moved to a company where I ran Product and UX. There was a lot I liked about that role, but I deeply missed being directly involved in building things.

After that company was acquired, I came to Stitch Fix and I’ve spent the last two years helping our consumer engineering team grow from 5 to 55 engineers.

What are the biggest challenges you face?

The vast majority of my current challenges have to do with growth. We don’t have crazy technical scaling challenges like early Twitter, but we do have an incredible breadth of software we build and our team is growing really quickly.

Because we’re growing so fast a lot of people are coming up to speed at the same time. Simultaneously, we need to evaluate how we plan, communicate, and work together as a team. What worked great when we were 30 engineers would be a disaster now that we’re ~120. How we built our first 30 services starts to show some strain now that we’ve got ~90 services.

I spend a fair amount of time helping us figure out what needs to change and what we need to preserve.

What is your approach to hiring?

At Stitch Fix, we seek to hire bright, kind, and goal oriented people. I find if we get those three things right a lot of other things get much easier.

Beyond that, I look for people who ship meaningful things and care deeply about the impact of their work.

As to process, I find it incredibly important to design an appropriate hiring process for your current stage of a company. If you’re a 3 person company you shouldn’t try to replicate Stitch Fix’s hiring process. And we shouldn’t try to replicate Google’s hiring process.

Our interview process is focused on three things:

1. Understanding what you’ve delivered in the past.
2. Simulating what it would be like to work together.
3. Helping you understand what we care about and if this is the right place for you.

What’s your advice for managers who are just starting out?

Three big things:

1. Managing people is a completely different job than writing software.
2. Your first responsibility is the health of your team.
3. Manage yourself. The feedback cycle as a manager is much longer and less clear than when you’re writing software, but the payoff can be huge.

I have two more tactical bits of advice I like to share.

First, you generally get to be a manager by being an excellent engineer. That skill doesn’t suddenly disappear when you become a manager and it’s almost like having a cheat code. You can dive in and help deliver by building something yourself. But, every time you solve a problem with your engineering skills instead of your manager skills you’re stealing an opportunity for your team to grow.

Sometimes that’s the right thing to do, but you should be very careful about how often you use that cheat code.

At the same time, don’t entirely divorce yourself from the reality of building software. It is entirely OK to periodically block some time to build things. But since your first priority is the health of your team don’t sign up for things on the critical path. You’re now much more interrupt driven and you don’t know when someone on your team will need you.

Second, you’re going to struggle to figure out the difference between “that’s not how I would have built it” and “that’s wrong.” Early in my managerial career, I vacillated between being overly prescriptive about designs and allowing some things to go out that I knew were going to cause problems. Thankfully, I eventually found the right balance. I’ve now seen this enough to know that it is normal.

Whats your work day like and how do you manage your time, emails, etc.?

I do a lot of my work in meetings now via one-on-one, with the people on my teams, interviews, and conversations with people across the company.

My time is managed by my calendar, but I manage my calendar by regularly setting and reviewing goals.

Each month I write up high-level goals in a markdown document.

Sunday nights, I review my calendar for the week to get a sense of what is coming. Then, first thing on Monday mornings I set priorities for myself for the week towards my monthly goals. I do that in iA Writer so that I can get things out of my head quickly. Then I put the tasks to accomplish them in Things.

Frankly, keeping up with email is something I’ve struggled with. I’ve been better recently by becoming OK with sending a one sentence reply that isn’t as polished as I would prefer.

What’s a personal habit that contributes to your success?

Running regularly.

If I don’t take care of myself I can’t take care of my team. This is a lesson I’ve had to learn a few times, but that I’ve been pretty consistent with for the last 3 years.

Share an internet resource or tool that you can’t live without.

I’ll do the two I already mentioned:

1. Things – How I manage my life. I’d be lost without it.
2. iA Writer – Writing helps me think. At this point, I pretty much think in Markdown. iA Writer gives just enough formatting to help clarify my thoughts while being restricted enough that I stay focused on the words.

If you could recommend one book to managers, what would it be and why?

The Manager’s Path. The engineering managers at Stitch Fix do a book club and this was one of the books we read last year. Reading The Manager’s Path after 5 years of managing was a very similar experience to reading Code Complete after being an engineer for several years. Camille does an incredible job of articulating lessons that I had to learn through painful trial and error.

Until last year, my one recommendation would have been Managing Humans. The day I became a manager I bought the book, went home, and read it cover to cover. It is a very different book than The Manager’s Path, but it really emphasizes two things that I want all new managers to understand:

1. That managing is a different career
2. Your job is now humans not code

Where can we go to learn more about you? (LinkedIn, Twitter, Github, etc.)

I infrequently write at my personal blog, pragmati.st. Our team writes some interesting things at multithreaded.stitchfix.com.

I’m @keeperpat on Twitter, but have almost entirely quit in the last year as it was a time sink that I wasn’t getting much value from.

And I’m KeeperPat on GitHub, but most software I’ve written in the last several years is for work so there isn’t much to see.

This series asks engineering managers to share their experiences with the intent of helping other engineering managers learn and improve. Have someone you want to see featured or questions you think we should ask? Contact me.