Planning is Everything
Hey!
Welcome back to another week of musings. We didn't have a long weekend this week, but I'm seeing the signs of spring, and I enjoy seeing flowers bloom around the city.
I hope you had an uneventful weekend and had time to rest and repair.
Was this forwarded to you? You can subscribe here!
Continuing with my topic from last week of taking control of your calendar, I've been thinking about plans in general.
I've been going through the planning phase for next quarter, which reminded me of the quote from Eisenhower.
"...plans are useless, but planning is indispensable" --Dwight D. Eisenhower
Spreading the team
Your company might have a different planning cycle or even not have (or need) one.
After a certain size, the process becomes part of the culture. You might have way too many product managers (PMs) looking for their projects to be done and a single engineering team dealing with these competing priorities.
Accepting all the top priorities of every PM you engage with is a bad idea.
Understanding problem space
One benefit of planning is that you should expect a document describing the problem the company wants to solve. It could be a product requirement document (PRD) or a one-pager, which might be called differently in your organization.
When you have a document that describes the problem space, you can analyze the problem space and start working on your solution.
This helps with delimiting the scope of work, what can be achieved in a quarter, or defining milestones to deliver consistently and working towards the long-term solution.
Talk of trade-offs
You can discuss trade-offs after understanding the problem space enough to scope the solution and allocate teammates.
Your conversation with PMs might go differently, but you can talk about the benefits of a project that might be faster to achieve vs another one. Or the opportunity to do a more efficient process or project that helps sustain the long-term business strategy.
I love these conversations, given we can't complete everything simultaneously. And it helps everyone understand what we can explicitly achieve and sustain.
Change is inevitable
Any project might hit a roadblock, regulations could change, and a competitor might launch an adjacent product.
We need to be nimble in responding to those changes in the context. A project might need a small change, a large pivot, or going back to the backlog until the situation changes again.
Other times, it might not be as radical, but you might face a change in your solution, technology might not be ready, or a team might not be open to handling a requirement from your project.
Conclusion
Plans can change constantly, context changes and even leadership might change, bringing new goals for your organization.
We must be nimble to change our plans and re-organize ourselves quickly. While sometimes we might need to throw the plan out the window, we must anticipate, not be caught off-guard!
We're not perfect, and we might fail while learning. But over time, identifying these possible roadblocks in planning will help us get ahead of risks.
Your turn!
Have you ever participated in planning for quarters or the year? Have you ever had a plan not work out? Or do we have to pivot a project mid-way? Let me know your thoughts by replying to this email!
Happy coding!
Things I discovered in the past week
- I saw things about Zed on YouTube and social networks and started looking into it. It has been cool for the few hours I used it. Maybe I'll take my thoughts into a blog post after using VSCode for so long.
- Lenny Rachitsky's interview with Netflix's CTO Elizabeth Stone was incredible, full of nuggets of wisdom, like managing expectations.
website | twitter | github | linkedin | mastodon | among others