The Chemist

The role of the chemist is to discover something that works and understand why it works. New products, new business models, and new technologies are all within the chemist’s purview. The main output is new knowledge. Practicality is not a requirement. In one of Paul Graham’s best known essays, “Do Things That Don’t Scale”, he argues that manual, painstaking work is fundamental to the discovery process. Every founding team has at least one person who can play this role.

Every new marketplace needs a way to get supply, and one of the hypotheses the founders of ThredUp had in its early days was that customers would send in bags of clothing if they made it easy enough. The office was soon overflowing with Mylar bags and no capacity to do anything with them. The experiment had revealed there was something worth pursuing. The operational chaos that ensued was a sign of success. Chemistry in action.

The Chemical Engineer

The chemical engineer takes something that works and makes it work at scale. The chemical engineer has to deal with throughput, variability, failure modes, cost, instrumentation, controls, human operators, and the fact that changing one part of the system changes something somewhere else. People who do this well are, at their core, systems thinkers and systems builders.

The first operations hires at ThredUp took an empty warehouse and turned it into a set of systems and processes that could process clothing at scale. Designing and redesigning the work helped us understand what to automate and when to automate it, and four years after bags in an empty warehouse, we had the largest garment-on-hanger automation in the world.

The Plant Manager

The plant manager operates the system that the chemical engineer has built. They care about uptime, quality, cost, staffing, maintenance, variance, and continuous improvement. Their role is to make a known system perform reliably. “Makes sure the trains run on time” is a good shorthand for the type of performance expected of this role.

You might find no plant managers in an early-stage startup because there isn’t really a place for them yet, as was the case when I joined ThredUp. As operations scaled to hundreds and eventually thousands of employees, people who embodied the plant manager skill set became invaluable. They kept the operation running reliably while chemical engineers kept redesigning the systems underneath them.

Finding Your Own Way

At ThredUp, I worked in many different parts of the company. I didn’t just move between functions; I helped create some of them. My work spanned engineering, product, and data science, but I never fit neatly into any of those disciplines. Over the years, I accumulated a series of unusual titles that reflected how difficult it was to fit what I did into conventional organizational structures. Eventually, I realized that the common thread wasn’t the function I worked in. It was the work itself: designing and building systems.

I started by doing this on a small scale. As I came to understand more of the business, I took on bigger and more interconnected challenges, eventually becoming responsible for the commercial engine of the entire marketplace. My development didn’t follow a conventional path through engineering, product, or data science. I became better at diagnosing systems problems and rallying people to solve them. What I knew instinctively, and later learned to articulate, was that I’m a prototypical chemical engineer. As I moved up, I didn’t simply gain altitude. I expanded my range of zoom, becoming able to move between the details of individual processes and the workings of the entire company.

What concluded my 11-year run at ThredUp was a reorg that put me in a plant manager role. It was the first role I hadn’t designed for myself. I was promoted to vice president and had achieved what I thought would be an incredibly meaningful career milestone, but instead found myself profoundly unhappy because I was doing work that no longer suited me. It was less about what I was capable of and more about feeling like I was fighting my instincts at every turn. From the outside, it probably looked like a familiar story: the early employee who got the company here but wouldn’t get it to the next place it was going. I left to start my own business, and I did so with the explicit intent of building the work around my strengths.

When I think about the conditions that allowed me to succeed at ThredUp, and what changed at the end of my tenure, I come back to three things: knowing what I did well, working in an organization that valued those strengths and gave me room to grow, and having the right environment to do my best work.

Knowing what I did well only got me so far. I also needed an organization that valued those strengths and let me take on more responsibility without abandoning them. I was fortunate that, until the reorg, I could keep moving up while staying in my strike zone. I think one reason management is so frequently dysfunctional is that it’s often the only reliable path to advancement. People get promoted into work they’re poorly suited to, or pursue those roles knowing they won’t enjoy them, because that’s what gets rewarded financially.

The third condition was an environment that understood how my kind of work gets done. Discovery, systems building, and reliable operations require different structures, processes, and tolerances for uncertainty. I’ve written before about the impedance mismatch between these kinds of work, and how it can make even exceptional people ineffective. I suspect organizations with all three archetypes represented in leadership are better equipped to recognize these differences, and to show people a path to advancement that doesn’t require abandoning what they do well.

Making a Way for Others

Knowing what makes you effective is one thing. As a leader, you also have to understand what kind of work your organization needs done, who is suited to do it, and the conditions they need to succeed.

I recently shared this framework with a founder I greatly respect. She understood it immediately and thought of someone on her team. “Oh, I have this great person, and I haven’t been able to figure out why I can’t find a place for her. It’s because she’s a plant manager, and what I need is someone who can build the function.”

I had a lot of empathy for her at that moment because I’d made a similar hiring mistake myself.

The first team I built when I became a hiring manager was the algorithms team at ThredUp. Our mission was to design and build the decision systems that would allow the marketplace to perform well at scale. Every item in our inventory was unique, which created some pretty thorny data science problems. So I went out and hired some data scientists.

I was excited about the first data scientist I hired. He had a PhD in machine learning, and his research seemed highly relevant to many of the problems we faced. The first problem I gave him was improving our photo retouching. We already had a system operating at scale, and I thought someone with his capabilities could deliver incremental improvements pretty quickly. Instead, the timeline kept slipping. I tried to steer him toward incremental improvements, while he kept trying to design a brand-new, cutting-edge system from scratch.

I couldn’t figure it out. This was a brilliant person and a relatively simple problem. What was I missing? I eventually realized that I’d made a hiring mistake: I’d hired a chemist to do a chemical engineer’s job. He had spent his PhD and his career creating new primitives, but I needed someone who would evaluate solutions in the context of an existing system, production constraints, costs, and business outcomes. I’d hired him for his strengths and then put him in a position that didn’t make good use of them.

It would have been easy to explain his struggles as a problem with him: that he didn’t care enough about the business, or that he didn’t have the right stuff. But, if I’d settled on that explanation, I’d have missed my own mistake and the opportunity to become a better hiring manager. It’s a leadership principle I’ve written about before in my critique of Amp It Up: when something goes wrong, look in the mirror before you look out the window.

My mistake was a hiring mistake, but the lesson extends beyond hiring. When designing an organization, leaders have two responsibilities: understanding what kind of work needs to be done, and creating the conditions in which people suited to that work can succeed. As a company grows, both the work and the conditions change.

Who Outgrew Whom?

Most companies that make it reach a point where the people who built it start to struggle. There’s a well-worn phrase for this in Silicon Valley: the people who got us here won’t get us there. It usually gets said as a fact about the people.

Sometimes it’s true. When a company goes public, the finance job changes. Keeping the books for a startup and closing a quarter under SOX are different jobs that call for different expertise. Someone great at the first can be the wrong person for the second, and no change to the environment fixes that.

That case is narrower than the phrase suggests. Discovery work never runs out. Companies at every scale have new products to find, new markets to enter, and systems that were never built properly. The danger as a company grows is that this work becomes impossible to do. The organization develops processes and expectations to protect what already works, as it should. But when those same expectations are imposed on discovery and systems-building, the chemists and chemical engineers lose the conditions that made them successful. When they start to struggle, the first place to look is the conditions. It’s the same mirror I learned to hold up to myself with the data scientist, held up to an entire organization.

Sometimes the people who got us here really aren’t the people who will get us there. But sometimes they’re exactly the people we need, and we’ve made it impossible for them to do their best work. Knowing the difference falls to leaders, because from the inside the two feel the same.

---

Originally published at Seeing The System.