Planning is fundamental to the success of any tech team’s initiatives. It is a core part of any team delivery cycle, regardless of what field you are in, or methodology you use, weather it be the SCRUM ceremony that we are familiar with in tech, or some completely different planning process used in the manufacturing industry (for example); planning is always an essential part of successfully delivering a plan. It allows us to estimate that what we are committing to is achievable within given timeframes, and it allows us to align with other teams, so that large initiatives do not get derailed by unexpected situations (eg. a team commit to certain deliverables within set timelines, and then find out mid-project that something important was overlooked, delaying the whole project; or one of the teams working on an epic finds themselves involved in multiple projects concurrently, and is unable to handle the load, so the whole project is delayed etc).
Alignment
If we don’t know why we are investing, then we can’t know how to invest.
Product focuses on the what and why of a product, defining its vision, strategy etc, while engineering focuses on the how and when 1 2 3. It is impossible, as an Engineering Manager trying to define the how and when, without first aligning on an understanding of “why”.
For example, consider the following request comes to the engineering team:
“We need to add a ‘quick reorder’ button to the order history page so users can easily repurchase items.”
Based on this the engineering team might simply add the button to the order history page, as stated in the request, or reuse existing reorder logic from another page. But if they understand the “why”, for example:
“Customers are dropping off before completing repeat purchases. We want to reduce friction and increase reorder conversion by making repeat buying one-click simple.”
The engineering might propose a very different solution, for example:
- Pre-fill the cart with items but allow edits before checkout;
- Use async loading for faster performance;
- Track reorder metrics with analytics;
- Address edge cases like out-of-stock items or changed pricing.
Similarly, we might get requests for product features, and by understanding the “why”, we find alternative solutions that have a higher return on investment.
For example, consider the following request comes to the engineering team:
“Let’s build an in-app onboarding tutorial to guide new users through key features step-by-step.”
At face value, this seems like a reasonable request, but it’s expensive (involving design, copy, logic branches, analytics, maintenance etc), and will take a few weeks to implement. Furthermore, we have the risk that once we release this new feature, it may not useful to end users (as we aren’t sure if the topics covered are actually what is negatively affecting their user-experience etc). But if they understand the why, lets say:
“New users are not discovering key features and are churning within the first 2 sessions. We want to help them realize value faster.”
Then the team might have proposed higher-ROI alternatives, such as:
- Tooltips or contextual nudges triggered by behavior.
- Improving empty states or default data for instant utility.
- A redesigned landing experience that highlights immediate value.
- Passive onboarding via better UX or microcopy.
These alternatives: take less time to implement; are easier to iterate on; might drive greater activation by meeting users in context, not forcing them through a flow. In this example again, by unpacking the “why” (ie. improve early retention by showing value), the team can explore simpler, faster, and more impactful solutions than the original ask.
So, hopefully these examples help highlight the importance of understanding the “why” and working closely with our product counterparts to create roadmaps, define success metrics, and run quarterly planning together.
Over-Communication
Communicate until you feel sure everyone is aligned (if in doubt, continue).
Misalignment can be the downfall of initiatives; resulting in considerable delays, pushing back timelines, or in the worst of cases restarting entirely.
Over-communicating decreases the chances of misalignment, as despite it being annoying for those who may have acknowledged the comms the first time, it leaves little room for those that did not to simply claim they missed the comms, and can therefore not be held accountable.
Its worth noting that there is risk with over-communication; for example, Meeting Fatigue, Loss of focus, Confusion and Misinterpretation etc. So striking the right balance is essential, here are some points to keep in mind when trying to do so 4:
- Clarity and Relevance: Craft messages that are clear, to the point, and directly aligned with the recipient’s role, ensuring they get only the information that’s useful and actionable—without overload or repetition.
- Purposeful Channels: Choose the right communication channel for each message, using each platform with intention and avoiding redundant messages across multiple tools.
- Empowerment and Trust: Foster a culture of trust by giving team members the independence to manage their work, making decisions without the need for constant check-ins or micromanagement.
- Feedback Loops: Maintain open lines for feedback, inviting employees to share thoughts on how communication is working – and using that input to refine and improve how information flows across the organization.
Guilds/ Workgroups
For large cross-unit initiatives, create temporary project focussed sub-teams.
Consider an organisation structured as in the (very oversimplified) example below, that needs to deliver a new “epic”, over the upcoming months, involving co-ordinating all the departments in the organisation. Large distributed projects like these require clear communication and alignment throughout to be successful. I have experienced the guild/ workgroup approach to be simple and effective in driving alignment.
The process looks something like this…
- Form a guild, made up of leads/ representatives from all the departments involved.
- Divide the epic into smaller projects (eg. by domain, scope, or phase of the project).
- Assess project dependencies, and assign relevant teams to each project.
- Assign a guild leader to co-ordinate the guild.
- The guild assess project priorities, and build a high-level roadmap.
- Projects are ordered based on priority and other dependencies.
- Each team is in only 1-2 active projects concurrently
- A workgroup is formed for each project, made up of leads/ representatives from each team involved.
- Setup async communication channels (eg. a workgroup Slack channel).
- Conduct bi-weekly review to share progress updates, blockers etc (similar to a sprint review).
- Function as pseudo-teams for the duration of their project
- The guild meets at a less regular interval (eg. once a month), for a more high-level progress report on the epic as a whole.
Discovery
Do high-level discovery before committing to deliverables/ setting goals.
This may seem obvious, but I have worked in a unit where we had a large project requiring collaboration between multiple departments, to redesign the core of a very large distributed system, comprised of many services across a number of domains. In an attempt to avoid “analysis paralysis”, the decision was taken, to commit to high-level deliverables and do iterative discovery whist implementing each domain.
While this may sound reasonable, it made it impossible to plan, and a projected 18 month plan quickly turned into a 36 month plan with no clear end in-sight; I do not recommend this approach.
Had the decision been to invest time in doing the discovery first, then realistic timelines could have been set, and despite the longer time initially spent on the discovery, considerably less time would have been wasted later.
The types of issues we faced were iteratively discovering what needs to be done in 1 quarter, and then:
- Trying to align roadmaps with the dependent teams, in-time to begin work in the following quarter,
- Finding out that it will require considerable changes to deliverables from the previous quarters, that are already considered “done”.
Had we been able to create a clearer roadmap, and then begun with the implementation, we would have been able to manage stakeholder expectations and set realistic timelines.
The key take-away; ideally, during each quarter, do discovery for the upcoming quarter, while your (hopefully self-organising) team is delivering the outcomes of the previous quarter’s discovery.
Roadmapping
Visualise your deliverables.
Developing a roadmap is one of the most important things to do with stakeholders and one’s product counterparts. It allows for visualising and understanding all the constituent parts of a plan (eg. which parts need to be done sequentially, or highlighting parts of the project that has dependencies on other teams), and understanding which key milestones need to be met in order to deliver on your goals in time. It additionally allows for sharing the plan with others for a review/ sanity check, or aligning the plan with other team’s plans (eg. roadmaps can be stacked on-top of each other, to better check that there is no capacity overload etc).
Building a strong roadmap with your product counterparts is paramount to creating alignment and confidence that your plan is accomplishable and realistic.
Agility
Don’t plan too far ahead (small iterations).
Plans change as we learn; to remain agile and able to adapt, a general rule of thumb is, don’t plan more than 3 months ahead (coincidentally, 1 quarter), in terms of committing to goals and objectives.
There are a number of different frameworks that companies choose to adopt, but most involve defining a north star for long term goals, and more specific quarterly goals.
This approach is about risk aversion, as it allows us to be flexible, and pivot, without the fear of potentially disregarding months worth of planning, should the company need to even slightly change direction.