When I started working at thredUP a little over a year ago, I was the 5th full-time, non-founder employee. During that year, the user base has grown over 15x and there's now 22 people working at thredUP including the founders. We've been moving fast and there's been a lot to learn in the process. So much learning that I would say I've had more professional growth this past year than my entire professional career.
Some of the growth came from mistakes I made or from the condensed Rails learning I went through, but the most valuable learning came from the evolution of our development team and from working soup to nuts on a number of large projects. On a recent boat trip in Northern California, I took some time to reflect on the year to determine what I did well, what I did poorly, and figure out what the next steps were. During that time I came away with two very important things I learned that I want to continue to focus on this year:
Leveraging Your Knowledge Is Your Job
If you're a developer at a big corporation, especially those with big teams, the natural tendency is to take on 'rock-star' projects, hoard knowledge, and specialize in certain niches that are important to the company so that you can become indispensable. If you do this ‘right’, the value you create for yourself over a potential replacement will yield a lot of benefits (i.e. raises, promotions, etc.). At a start-up, the return is only short term and you’re hurting the company as a by-product.
When your team is small, you become responsible for large pieces of your app. Not because you’re trying to hoard anything, it’s because there’s a finite amount of developer resources and there’s a lot to do so you split up the work. As the team grows and more resources become available, you arrive at a point where you’re forced to make a decision: let your new colleagues go through the same growing pains you experienced and expose the knowledge dichotomy or leverage everything you know to help them skip all the road blocks you experienced along your path.
It sounds like a black and white decision - help yourself or help the team. It sounds simple, but you’re intentionally making yourself less valuable when you give away all your tricks, knowledge, and keys to the niches you specialized in. What I learned was this:
- The ability to leverage your knowledge and create more value for the team is essential to scaling a company. To become very valuable to your team is one thing - to be able to help others become just as valuable as you is what can truly make you indispensable.
- Your professional growth ends when you isolate yourself to a few domains of expertise. To learn new things, you need to move past what you already know and exit your comfort zone.
The Last 10% is the Hardest and Most Important
Every decent-sized project contains a variable amount of work that is unforeseen. On the Back-end, it’s typically the flows that weren’t thought through or the business logic that was sound on paper but didn’t add up in code. On the Front-end, it’s the hover/active/disabled buttons that weren’t in the designs or the edge cases of too much or too little of data that breaks the design/layout. Even if you're meticulous, something always springs up.
The reason why this chunk of work is so hard is because at that point of the project, most of the fun stuff is out of the way and everyone is waiting for the end product. To polish all those unplanned pieces would require grinding through test scenarios and working late to make sure every design interaction is perfect. It's not the most rewarding work, but from my experience I’ve found this is the most important phase of the project.
I have never ‘wowed’ anyone on a project that wasn't completely buttoned-up no matter how cool it was or how extensive the functionality was. When things are ‘off’ or ‘clunky’, it will consume the focus of the page and a lot of your great work will be looked over. Worst of all, the projects of yours that will be remembered the most will be the ones that are the most buggy. I think every developer has heard the following and cringed: ‘I found a bug. Who coded the ?’
If you build features that break often, your name will be associated with bad code or some sort of negative connotation regardless of how difficult or complex it is. The more you care and focus on that last 10%, the less your name will be brought up for the wrong reason. At the end of the day, if you want to be the 'go-to' person, you need to care about that last 10%.
