Planning in Software Engineering: Lessons from Startup to Big Tech
Dev Leader Weekly 128
TL; DR:
Context shapes everything
Stop optimizing for the perfect plan
Know your stakeholders deeply
Join me for the live stream (or watch the recording) on Monday, February 23rd at 7:00 PM Pacific!
Why Everyone Seems to Have a Different Opinion on Planning
I want to talk about planning in software engineering -- and more specifically, why people seem to have such wildly different takes on it.
Here’s something I’ve noticed. You come across someone who’s had a successful career, and they describe how they do planning. Makes sense, you note it, maybe you try to apply it. Then you find someone else -- equally successful, equally confident -- doing it in a completely different way. And you’re left thinking: how are both of these people right?
The answer is almost always context. When people share their perspective on planning, they almost never include the environment that shaped that perspective. And that missing context is what makes everyone sound like they’re contradicting each other.
Think about someone who spent their career building satellite infrastructure or delivering government contracts. Their planning approach is going to look fundamentally different from someone who built a scrappy startup from scratch. Both of them are right -- they’re just responding to completely different constraints, completely different risks. If you pulled both people into the same room and actually mapped out what they value and what they’re trying to optimize for, I’d bet there’s a lot more overlap than it first appears. The differences come from the environments that shaped their thinking.
I wanted to get that framing out of the way first, because everything I’m about to say is colored by my own experience. Two data points: Magnet Forensics, a startup where I joined at around seven or eight people, and left when we were around 250. And Microsoft, where I’ve been for over five years, working on the Microsoft 365 / Office 365 side of things. These are just two examples -- they do not represent all startups or all of big tech. Keep your own environment in mind as you read.
You can check out my full thoughts on this in the video below:
What Planning Looks Like When You’re Drinking From the Fire Hose
In the very early days at Magnet Forensics, planning basically didn’t exist. Everything was the highest priority. A customer requested a feature? Drop everything, go build it. A bug got reported? Drop the feature, go fix the bug. Ship the bug fix and accidentally break something else? That’s tomorrow’s surprise.
It was chaos. And honestly, for where we were, it made some sense. You can’t really plan two weeks out when you’re still figuring out if anyone’s going to use your product.
One of the things I spent real effort on during that era was managing escalations. The CTO cared deeply about his customers -- this was his product, built from scratch out of necessity, and he was fiercely proud of it. When something got escalated to him, it was the most important thing in the world. My job was to come to him with a full picture -- here’s everything on our plate, here are all the other priorities, here are the tradeoffs -- and then ask: knowing all of that, do you still think this is number one? Over time, those conversations got shorter because we built mutual trust and a shared understanding of what mattered. He’d see the full picture and more often than not land at “yeah, okay, carry on.”
Gradually, we introduced sprints. Two-week sprints. And I’ll be honest -- even that felt like overkill at first. Two weeks out? We’re going to be doing completely different things by then anyway. But we built the habit. First two weeks, then a bit further, eventually quarterly.
The goal was never to nail the plan perfectly. The goal was to build the muscle of looking further ahead.
By the time I left, we were working with OKRs -- Objectives and Key Results. I have mixed feelings about the framework itself. People waste an absurd amount of time debating the wording and structure of key results. But the underlying concept is something I genuinely believe in: you’re setting a goal to move a metric, not to ship a specific feature. The how is for you to figure out. The key result is the destination -- reduce latency, improve onboarding rate, move some number from A to B. How you get there can change along the way.
And that’s the thing: the most valuable planning conversations we had weren’t about shipping dates and locked deliverables. They were about alignment. Are engineering and product actually pointing in the same direction? Are we measuring success the same way? What does “done” actually mean here? Those conversations moved the needle. The hours spent trying to lock in dates and enforce commitments? A lot of that was wasted energy.
How Planning Changes at Scale
At Microsoft, planning is a completely different beast. We do semester planning -- six months at a time. And because of the sheer number of teams and dependencies involved, you often need to be thinking about the next semester while you’re still planning the current one.
The reason is dependencies. When you’re working at platform scale, getting anything meaningful done usually requires another team to deliver something first. If you don’t get ahead of that conversation early -- if you’re not on their roadmap before they lock in their plans -- you’re going to be blocked. So you’re always playing this forward-looking dependency game: who do we need things from? Who’s depending on us? How far ahead do we need to start those conversations to actually have a shot at being unblocked in time?
The challenges, though, aren’t that different from a startup.
Plans change. Priorities shift. At Microsoft, if something critical surfaces in the security space, that jumps the queue -- full stop. It needs to. That’s the job. The difference is scale: at a startup, telling someone your plans changed might mean a conversation with one product owner. At Microsoft, it might mean fifteen other teams just got their plans disrupted.
Actionable Tip: Know your stakeholders -- not just who they are, but what they’re trying to accomplish and what they’re depending on you for. When your plans shift (not if -- when), getting ahead of it as early as possible lets you work with your stakeholders to adjust. The surprises that derail projects aren’t usually the changes themselves; they’re the changes people find out about way too late.
I’ve seen this play out firsthand. You’re three months into a six-month plan. A partner team drops something on you: “Hey, by the way, we’re not going to hit our commitment -- just so you know.” And when you dig in, there were signs of this two months ago. The communication just never happened. That lag is what causes damage.
Stop Trying to Make the Plan Perfect
Here’s my biggest takeaway from all of this: the goal shouldn’t be to build a plan that never changes. The goal should be to build a team that handles change well.
I’ve watched organizations pour enormous amounts of time into making the plan airtight -- anticipating every dependency, locking in every date, getting every commitment in writing. And then something unexpected happens (as it always does), and a lot of that effort evaporates.
I’m not saying don’t plan. Plan. Have a direction. Have milestones. Have a roadmap. But be honest about what you’re actually optimizing for. If most of your planning energy goes toward “how do we stick to this plan no matter what,” that’s the wrong optimization.
Instead, here’s what I think is actually worth your time:
Get alignment on direction and success metrics -- not just which features you’re shipping, but what you’re trying to move and why
Map your dependencies early -- both what you need from others and what others need from you
Communicate early and often -- if you’re falling behind, say so now, not three months from now
Build agility into the plan from the start -- leave room to adjust, because you will need to
The OKR concept captures a lot of this well, even if the framework itself can get annoying. You set a goal to move a metric from A to B. How you get there can flex. What you’re trying to achieve stays consistent. That consistency -- the direction -- is what you’re really protecting when you plan.
Your Environment Is the Variable
Let me close with the thing I opened with: context.
How much planning you need, how rigid it should be, how far out you should look, how much agility to build in -- all of it depends on where you’re working. A ten-person startup looks nothing like a platform team at a large enterprise. A company with physical products and multi-year contracts looks nothing like a cloud security team shipping continuous updates.
Neither approach is right or wrong. They’re both responses to different constraints and different risks.
So the next time you hear two engineers give completely different answers about how planning should work -- and both of them swear by their approach -- before deciding one of them is wrong, ask what environment shaped that perspective. I’d be willing to bet there’s more common ground than it first looks like.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!