The title “Chief of Staff” connotes some combination of DC politics, Supreme Leader Snoke (Star Wars reference), and the Minions. It goes without saying that at a San Francisco fintech company, the role looks very different.
I’ve been in the Chief of Staff role at CircleUp for just two months now, and I’ve already been asked the question – what is a Chief of Staff anyway? – 40+ times. The honest answer is that there is no crisp answer, and so I plan to write a series of posts to articulate the purpose of the role as it evolves over time. My hope is to bring clarity to the uniqueness and nuances of this often opaque position for others with a similar title (or aspiring to have it), for the team at CircleUp, and even for myself.
Leading up to this role I spoke with 10+ other Chiefs of Staff in the world of finance, healthcare and technology. I’m not going at this alone. It’s clear that the role varies by company, but two common threads emerge: (1) the job changes with every week and sometimes with every hour and (2) it is essential to be able to quickly and effectively prioritize initiatives. I’ll zoom in on #2.
In an environment where everything seems both important and urgent, there has to be a mechanism to prioritize (at the individual level and the organizational level). The alternative is a miscellaneous series of under-resourced projects with mediocre outputs – a really great way to run out of money.
I’ve used this importance vs. urgency matrix for a long time but just recently learned that it has a name: the Eisenhower Matrix (I’ve flipped the order and have a different spin on it). Note that with my background in consulting, I’ve been known to think in 2×2 grids – I’ll shamelessly play that up here:
It will be obvious to most that importance and urgency aren’t actually binary variable, which is why I use the word “relative.” It’s a spectrum in both directions which has to be re-calibrated at both the individual and team level.
In short, my job is to (i) make sure the team is executing on B projects, (ii) create time for myself to execute on A projects, (iii) resist every temptation to be derailed by C projects, and (iv) acknowledge that I and others just shouldn’t do many D projects. Let’s get specific:
E.g. In ~45 days Ryan (CEO) and I have several meetings with important strategic partners. 45 days feels like an eternity away (not to mention that the strategic partnerships will likely take 6+ months to finalize), but the time to start preparing an agenda and materials is now.
The majority of my job is to make sure A projects are prioritized before they become B projects (urgent). I’m a big believer in the 80/20 Rule but there are some things that deserve closer to 100%. By prioritizing projects before they become immediately urgent, we can get feedback from key advisors and iterate several more times on the outputs.
E.g. A new feature is shipped with a bug that meaningfully impacts the aggregate metrics used by the business teams. This needs to be communicated to the team at large and fixed as quickly as possible.
In a lean startup, B projects are where most team members spend the majority of their time, including the CEO. This is a good thing, and while I inevitably end up working in this sphere, my primary role is to help enable the right teams to execute, and to do so quickly. Sometimes this means elevating an issue or creating a decision framework to generate solutions. Other times this means just getting out of the way.
E.g. Ryan asks me to follow up with a business team lead on the rationale behind a process change that was mentioned at a recent meeting. There is some urgency to answer this before the context is lost, but the answer likely won’t change the decision.
This is the danger zone. I could very easily spend 100% of my time on C tasks and the temptation to do so is strong.There is nothing harder than being asked to “put out a fire” and deciding not to take action because the fire will probably put itself out.
I have come to believe that nothing of low importance can actually be THAT urgent, no matter who the ask is coming from. With this in mind I try to diagnose whether C tasks are actually B tasks, in which case I immediately prioritize, or D tasks, in which case I punt.
I block 3.5 hours on my calendar every Friday for what I call “Friday Follow-ups.” Throughout the week I accumulate a list of random asks and readings, some of which will take 5 minutes to complete and others that spiral into an hour+. By deliberately clustering these micro-tasks I consolidate the inevitable context switching, which creates a more efficient process. All at once, I crank through the list and if I’ve done my job well, Ryan has no additional follow-up questions to the follow-ups. I’m not there yet.
E.g. Write a blog about what it means to be a Chief of Staff 🙂
I could add a third dimension to this matrix: Relative Enjoyment. I don’t do many D tasks, but when I do, it’s only things I really enjoy. More to come on how to effectively ‘say no’ without constantly disappointing teammates.
To conclude, this framework is just one way to explain my experience of the CoS role to date. I welcome input from others who have held similar roles. I can assure you that my perspective on the job will continue to evolve so stay tuned for What is a Chief of Staff Anyway – Part II.