How engineering leaders can write better proposals

Upgrade your writing techniques to create the most user-friendly proposal documents you can.

As an engineering leader, you’ve likely faced the challenge of writing proposals for ideas you’re passionate about, whether it’s drafting design docs, request for comments (RFCs), memos, or even slide decks. The format might change depending on context, but the fundamental challenge remains: how do we make our ideas resonate?

Throughout my career, I’ve witnessed numerous promising ideas fall by the wayside or need a lot of back and forth due to a lack of clear articulation. The culprit? Often, a missing ingredient from the six crucial elements of a persuasive proposal.

Knowing how to craft proposals that communicate and inspire action will ensure that your next proposal isn’t just read, but acted upon.

1. Establish context

At the heart of a compelling proposal lies the establishment of mutual understanding. Begin by elucidating the “why.” Resist the urge to dive straight into the solution.

For instance, if you’re proposing a shift in system architecture, listing the current system’s flaws might seem intuitive. However, the real starting point should be “Why now?” What future changes do you foresee that necessitate this shift? Relate your proposal to your organization’s KPIs, OKRs, or overarching strategy.

Drawing inspiration from Stephen Covey’s The 7 Habits of Highly Effective People, it’s paramount to prioritize understanding before seeking to be understood. By ensuring your proposal resonates with your audience’s concerns, you pave the way for consensus.

Example of establishing context in a proposal:

With the rapid growth of our user base and the increasing complexity of our application, our existing architecture is becoming a bottleneck. Recent post-mortem analyses of outages have pointed to scalability and tight coupling issues.

Our company’s OKRs aim for a 20% increase in user engagement and a 30% growth in active users over the next year. To achieve this, we need an architecture that is resilient, scalable, and can be iterated upon quickly.

2. Identify the problem

Once mutual understanding is established, it’s imperative to identify the core issue or opportunity your proposal targets.

Begin by articulating the current state, grounding your discussion with metrics and data. Subsequently, spotlight the primary areas of concern with the existing situation and, based on this, formulate your hypothesis.

Overall, you should seek to emphasize the gravity and ramifications of the problem, positioning yourself as the authority spotlighting an urgent issue.

Example of identifying the problem in a proposal:

Current state:

Our monolithic application has been the backbone of our services for the past five years. During this time, we’ve seen:

User growth: A 300% increase in active users.

Feature expansion: The introduction of 50+ new features, increasing the complexity of our codebase.

Deployment frequency: An average of one thousand deployments per month, with each deployment introducing an average of three new features or improvements.

While this growth and activity indicate a thriving product, they’ve also introduced challenges:

1. Latency concerns: Our API response times have gradually increased over the past year. During high-traffic periods, we’ve observed a 30% increase in API response times compared to the previous year, impacting user experience.

2. Tight coupling: The intertwined nature of our services has become more evident. 20% of new feature releases in the past six months have resulted in regressions in unrelated areas, indicating a lack of modularity and separation of concerns.

3. Deploy time: The complexity of our application has affected our deployment times. Each deployment now takes an average of one hour, a 25% increase from the previous year. This affects our ability to swiftly deliver value to our users and maintain a reasonable MTTR.

Hypothesis: By migrating to a microservices architecture, we can achieve faster deployment cycles, better scalability, and independent service evolutions, leading to improved uptime and stable user experience.

3. Present options

When proposing solutions, it’s vital to consider various options. As Chip Heath and Dan Heath advise in Decisive: How to Make Better Choices in Life and Work, follow the W.R.A.P process: widen your options, reality-test your assumptions, attain distance before deciding, and prepare to be wrong. 

The W.R.A.P process will help you avoid common pitfalls in decision-making, such as the framing trap, confirming-evidence trap, overconfidence trap, and forecasting trap.

This also builds credibility as an honest analysis rather than a biased proposal. This stage is about demonstrating your critical thinking skills.

Example of presenting options in a proposal:

• Option 1: Incremental refactoring
  Pros: Lower immediate risk, can be done during regular sprints.
  Cons: Longer overall transition period, potential for accumulating tech debt.
   
• Option 2: Big bang rewrite
  Pros: Clean slate, can design with best practices from the start.
  Cons: High risk, requires significant resources, longer time to see benefits.
   
