MANAGEMENT / JUDGMENT & SUPPORT
The TL Brings Options. What Does the Manager Take On?
Based on the team structure, management expectations and version decision experience I provided. The explanations and questions are editorial extensions; the wording still awaits review.
I expect a Technical Lead (TL) to develop their own thinking first. When they need help deciding or need support, they bring several possible answers to the discussion.
Own your area and help across teams
I divided the work into three teams: System, WiFi and 5G. Each has its own responsibilities, and they also help one another.
Responsibilities give each team an area to own. Helping across teams allows different expertise to connect around a problem. Both deserve attention: who owns each part, and how collaboration connects when another team is needed.
The TL starts with their own thinking
I expect the TL to have a view first. If they cannot decide or need support, they come to me with several possible answers.
Possible answers give the discussion a concrete starting point. We can then examine why those options are being considered, their advantages and disadvantages, and where we still need to exercise judgment together. The TL's understanding of the problem can become clearer through that discussion.
The manager connects judgment with support
My role includes judgment, trade-offs, analysis of advantages and disadvantages, resource adjustments and external coordination.
These responsibilities connect. When considering a proposal, we need to look at its benefits and what adopting it would require us to take on. After making a trade-off, we still need to consider the resources it requires and what needs external coordination.
The TL brings their thinking about the problem. The manager helps connect judgment with the support needed. This is my expectation of how the two roles work together.
Version choices: the TL assesses the costs, the Manager decides the timing
A cross-team version decision made this division of responsibility concrete. We needed to keep up with other teams while considering the impact on each other's builds and development work. The TL compared following develop with using stable branches, laying out the advantages, disadvantages, affected areas and costs of each option.
Who bears the cost of an update?
When a new feature reaches only some repositories, dependencies across repositories can become a problem. A build may fail. A harder problem is a build that reports no errors but produces incorrect runtime behavior or even a crash.
These risks can require substantial debugging time, along with work to resolve other teams' build problems. The effects of an update can spread and delay shared progress. Comparing the options also means considering that effort and impact.
Accepting a lag in features
At the time, I decided to branch from a stable version. That had a clear cost: new features would not arrive immediately, and our device would lag in features behind some products already at EA, RC or GA.
I accepted that cost and assessed when to follow develop. I considered whether the features we needed had been adopted in other products, and whether those products were at EA, RC or GA, as evidence for assessing the timing. Adoption in other products informed the decision; it was not a substitute for integration validation on our own product.
Keeping options for updates
Branching from a stable version left us with options: we could cherry-pick the commits we needed from develop, or wait for the other team's next version to reach EA, RC or GA before assessing an update. Selecting commits still requires attention to dependencies and integration impact.
Later, I observed the system entering a stable period without disrupting the other teams' development. The TL subsequently expressed appreciation for the decision.
Looking back, the TL's analysis of the options and costs gave me a basis for taking responsibility for the timing. The decision accepted a lag in features while accounting for how integration and debugging could affect shared progress.
Three questions to move the discussion forward
These questions are editorial extensions of the principles above. Adapt them to your team's situation:
- Which options are we comparing? What supports each option, what are its advantages and disadvantages, and what remains unknown?
- Where is the manager's help needed? Is it joint judgment, a trade-off, resources or external coordination?
- Who takes on the next step once a direction is chosen? Are each team's responsibilities and the parts requiring joint support clear?
Context
Based on the team structure, expectations of TLs, manager responsibilities and version decision experience I provided. Dependency failures and debugging costs describe the risks considered, not a claim that every failure occurred in this incident. The reported outcome is my observation, and the TL’s appreciation is feedback I have recounted; no observation period or quantitative validation records are provided. The explanations and discussion questions are editorial extensions; the wording awaits my review. This article does not claim a complete operating procedure or member development outcomes.
Content revision: — Added a cross-team version decision, role responsibilities and subsequent observations.
Content revision: — Added the cost of delayed features, cross-repository dependency risks and their impact on shared progress.