RFC: Tech Plan Decision Making Process
SamRozen opened this issue · comments
Proposal:
The goal of this RFC is to clarify our decision making process for Technical Plans and ensure that teams know how to proceed forward with the highest quality decision. This RFC will focus on roles and responsibilities as well as expected resolution time (72hrs).
tl;dr
- Get feedback fast, from the relevant folks and async if need be.
- Don’t wait for the next practice meeting to work on stuff laid out in a tech plan. Resolve tech plans in 72hrs.
- Practice meetings are best for radiating intent and information. You can always incorporate more feedback on the fly if relevant.
- In doubt, escalate for quick resolution.
Roles & Responsibilities
Disclaimer: The characters mentioned in the examples below are for illustrative purpose only. Any resemblance to reality is purely coincidental. ;-)
Any engineer can take the initiative (and is encouraged) to write/champion a technical plan for a project they lead.
Erik, as the Project Lead for Avalara integration, takes on the technical plan for tax calculations.
The Tech Lead of a team is ultimately the DRI for the tech plans in their team. Their role is to ensure that any meaningful project has the appropriate amount of technical planning, that this tech plan gets the right feedback and that the right decision is landed in a timely manner. The Tech Lead also ensures that technical decisions are in line with our engineering wide technology choices and strategy.
Chung-Yi, as the Tech Lead for Purchase team, ensures that every meaty project has a tech plan and that these tech plans help the Purchase team deliver the right features at the right time and that, overall, they get our company-wide tech stack to a better place. He is glad to see that Erik volunteered for the Avalara tech plan. He’ll keep a close eye on it and will provide Erik with the support and guidance he needs to make it successful.
Stakeholders review and give feedback on the technical plan. It is preferable that key stakeholders are explicitly named in the tech plan. They will usually have specific domain expertise or be closely impacted by the decisions made in this tech plan. By default, if no stakeholder group is provided, all the tech leads will be stakeholders. Stakeholders should provide feedback and inputs. If any stakeholder vetoes the tech plan, they should pair with the DRI to come up with a better plan. It is the DRI’s responsibility to digest all the feedback and land a final proposal. If it’s unclear how to resolve the feedback, they should escalate to the Decider.
To properly compute taxes, Erik needs a lot of information both from the buyer and the seller. He decides to name Jackie as a key stakeholder since she solved similar issues for shipping and also Sepand given his expertise with Exchange. Data Security is key for this project so he also seeks Jian’s advice. The finance team will need some automated reporting so Erik also adds Emma to validate the data pipeline approach.
Every tech plan needs a Decider. By default the Decider is the Product Area Engineering Lead. They may decide though to appoint someone else as the Decider if they feel the other person would be better qualified to help make the right decision. Since not all Product Areas have an Engineering Lead yet, the DRI should suggest any of the other Product Area Leads as a Decider.
Erik works with Chung-Yi on integrating the feedback from the stakeholders, they got conflicting advice and they feel stuck. They ask Sarah to step in and validate the final recommendation.
Anson wrote a tech plan for an integration with a feature flagging tool. Even if this integration will be driven by the Partner Experience team in Core Marketplace, this closely maps closely with the Platform mandate. Sarah decides to make Joey the decider for this tech plan.
The practices should be used as ideation and information radiation forums. The main goals of the practice are: to get ideas and feedback one may have missed otherwise, and to keep a broader informed of the evolution of the platform. (They are not a decision making forum.)
Suggested Timeline & Tech Plan Stages
- Draft Tech Plan can be brought to practices at an early stage to ideate and workshop the best way to achieve some objectives.
- Once the Tech Plan has reached the right level of clarity, it should be transitioned to the Proposed stage. At this point, the goal is to get feedback and validation from Stakeholders and Deciders within 72 hrs. The Tech Plan should be shared in the open (practice channels or #dev are good forums for this.)
- By no means should the champion wait for the next practice meeting to get unblocked.
- Once the final recommendation is landed, then the tech plan is Accepted (or Abandoned)
- The Accepted Tech Plan can be shared with the practice for information / clarity / additional inputs.
- The DRI should continue to incorporate meaningful learnings and feedback as we execute on the tech plan and can issue some Revisions.
Reasoning
Our current process is unclear and doesn't always yield high quality / fast decision making. Too often, people wait for a meeting 10 days away to land a decision. This process should clarify expectation. And as usual, I'm in favor of making more and more expectations explicit as we scale.
Exceptions:
This process is meant to be a suggested guideline to help make things more explicit. If for a specific reason, on certain occasions, you want to proceed differently, you can do so as long as you share why and explain why this process doesn't work for you so that we can iterate on it.
Additional Context:
Prior context on Technical Plans available in our playbook here.
How is this RFC resolved?
- I'm looking for feedback on this way of managing technical plans. I’ll incorporate any suggestions that would make this process easier / more efficient.
- If approved, then we should update the Tech Plan template to make it easier to put this into practice (i.e. clear table with Roles & Responsibilities, RFC Stage, Created Date, Due By Date, etc.).
Resolution
- Moving forward with this
Level of Support
4: Acceptance, with Little Feedback.
Next Steps
@SamRozen will update Tech Plan template.
I like the expliciteness of the technical plan procedure. I have a few questions about the practice meetings though. What exactly are they for usually (before being a forum for technical plans)? How do I know which practice meeting to approach for technical plans that might have some interdisciplinary scope? I am still struggling to understand the scope/meaning of the practice groups.
In order to being able to propose innovation, one needs to have enough breathing time to grow ideas in their minds. I have seen/heard from a lot of people that they feel stressed/burned out/ overwhelmed with the sprint work and don't have the resources to focus on things aside from the tickets that they work off. Maybe this would be a topic for another RFC, but I think we need designated time slots aside from sprint work, that lets people come up with things like technical plans or sparks for ideas of improvement.
Another thing I like about this proposal is the low barrier. I feel like anyone is invited and included to switch on their brains and spark decision making.
@SamRozen I have a few points.
Resolve tech plans in 72hrs.
I think we should think in some terminal condition after this 72 hours in case of no response; even some kind of implicit acceptance/rejection, or some kind of parking lot where we can set a minimum process to drop move forward with the Technical Plan.
My suggestion here is: We can keep 72 hours with an implicit rejection (for the lack of a better term) or longer (5 working days) with an implicit acceptance. The idea would be to have some grace period to not rush the TP or not have enough eyes to check what is going to be made.
Two suggestions (and I think maybe they are out of scope):
(a) Would be great to see somehow some clarification between the Engineering and Product technical plans.
My reasoning here is that the first one is generally more related to aspects that doesn't involve a direct proposition of value (e.g. change of processes, optimization in repositories, include a new pre-commit security check, etc ) and the last one has a direct impact on our collectors and artists (e.g. a faster load page, a new recommender system, data quality for auction results, etc).
And for the last one, would be great to have some expected results that can be attached in some KPI, metric, or product strategy (e.g. product wants to experiment with a new ranking system). This can lead to 3 things: (a) the engineer will consider a broader impact and because of that they will be more insightful when to propose a TP, (b) the team PM will see the estimated impact and will buy in the initiative, (c) as we have (a) and (b) initiatives that can steal our focus will be dropped right away even before to be proposed (and it's fine to drop ideas or rethink about them).
(b) I think worth it at this moment do a small effort to evaluate all Technical Plans and see what makes sense and what doesn't and drop non-useful initiatives. This can help us to have a clear picture of what needs or can be done and give some sense of urgency. For instance: There are technical plans of 2019 without follow-up or even status if will be done in the future or not.
How do I know which practice meeting to approach for technical plans that might have some interdisciplinary scope? I am still struggling to understand the scope/meaning of the practice groups.
I can speak for the Data Practice that I'm helping to facilitate; other practices can have different processes and specificities.
In every engineering standup on Monday, we have the round of each one of the practices with their updates and subjects. Topics vary a lot, but in Data Practice we discuss aspects that will impact other teams beyond the Data/Platform teams in a way that a bigger forum would bring not only a better collective intelligence but most of the time we have people with skin in the game participating in all discussions and giving their feedback or areas of concern.
Practical example: In a Platform Practice in April we started with the following question: "How should Artsy's system interface with Redshift?"
Basically, the goal was to discuss and align the best practice(s) related to future directions of Redshift's utilization by Artsy's systems.
Before the meeting, @ansor4 and I prepared to research, and during the discussion several points were highlighted like: (a) platforms that depend on this database, (b) concerns about latency, (c) the current state or our cluster and how near are we in the full capacity, (d) optimization avenues and future directions, (e) caveats.
If we discussed inside of Platform/Data forums I think that maybe we would go for a suboptimal route, but because our colleagues of CX and Auctions we realized that this was not the best route to take due to some limitations.
I really like this thinking overall, thanks for taking the time to write it up! I did have a question for you when I saw this part:
The Tech Lead of a team is ultimately the DRI for the tech plans in their team.
and
By default the Decider is the Product Area Engineering Lead.
I'm concerned when neither party is the author of the tech plan - are we missing an opportunity to empower the people closest to the work?
Thanks everyone for the comments so far, I'll do my best to answer everything here.
Technical plan are most often used as part of a larger project brief that includes details as to why we're doing this, measures of success etc. See for instance this one for CMS Checklist🔒
@fclesio maybe your suggestion then is just about adding a lighter weight version of the Brief Template🔒 alongside a technical plan if it's engineering driven.
@kajatiger we encourage teams to take advantage of Future Fridays to have time to ideate and explore tech driven improvements. It's a great opportunity to make incremental progress on tech initiatives outside of the normal product work. If teams get closer to an important release and don't feel they have the breathing room to take advantage of the Future Fridays, then we're also encouraged them to save these day and use multiple at once post release to catch up.
To your comment @jonallured about why being so explicit about TL and Product Area Lead responsibilities there: the intent is to provide a quick escalate path if the feedback is hard to integrate, the tech plan champion is ensure as to how to move forward. The stakeholders should be the close to the work and have valuable inputs to contribute. I also expect the Tech Lead to have a clear idea of the technical decisions made across the team and be able to support the champion even if they don't author the tech plan. Finally I've seen some tech plans in the past stuck after a discussion at the platform practice because everyone is confused as to the next step / how to proceed to decide. Having an explicit decider should help us remediate that going forward. I welcome your suggestions about a different model if you have something else in mind.
@SamRozen When you have a moment, it might be nice to update this thread with our RFC resolution template.