Open niksilver opened 2 years ago
There's not much in here about making/guiding technical decisions. In my experience Tech Leads usually have opinions about
how
things should be built. They suggest technologies to the team, offer feedback on technical ideas and work to understand how all the different parts of a system fit together and what the consequences might be. They take ownership of technical decisions and outcomes. Is this something we should capture?
With the caveat that some of that work is done in conjuction with principal engineers, yes, that should be there. However, I think it is. Maybe I'm mistaken, or maybe it requires a degree of interpretation that isn't obvious.
So here are things which I think capture that - but please do say if these still miss certain things. From various locations, and lightly edited for better presentation here...
summary: Works with the relevant Principal to develop and maintain a technical vision for the product, project or team
example: Has a high level technical roadmap (document, slide deck, diagram, etc)
A technical vision isn't really "how" to get somewhere (it's "where to get to") but the roadmap mentioned in the example should detail the "how".
summary: Breaks down work described in business/user terms into user stories that engineers can work on confidently
example: Adds technical detail to tickets
example: Spends time adding technical details/tasks to tickets
Breaking down the work from business to techncial steps presumably requires understanding how something should be implmented - and not just for that item, but to integrate appropriately with the rest of the system.
summary: Keeps in touch with the team’s engineers, to understand their issues
example: Creates a team environment of psychological safety
I think this is about listening to engineers' feedback and ideas.
summary: Continually ensures the technical plan is consistent with a realistic delivery schedule
example: Adjusts the technical plan according to changing circumstances
Ensuring the technical plan is consistent with a realistic delivery schedule - and changing that as needed - would require an understanding of the suitability of the technologies being used, and how they're used.
summary: Ensures the engineering work of the team is synchronised with other relevant teams, including any in other groups
example: Demonstrates the plan for the team aligns with the work in other teams and groups
This is one part of understanding how the system fits together (especially with external systems), and ensuring the consequences of a system's design are appropriate - achievable, maintainable, reliable, etc.
summary: Ensures risks (not just technical ones) are considered in planning and system design
example: Makes it clear the technical vision or plan accounts for concerns such as security, loss of team members, [...]
This is also about consequences - in particular about being saying what certain decisions entail.
Sorry to bombard you with all of that, but your question was a good one, and it forced me to go back and review the text.
Again, if you think I've got anything wrong here, or if you think things aren't clear enough, it would be good to know.
Yeah, I can see how there is a thread running through the competencies about more active technical ownership. I think the suggestion (made offline) to amend the summary to reflect this is a good one.
The point I was trying to get to (a bit clumsily) is that the Tech Lead should strive to deeply understand the problem space and should be able to use this knowledge to assist/guide the team in making technical decisions by providing context and direction that other team members may not have access to.
If you agree, then something like this might work?
- The Tech Lead guides the technical vision for the team, and provides them with technical coaching and support.
+ The Tech Lead guides the technical vision for the team, maintains an understanding of the problem space and supports the team in making technical decisions by providing coaching and support.
If you agree, then something like this might work?
Thanks, that's a good change to the summary text. I've pushed that up in a new commit.
As discussed initially in a Google Doc, andnow brought into this repository for greater visibility and to merge when appropriate.
Relevant public documents are: