The world and pandemic is getting increasingly dangerous out there again. I sincerely hope everyone remains safe and healthy over the end of year holiday season.
It’s the end of the year and organizations across the world have likely been engaging in the annual ritual of doing “planning” for the next year, through a series of complicated meetings and “syncs” and “getting alignments”. There’s lots of stuff written about how different organizations and teams plan ahead for the future, whether it’s using tools and methods like OKRs, or writing new Epics, or a set of big company goals are handed down from the heavens, etc.
But know what? I don’t see much written about handling planning when you’re near the bottom of the organizational ladder. There’s definitely stuff we need to plan and advocate for, but I also see a lot of folk get stressed because this big complicated machine is moving above their heads (sometimes WAY above their heads) and they feel like they should somehow contribute and have no idea how.
It took me many years of watching the planning process at various places over the years before it slowly clicked in my head what the big, stressful, complicated exercise really is.
TD;LR for surviving planning when you’re too junior to know what’s really going on
Don’t panic. You’re not making any irreversible decisions about your fate
Participating in planning is listing things you want to do, along with things other people want you to do, and having everyone hash out which are the most important things on the list — then you work on those important items
It’s to your benefit to participate and contribute to future plans where you can. The more experience you have the easier it is to find things to contribute
Everyone will treat it as super important to do
Everyone also understands even the best plans change
Planning is finding answers to “Where are we going? How do we get there?”
At the highest of levels, planning just boils down to forcing ourselves to devote some thinking about the future. This is because large complicated efforts take time to build up to, and it’s nigh impossible to execute a multi-year effort without some forethought. Since much of the tech industry involves large, complicated efforts that span multiple teams and time horizons, it’s a pretty important activity to identify the goal, and proposed way we’re going to achieve the goal.
Even if your organization were extremely straightforward, like you were selling coffee from a cart on the streets of NYC, doing any big change like adding a menu or expanding to a larger cart would take lots of thought, planning and budgeting.
Since there’s usually lots of competing demands for limited resources, teams eventually wind up with a big wishlist of things they want to work on, and all the managers and stakeholders wrangle amongst themselves to decide which ones will be worked on, and which will fall under the cutoff line and won’t get worked on.
When you’re just a low ranking person, much of those discussions won’t even be your view. At most, you might have contributed to your team’s particular wishlist (more on that next), and those go up the chain and the final prioritized list of projects will come down from above.
But I'm on the bottom of the pecking order, why shouldn't I just sit back take my marching orders?
Sure, for various complicated reasons sometimes that might be the good course of action. But in in many tech companies I’ve worked in, this isn’t ideal for you.
Just because an executive declares that the goal for the year is to reduce theft by 50% doesn't mean they know exactly how to get there. Those tactical decisions are informed by and ultimately executed by people lower down the chain, and that includes you. There’s lots of room for interpretation as to how to contribute to achieving the goal within the confines of your job description.
There will always be a bucket of things that you, as individual, want to achieve in the coming year as related to work. Maybe it's reducing tech/dashboard debt to free up time for other work, maybe it's a study about a specific hypothesis you have, maybe it's a question from a distant project team that seems really promising to look into. Maybe you want to try out a new methodology you learned. There’s usually some intersection between those interests and the broader goals handed down from above. They’re aligned in spirit and thus valid options to include in planning.
That bucket of “stuff I want to do” just needs to be balanced against all the stuff everyone else wants you to do, because sometimes that stuff is also important. This is why it’s important to engage with planning regardless of your ‘rank’, you should make some effort in putting forward ideas for future work projects onto the table and have them compared on the merits against projects coming from everywhere else. Worst case, your stuff isn’t deemed as important and it gets pushed down past the work cutoff line. Best case, people agree and you get to work on something you want to.
Sidebar: Yes, the above makes LOTS of assumptions about the environment and willingness of people in the management chain to accept projects that aren’t “from the top”. There are many places such an approach won’t fly and gets exceedingly political, but what I describe is a somewhat the ideal state you’d like to find yourself in.
Oh no! But my work depends on what other people’s work is!
If your job is similar to mine, where the primary charge is to “make other people smarter and better at what they do”, then a lot of your work is actually contingent upon what other people are doing. This was true when I was doing product analyst work and data scientist type work, and is even true now as a UX researcher.
For example, as a Quant UX Researcher, I have a couple of research questions and projects I think are important to look into and submit those into the planning process, but I also expect a majority of work to come from the various engineering and product teams who will request that research be done in support of whatever it is they’re committing to build next year. Most of those teams won’t know what their own plans are until the planning process is mostly (but not completely) done.
This sounds like a recipe for disaster and panic — how can I submit plans for stuff that is completely contingent upon other people’s plans? The answer is you just have to peer into the future and anticipate potential work coming, leaving flexibility into your plans while keeping your finger on the pulse of your various partner teams.
Once you get a rough sense of what a team wants to do (e.g. launch a big new feature, run 5 small experiments, ship a prototype for testing) you can take block off a chunk of time as “1 big project to support team X doing Y”. Then, throw in another block of time for “random ad hoc request for important research that will pop up”. Finally, toss in those projects you want to work on.
You’ll ultimately end up with this life of vague projects that are attached to teams and efforts, plus your own projects. Some of those will become concrete projects as people make up their mind about things, others will get shuffled around and fail to become actual work. Other things will come out of nowhere as new surprise initiatives spawn. This doesn’t look like a very strong thing to stake an entire year (or quarter) of planning on, but that’s about the best I’ve come to expect.
It’s the nature of this particular line multi-team/multi-product work to be utter chaos. Just go with it as best you can.
Whoa, but over half your plan is “flexible”, why bother having a plan at all?
Planning, even planning for a lot of flexibility, takes a lot of work. This is especially true for when you’re busy with day-to-day work and deadlines. So I’m sure you’re wondering why bother with this whole exercise to begin with. Much of that time could be spent doing something else, or having a nice relaxing lunch break.
The reason I put effort into participating in planning is because I really want to work on those handful of projects that I push into the system. It gets other teams to look at those projects and agree that they’re important enough to work on. It gives me a reason to work on them in the little gaps between other projects. And when things change (as they inevitably will), I can point to that prior agreement and push back on work that seems less important.
So in the end, planning isn’t supposed to be a bunch of out-of-touch people dictating what your work is supposed to be, but instead a vehicle for deciding which of the things you and your stakeholder teams want to do that happen to work towards the big overarching goal.
You can let the people paid significantly more worry about how all that aligns with what they intended.
About this newsletter
I’m Randy Au, currently a Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. The Counting Stuff newsletter is a weekly data/tech blog about the less-than-sexy aspects about data science, UX research and tech. With occasional excursions into other fun topics.
All photos/drawings used are taken/created by Randy unless otherwise noted.
Curated archive of evergreen posts can be found at randyau.com
Supporting this newsletter:
This newsletter is free, share it with your friends without guilt! But if you like the content and want to send some love, here’s some options:
Tweet me - Comments and questions are always welcome, they often inspire new posts
A small one-time donation at Ko-fi - Thanks to everyone who’s supported me!!! <3
If shirts and swag are more your style there’s some here - There’s a plane w/ dots shirt available!