Tech lead transparency

Archive
1

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.

Test resolution:
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.

More here

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.

Test resolutions:

  • 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.

Test resolutions:

  • 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 :price subscription.” 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.

Test resolution:

  • 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.

Test resolution:

  • 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!

Test resolution:

  • 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.

Test resolutions:

  • 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?

Test resolution:

Issue: Managing app release and changing app store guidelines.

Test resolution:

Issue: Rachel is currently doing this role at the expense of product strategy, user research, feature evaluation, etc.

Test resolution: N/A

8 Likes
2

Another example item: this person could help to be on top of things such as our likely Infura upgrade. Helping to understand our options and look into alternatives.

1 Like
3

Thoughts on this would be another plus: Status.app

1 Like
4

Just a huge thank you to @rachel for:
(a) Driving this forward
(b) Documenting the decisions
(c) Sharing them publicly

As is already written above, you’re stepping in and filling the shoes in the absence of this role at the expense of product strategy. Looking forward to seeing resolution to this discussion one way or another, which should result in an improvement to the issues you’ve addressed above.

2 Likes
5

Thanks @naghdy! I appreciate it + also look forward to hopefully getting some more support :slight_smile: