There are several articles out in the world about engineering strategy. You should carve out an hour, do a Google search, and read the first several. After you do that, I aim to provide you with a tangible guide based on my experiences.
As a company scales, its processes need to become more complex. Strategy is no exception. This guide will scale up and build on previous phases.
Phase One: Expose Decisions
Team Size: 4-10 Engineers
At this early stage, simplicity and accessibility are key. Start by creating a centralized repository to easily access and edit all decision documents. Each document should follow a lightweight template that covers the essentials: the decision being made, the rationale behind it, the alternatives considered, and the expected impact. This template should be short enough to be quickly produced and read, encouraging frequent updates and consultations. Encourage the team to document decisions as they are made, keeping the process as informal and low-friction as possible. This approach not only ensures that critical information is captured and shared but also fosters a culture of transparency and collective decision-making right from the start.
Here’s a sample simple decision doc to give you an idea:
Decision: Implement Tailwind CSS
Date: 2024-03-28
Contributors: Pat, John
Decision: Use Tailwind CSS for our project.
Why: Enhances speed and consistency in UI development; offers a lightweight, modular approach.
Alternatives: Bootstrap (too generic), Foundation (complex), Vanilla CSS (time-consuming).
Impact: Expected faster development, consistent UI, and improved load times. Initial learning curve.
Tips:
Use a tool like notion or confluence to simplify your knowledgebase
Create a template
Make sure it’s easy to review all previous decisions. For example, if you derive your template from Confluence’s decision doc template, you get a macro for free: https://community.atlassian.com/t5/Confluence-articles/Decision-report-macro-now-available-to-aggregate-all-your/ba-p/1521548.
Phase Two: Periodic Leadership Review
Team Size: Multiple Engineering Leads/Managers (likely 8-15 engineers)
As a business grows and evolves, periodic engineering leadership reviews become a critical juncture for strategic development. This phase is about more than just evaluating past decisions; it's a foundational process where engineering leaders start to formalize the practice of objective setting itself. Through review, leaders can identify patterns of success and areas needing improvement, laying the groundwork for more structured goal-setting. The review acts as a catalyst for transitioning from ad-hoc decision-making to a more strategic, goal-oriented approach, gradually hardening the process of setting clear, measurable objectives that drive the business forward.
Keep the simplicity theme going for this exercise. Start with a simple template, review the decisions, reflect on how you felt about the quarter, and try to predict the next quarter. Rinse, wash, repeat.
I recommend that your engineering leader fills out the template ahead of a meeting and then your team discusses the document for an hour, makes refinements, and adjusts action items.
Here’s a template to fill out:
[Date] Leadership Review
Date: [date]
Past Quarter Decisions:
[enumerate all decision docs]
Quarter Reflections:
General Feel: [Few words on team sentiment]
Biggest Win: [Highlight the biggest success]
Biggest Challenge: [Highlight the biggest challenge]
Next Quarter Goals:
Focus Areas: [Key areas to focus or improve]
Risks: [Things that may hinder our goals]
Action Items:
[add any action items that come up]
Here’s an example:
2024-Q1 Leadership Review
Date: 3/29/2024
Past Quarter Decisions:
Implement Tailwind CSS
Hold off on service layer refactor
Keep payments service in monolith
Quarter Reflections:
General Feel: Concerns over growing tech debt
Biggest Win: Tailwind is already paying dividends
Biggest Challenge: Our sales season has been more demanding than we anticipated. This led to incurring additional tech debt in several areas.
Next Quarter Goals:
Focus Areas: Experiment with ways to reduce new debt.
Risks: If new sales don’t slow down (which is a good problem to have), we could continue incurring more tech debt than we feel is healthy.
Action Items:
Pat - Experiment with post-release cool-down periods. Schedule them after our upcoming sprint as a cool-down sprint on 4/21. Why: We believe that a cool-down sprint after our upcoming sprint will allow us to pay down some of the tech debt during the previous sprint without slowing down time to market.
Pat - Schedule a sales volume check-in one month from now to review sales speed on 5/1. If it is still at the same speed, we need to discuss some upcoming roadmap tradeoffs and how we might scale up the engineering team to handle the demand. Why: A successful business needs to scale. In the past quarter, we saw an increase in sales leading to an increase in tech debt. If this increase in sales is here to stay, we likely need to hire more engineers.
Conclusion & Next Up
As we wrap up, remember that the essence of engineering strategy lies in simplicity and adaptability. These initial steps are just the beginning of a journey towards a more structured and strategic approach as your team grows. Keep an eye out for future articles where we'll dive deeper into scaling strategies for larger teams and the ongoing challenge of balancing innovation with efficiency.
Any questions or feedback? Please let me know in the comments!
I'm curious to hear if you implemented the second layer of review yourself. This first thing I thought is that this could turn into a gating process, which would be an anti-pattern for agile delivery. What cmae to mind was more of a realtime flow of information distilled down to those items needing those most attention (both good and bad). That is, more of a realtime model--probaby enabled by agents--distilling insights from team meetings, peer interactions, changes in tracking systems and dashboards, etc. That way, you only introduce the gates when they're needed--when something is going off track.
That said, I'd be very cautious to take a hands-off approach--the agents (bots) are likely to need close supervision. 😊