Just creating this post as a container for further discussion amongst the core team, and so we can track how these process changes are going.
Today we had some more discussion in #status-core around estimations + backlog management. I’m setting up the spreadsheet for estimates next.
TL;DR for those unfamiliar: the Janitors want to hire a technical team member to facilitate good development processes and decisions, bridge more abstract ideas and long-term strategy with day-to-day execution, and support technical team members in their personal development. We’re referring to this as a ‘tech lead,’ but the goal is really for someone technical to act in service of the team, as Iuri does for Embark and Jacek does for Nimbus.
Problem is, the hiring process at Status has tended to be opaque. In the past, decisions that impact people have been handed down without any prior buy-in from those affected.
In response to that feedback, we decided to first lay out the problems we’d expect a tech lead to help solve, and rather than looking to a single person to be the panacea for these problems, begin by implementing process changes that can (and should) also help.
Problems to solve
Issue: Help with estimating effort for issues.
Planning poker with the team, every 1 or 2 weeks. We can do this asynchronously, and set a deadline by which each team member needs to share estimates. Any discrepancy in estimates should be resolved synchronously.
Issue: Integrate Jarrad’s vision with team execution and represent team concerns, ideas, etc.
Issue: Bird’s eye view of development + interface between Core, keycard, Nimbus, Embark.
Issue: Look 10 steps ahead - use foresight to plan for architectural changes and needs.
- Set up a biweekly sync for the teams to check for dependencies.
- Make clear decisions that are incompatible with potential changes.
- “We don’t even have another team interaction. The only one we might have is Nimbus.”
- “I don’t think we could have been more efficient on the 64 bit fix and the move to Hermes. We identified the problem pretty fast.”
- The tech lead could have prioritised this problem, knowing that we needed to make an interim release with v1 notifications included.
- But - we felt there was too much risk to release in the one week of padding that we had. The decision to make breaking changes (which needed to be announced) was only made then.
Issue: Lead documentation efforts.
- That needs to be made a mandatory part of PRs.
- Could make PR checklist mandatory for PRs again. (Updated checklist)
- “As an external contributor, you start at one place and grow your knowledge based on what you need to touch.”
- We still need a central knowledge repository - after v1, blocking time for this seems wise.
- Issue specs can also be written a lot more clearly. When you estimate an issue, you write, “This will take only 2 hours because there’s already the
:pricesubscription.” Reference issues that have ciruclar dependencies.
- Have a checker script or linter that automatically tells contributors repo rules
Issue: Mentorship / hearing team’s concerns from a techincal point of view and looking out for people. Help managing performance issues.
- Team does not feel this is an issue. (Eric: I think we meant more that it’s not something we can do ourselves?)
Issue: Act as liaison to product & design, free up time for developers to build.
- Team does not feel burdened by this and knows they can respond to questions in their own time.
Issue: Have ownership for implementation decisions. Bridge differ opinions & take accountability for decisions made. Single point of failure!
- We document the different options. The champion has for each has to defend their POV. If no consensus, we vote. And we have documentation to refer to later.
Issue: Uphold integrity around definition of done - problem solve, ensure PR process is followed and code quality standards are maintained.
- Developers agree that they will no longer defer problems found in PRs, e.g. margins.
- This is something estimation might help with. Having more granular specs and acceptance criteria. We also decide whether design is required for that.
Issue: How would hiring decisions and budgets work?
Issue: Managing app release and changing app store guidelines.
Issue: Rachel is currently doing this role at the expense of product strategy, user research, feature evaluation, etc.
Test resolution: N/A