I joined Teachable in 2014 as its first designer and front-end engineer. Getting to be a versatile individual contributor in a fairly flat organization was extremely fun, at first: it offered a lot of flexibility to someone like me, who wanted to both design and code.
As we grew in size, the typical challenges around scaling and organization building ensued. Some things that were once efficient and fun weren’t any more. When we noticed this trend in late 2016, one of the root-causes we identified was the lack of product management: as our marketing, operations, and customer care teams were forming around us, it was apparent that our engineering team needed to operationalize with it.
When our first couple product hires didn’t work out, I was given the chance to step in as an interim Product Manager by our leadership team. Three months later, I was promoted to VP of Product, tasked with not just managing our product, but building out an entire team — they'd no longer be looking to "hire above" me.
I realized that my cross-functional experience in both design and engineering, and my love for products, had set me up on this path a long time ago. While I found myself immensely fortunate to be able to have such an impact on our product and company, I was also scared. I didn't know if I was doing the right thing by taking this on, but I didn't think there was anything better for me.
I reached out to all my mentors, started reading every book on product that I could find, and met every seasoned executive I could manage to convince for coffee or lunch.
When I left the company in April, the Product team I’d built consisted of 4 PMs and a design team of 4, supporting a company of nearly 100 at $20mm+ ARR and $320m+ in accumulative GMV. I never thought I'd stay with the company in that role for as long as I did.
Some day, I’ll write about why it made sense for me to leave.
But for now, I'd like to share some of my lessons and be available to anyone who’s undergoing a similar transition. The post you're about to read is one I wish someone had written for me when I began my transition.
Going from an individual contributor to a manager, and then from a manager to an executive, can be extremely challenging, rewarding, and humbling. But if you ever find yourself in a position where such an opportunity presents itself, I urge you to take it up.
It's a ride very few get to go on, and like most adventures worth having, it will involve a constant cycle of learning, failing, and getting (a little) better at the job.
A lot of the lessons in this post apply primarily to the executive path in high growth, venture-backed startups. It's worth noting that this is not the only path! With the indie creator movement, bootstrapped startups seldom need to focus on matters like organization design, inter-team communication, and management training.
So, at the risk of rehashing most of what you’ll read if you're undertaking this transition, here are the 10 most obvious things that I can personally attest to having learned the hard way — by trying and failing.
1. HIRING THE RIGHT PERSON TAKES TIME
First and foremost, I learned how to hire, and to be patient at it.
If you're in a situation that I was, this is not a skill that you currently possess. I got to participate in over hundreds of phone screenings and interviews, learning to distinguish between talent and skill, and skill and experience.
It took me some time to realize that "management" is not something you should actually strive to do — the goal should be to hire talent you can trust and have to manage very minimally. To that end, a riskier but high potential hire may end up being a better choice than a safe hire, but the former will take time.
Week after week, phone screen after phone screen, it takes time to build up a pipeline.
Once you've got the pipeline, it takes time to calibrate internal alignment and expectations on what you're actually looking for. What's good? What's right?
You learn how to pitch yourself as someone worth working for, and the company as something worth believing in.
And even once you've made an offer, the reality of a "no thanks" can hit you like a ton of bricks.
I wouldn't have thought of hiring as a game, but it turns out to be a challenging and ultimately a rewarding one.
For more such lessons, I recommend reading The Culture Code by Daniel Coyle.
2. IF I WASN'T REPLACING MYSELF OVER AND OVER AGAIN, I WAS FAILING
Building and scaling for an organization at the same time is never fun. When I first stepped into the Product role, I was still Teachable’s only product designer, and had to immediately hire my replacement; all the while, I was unblocking engineers who were waiting on me for design and product input. Over the course of the two years, I got to personally do the job of at least 3 different IC roles until I was able to hire for them.
I probably waited too long to prioritize hiring and delegation, and later realized that it's what I should have done *at the cost of* what I was actually good at: product work. This is a critical skill at growing startups, and seems counter-intuitive at first: it doesn't feel right to "half ass" the job that you're doing.
But I found that people were generally very understanding when I set the right expectations, and told them *why* I was half-assing something, looping them in on the progress I was making on the hiring front. Getting them invested seemed to help.
And when it worked, not only was it the right thing to do for the company, it was the only way of ensuring my own future sanity.
High Output Management by Andy Grove taught me about the importance of leverage and exposed me to managerial mental models I was oblivious to.
3. NOT ALL PROCESSES ARE GOOD
When I first stepped into the product role, I was exposed to a lot of “process jargon,” and they all sounded like things I should have been doing but wasn't. I felt like an imposter for not implementing them.
THIS WAS A TRAP! I realized that if you’re not thoughtful about it, a process is the surest way to suck the life out of someone's work, especially if that something wasn't "broken" to begin with.
I slowly picked up signs of processes are effective, and ones that look effective, but aren't actually. For example, if at all possible, engineers should assign themselves to work that they'd prefer to do, instead of set meetings where product managers take the pick. The more autonomous people feel, the better work they do.
I also learned the value of *non operationalizing*; i.e. taking the process out of things so they’re fun again. Research and feedback was one such thing — my personal time spent with customers and their feedback made way more of a difference than delegated, organized summaries and checklists of their feedback that I wasn't a part of.
Learning how to distinguish between good and bad processes doesn't just make someone a great manager; it makes them someone who's both competent and easy-going, someone who works hard but seems fun and effortless.
On this topic, one of the best books I can recommend is Orbiting a Giant Hairball by Gordon McKenzie. The "Hairball" is bureaucracy and process, and you've got to learn how to orbit it: be close enough to it that you understand it, but far enough that you don't get engulfed in it.
INSPIRED by Marty Cagan has a whole bunch of tips on operationalizing your product team in fruitful ways.
And finally, Elinor Ostrom proved why *people* governing themselves is the best possible way to govern the commons with a great amount of research and a Nobel Prize in Governing the Commons (watch this video, too!).
4. REALLY IMPORTANT THINGS NEED TO BE REPEATED, OVER AND OVER AGAIN
Shipping a product with large groups of people is a skill. When something was really important, I learned that it had to be said over and over again with the same amount of enthusiasm as the first time (sometimes, to the same people). If you're an executive, people tend to watch what you do, but rarely remember what it is that you said. Important things are worth communicating up, down, and in every direction to avoid dilution and misinterpretation of a key message.
To me, Jeff Bezos is the ultimate master of key message encoding + repetition. I'm not even an Amazon employee, but I know exactly what he means by "day one" and "customer obsession". Even better, I remember it.
I don’t think I ever really learned how to communicate effectively as an executive, but I learned the importance of communication being one of the highest leverage things you can do. For an introvert like me, this was one of the least fun things to do and learn, but in hindsight, perhaps the most beneficial life skill I got to get better at.
The Pyramid Principle by Barbara Minto taught me how to be concise and structured, both in my thinking and my communication.
High Growth Handbook by Elad Gill taught me about ways in which startups have to operationalize and systematize a whole bunch of lessons like this one.
5. SYSTEM > GOALS
In a given week, I was exposed to everything from company-level metrics to the smallest of grievances. From mockups for features that may not ship for many months to looming disasters that are days out. In that whirlwind of things going on, something I started to appreciate was the very opportunity to observe such a complex and dynamic system at scale.
I used to be a goal-oriented person, looking for the next hill to climb. But over time, I learned that the "hills" I was looking for weren't really hills as much as one never-ending mountain with many intertwined peaks, crevices, rivers, and resting points. The beauty of our work and impact was always around the corner, as was the risk of falling and the feeling of despair.
To excel at it, it seemed like having a system, a method of operating, was table-stakes. Something that vaguely consisted of my gut, my ability to zoom out, and my faith in what I was about to do. In observing other, more senior executives, I found that they'd mastered their own systems over time.
A method of operating with a system was worth a lot more than single-minded goals. It keeps you centered when things don't go your way, and keeps you focused on the one variable you have some control over: you.
When I first read Thinking in Systems by Donella H. Meadows, it blew my mind. It's amazing how such obvious things can be so complex, and how stories of complexity can be told in incredibly simple ways.
The Goal by Eliyahu Goldratt was a guilty pleasure at first — a "business book" — until I reflected on it, and realized that it's much, much more than that. Turns out, "The Goal" is actually about systems.
6. SET THE PACE & PACE YOURSELF (IT'S OK)
Over time, it occurred to me that our culture and output was really intertwined with answers to the following questions:
1) What do we think is worth doing, and why?
2) What are the kinds of things we are willing to let slip, and at what cost?
3) How are we going to measure and pace ourselves?
4) Is everyone on board with the answers to these questions?
Most of the answers to those questions aren't solely in the hands of managers and executives, except for one: how are we going to measure and pace ourselves?
And to that end, my personal preference is to do it simply (fewer KPIs) and realistically (incremental inputs you can control and change).
Milestones that were incredibly ambitious were rarely met, and put a lot of undue pressure on teams. Worse yet, when we shed the blood, sweat and tears to meet them, and fell even slightly short of it, it didn't seem like whatever we achieved was worth appreciating. That was far from the truth.
After failing to nail OKRs many times over, I became a little better at it after I read Measure What Matters by John Doerr. I still don't agree with Google's way of setting goals that you're bound to not meet just for the sake of it, though.
7. ONCE IN A WHILE, YOU HAVE TO LOOK UP AT THE STARS
At my core, I’ve always thought of myself as a designer and engineer. So when things got strategic, I put on my tactical builder’s hat. Every time I did this, it was a massive mistake. Being a good strategic thinker often means letting go of your lens into the opportunity space, and seeing it through many other (potentially more important) lenses.
The clearer your North Star, the clearer you see it when you hit upon the right idea.
Getting a clear picture of a North Star requires work, though. It requires asking yourself, and others, "why" a whole bunch of times. Asking "why" can be deeply uncomfortable, and question assumptions you may have been taking for granted. When you don't have answers, you tend to feel untethered and directionless.
But getting those answers, at least ones you can buy into for a while, can make everything else a lot easier.
Put another way, I think you have to look at the stars to appreciate what's around you.
On Grand Strategy by John Gaddis, based on a Yale course, taught me how to balance being a fox with a hedgehog by showing me examples of leaders in historical contexts. Meanwhile, foxes can keep a lot of contradictory ideas in their head and are prone to doubt, reflection and adaptation; while hedgehogs know one big thing and can relate everything to a central idea. Both are pretty important.
Start with Why by Simon Sinek made me do exactly what the title suggests.
8. YOU’LL HAVE TO GET BACK UP AND TELL EVERYONE ABOUT WHY YOU FELL
When I made a mistake, I realized that I not only had an outsized impact on the failure at hand, but I set a modus operandi that people around me inevitably emulated and repeated. If I wasn't observing and learning from these failures, and emphasizing the cost of repeating said failure, the failures ended up repeating themselves over time.
But to accept, learn from, and share the lessons of failure takes a lot of humility and acceptance, which I didn't possess at first, and am still working on.
A promising lesson I learned throughout a lot of it is that I was more "gritty" than I thought. I could withstand a lot of pressure, fall, and get back up again.
Grit by Angela Duckworth is a book that taught me about the importance of effort, and learning to get back up again. As she points out in the book, effort counts twice: once in skill acquisition (as you use your talents to acquire a skill), and once again in achievement (as you use those skills to achieve something.)
9. NEVER STOP SWEATING THE DETAILS
In making my transition from an individual contributor to an executive, I think I lost sight of the importance of details, and that was a mistake. As you become a master of systems, delegation, and abstraction, you tend to forget that most successes or failures can be attributed to detail (or the lack thereof) at every level.
I think this is why Bezos still responds to customers directly, and Jobs sat through many demos every week. It goes back to that question: what are they willing to let slip, and at what cost?
Sweating the details seems to count twice-over too: once in fixing the problem at hand, and once again in showing the importance of fixing these problems to everyone who's looking.
Creative Selection by Ken Koceinda is a fascinating account of Apple’s design and product development process. Apple may as well be called the "detail management factory". It's inspiring to me that companies at a massive scale, ultimately, boil down to the summation of all the shits they gave when something wasn't right.
10. PEOPLE ARE NOT COMPONENTS
A spreadsheet is a powerful tool of abstraction, so powerful that it can hide even the most important stories worth listening to.
Hiring projections, thinking about whom to give a raise to, models of team structures, etc. are generally informative exercises; but if you end up taking them too seriously, you can end up believing that people are ultimately a “piece” of a puzzle — the budget sheet, the roadmap, the team, the feature.
I found it very easy to forget that a person is a living organism that lives and breathes, has hopes and ambitions, and believes that you're worth working for. If I wasn't operating in a state of empathy, this was one of the most tragic things to forget, because it messed with my focus on the North Star.
A question that bears repeating to remind me not to lose sight is this: would I choose to work for myself, a spreadsheet manager? A person who sees people as cells in a spreadsheet and a component in a library? Would that person be worth working for? If it wouldn't, why should I expect to get away with it?
I read the Trillion Dollar Coach by Eric Schmidt, Jonathan Rosenberg, & Alan Eagle after I left Teachable, but it reiterated a lot of what I already believed: teams are about people, and people can get better with coaching. It's amazing to me how Bill Campbell's central message was to remind the people he coached about the value of seeing the people around them as exactly that: people.
