I joined CommandBar as the first non-founder and have played the mythical role of “early startup generalist” for almost 2 years. In the process, I’ve had the opportunity to work on almost every aspect of our company: customer success, product, sales, analytics, marketing, engineering, security, and more. The role of “early startup generalist” is fairly common but I haven’t seen much written about it since the job description is so nebulous and varies substantially from company to company. Below is some advice I’d give a new startup generalist. While this comes from my individual experience working on a specific product with specific people, I’ve tried to extract generalizable lessons.
Solve the personal cold start problem – learn to do something for the first time and believe in the process. This lesson applies to many of the early initiatives I worked on: nudging existing customers to try a new feature, building prospect lists, re-engaging stale leads. With most workstreams, the first half of the battle is just figuring out how to actually achieve the task. What tool(s) can I use to do this? What do I want the end result to look like? Once execution starts, it’s critical to understand what “good” looks like. Is the outcome a binary “success” or “failure”? Or is success probabilistic? Case in point: with sales outreach, only a tiny percentage of prospects will convert. Going into a workstream like this with a binary outcome mindset will quickly lead to demotivation and burnout. You’ll craft 5 beautiful emails, get no responses, and be sad. But knowing that you’re playing a numbers game from the beginning can soothe you even after sending 20 emails without a response. I’ve found the mindset of a baseball hitter useful in this regard – failing at a high rate can still be considered a success! If you aren’t sure whether success is binary or probabilistic, ask your team or a fellow startup generalist (happy to help!).
Be the cursed chef – recognize that some of your work will be wasted. At a young startup, there are many things that need to get built. And then you build it, and sometimes it’s no longer needed. Maybe the team has had a change of heart after seeing what it looks like; maybe the priority stack has shifted; maybe a new idea renders your work duplicative. There are countless reasons why a given piece of work won’t see the light of day. The reality of a startup generalist is like that of a cursed chef. You’re cooking up orders for customers, knowing that a random subset of customers will disappear before you can deliver the meal. A startup generalist must fully embrace this reality and not let it kill their mojo.
Identify opportunities to re-prioritize. Priorities are always changing, to-do’s emerge like Whack-A-Mole’s, and timelines for workstreams shift. It’s crucial to shift with the environment surrounding you and take care of the highest value work. Let’s imagine: the backlog you’ve been working on for a few weeks only has a few p1’s and p2’s left, but there are some p0’s that just surfaced. That the p1’s have been there for a while cannot be the only reason you don’t move to the new p0’s. In some cases (e.g., a customer commitment), those p1’s need to be completed, but then I’d argue in those cases, they’re probably p0’s at this point in time anyways. Being able to assess what’s important on the fly and prioritize accordingly is one of the most important skills for a generalist.
Take extreme ownership for your work. Early employees always have a ton on their plate. Unfortunately for early employees, unexpected challenges often emerge. Here are a few example traps that one might fall into: (a) someone from the team has yet to make their contribution or provide input; (b) there’s an issue with an unknown solution; (c) it’s not clear what the next step on the workstream is. The item owner should consider themself the DRI (directly responsible individual) and manage everything through resolution. When someone has yet to provide input, remind the individual or share a deadline for input to come in. When there are external blockers, bring the right teammates together to brainstorm a solution. When the next step is unclear, outline the possible actions with a recommendation and circulate to get buy-in. The best generalists make it a point of pride to own their work like a PM owns their product or like a CEO owns their company. A good heuristic I’ve adopted: whenever I pick up a task, I assume everyone at the company has forgotten about it, and I’m the only one responsible for getting it done.
Get things over the finish line. If there are three projects, it is generally more effective and faster to finish those projects one-by-one, rather than hop-scotch from one project to another. I think of this like multi-tasking, but on a larger scale. It can feel great to make big progress on multiple items, but it’s almost always more productive to focus on one item. I found that I was most tempted to jump to something else when I hit roadblocks. As a result, I used to end up at 80-90% completion on multiple projects before reaching full completion on any. The final 10-20% is the most challenging, so reaching the “done” or “completed” state is huge. Get comfortable clearing those hurdles, even if it feels like you’re moving slowly. Sometimes this means looping in other teammates, bringing in an expert, or taking a new path, but that bridge must be crossed at some point. And in these cases, no time is better than the present. The heuristic should be “get this 100% finished before moving on.”