• Option 3: Hybrid approach (starting with core services and expand outwards)
  Pros: Balances risk and allows for learning and iteration.
  Cons: Requires careful planning and coordination.

4. Create a roadmap

With a recommended solution, it’s time to detail the implementation. Envision your proposal as a meticulously planned sequence.

Create a timeline detailing the steps, assign responsibilities, and set expectations for each stage.

Like a conductor leading an orchestra, your proposal should coordinate a unified effort toward the intended result.

Example of outlining a roadmap in a proposal:

• Phase 1: Identify and isolate core services.
  Duration: 1 month
  Responsible: Architecture guild
   
• Phase 2: Develop the first set of microservices and integrate them with the existing system.
  Duration: 3 months
  Responsible: Teams A and B
   
• Phase 3: Gradual rollout to a subset of users and gather feedback.
  Duration: 1 month
  Responsible: QA team, DevOps, and user feedback group
   
• Phase 4: Full transition and decommissioning of old components.
  Duration: 2 months
  Responsible: All engineering teams

5. Highlight risks

Analyze potential risks and challenges associated with the proposal, as well as the likelihood and impact of those risks. Provide strategies or plans to mitigate these risks, showing preparedness and foresight.

Examples of highlighting risk in a proposal:

• Risk: Integration challenges with existing systems
  Likelihood: High
  Impact: Moderate
  Mitigation: Begin with a pilot project focusing on one or two core services to understand integration pain points. Use this pilot to develop best practices for subsequent integrations.

• Risk: Potential downtime during transition
  Likelihood: Medium
  Impact: High
  Mitigation: Schedule migrations during off-peak hours and ensure rollback strategies are in place. Communicate potential downtimes to stakeholders well in advance.

• Risk: Team’s learning curve with new architecture
  Likelihood: High
  Impact: Medium
  Mitigation: Invest in training sessions and workshops focused on microservices best practices. Pair experienced team members with those less familiar during the initial phases.

• Risk: Increased initial costs
  Likelihood: Medium
  Impact: Medium
  Mitigation: While there might be an upfront cost due to the transition, the long-term benefits in terms of scalability, maintainability, and faster deployment cycles are expected to offset these initial expenses. Regular cost-benefit analyses will be conducted to ensure we remain on track.

• Risk: Complexity in monitoring and logging across services
  Likelihood: Low
  Impact: High
  Mitigation: Adopt centralized logging and monitoring solutions that provide a holistic view of the entire system. This will aid in quicker issue detection and resolution.

6. Prompt action

Summarize the proposal’s main points and clearly state what you’re asking stakeholders to do next, whether it’s providing feedback, giving approval, or allocating resources.

Include any additional information, data, charts, or references that support the proposal but might be too detailed for the main body. This provides a deeper dive for those interested.

Example concluding aspect of a proposal:

In light of the challenges posed by our current monolithic architecture and the company’s ambitious growth targets, transitioning to a microservices approach emerges as a strategic imperative. The hybrid approach, which combines the strengths of incremental refactoring and a more comprehensive rewrite, offers a balanced and pragmatic path forward.

We’ve identified potential risks associated with this transition and have proposed robust mitigation strategies to address them. The success of this initiative, however, hinges on a collaborative effort, cross-functional alignment, and shared commitment.

Next Steps:

Feedback round: We invite stakeholders to review this proposal and provide feedback by [specific date].

Pilot execution: Post feedback; if there are no strong objections or concerns, we will commence the pilot project.

We’re at a pivotal juncture, and the decisions we make now will shape our product and capabilities for years to come. Let’s collaborate, innovate, and steer our organization towards a future-ready architecture.

Final thoughts

In conclusion, crafting a persuasive proposal goes beyond organizing information in a digestible pyramid structure. It’s about weaving a narrative that resonates with the organization’s core objectives, prospecting a path forward, anticipating risks, and compelling stakeholders to take action.

When writing your next proposal, see it as more than a document. It’s a powerful call to action, a catalyst for change, and a testament to your leadership acumen. The quality of your proposals can shape the trajectory of your projects, teams, and, in the grander scheme, your evolution as an engineering leader.