|
|
|
|
|
by nostrapollo
2323 days ago
|
|
I am two years into being an 'inexperienced tech lead', and I think there are some good pieces of advice in the other comments. But I think the most important thing seems to be having some structure to your progress in all of the mentioned categories. When dealing with your team have an objective in mind for not only the conversation or meeting but for the takeaways you want your team to have. Take note of what assumptions changed your mind for certain decisions. Assume you're wrong and need to experiment to be right. More practically: I write down feedback that is given to me regarding leadership style and write down things that I think about at the 'moment of impact' (assumptions, reasoning, and metrics for success/failure of decision) when decisions are being made. Read over these notes often enough that you are aware of those things when they happen again. Anecdote: Developers often want time to create a quality feature and if they are frequently pressed for time due to business requirements, they are unhappy and the product suffers, often in less than obvious ways. It was only really obvious that this was a problem when we tried other ways of planning and prioritizing because the assumption was that development pressure was a given for a tech company, turns out that some development work can be offloaded by better planning and prioritization based upon better thought out business objectives. These learnings came about because we kept took notes of decisions that were made, and could refer back to them as crucial points of pain/cost/failure. If you don't have some structure to your approach, you'll find it difficult to call out specific changes that need to happen. There's a lot more that could be said. Tech leads are often interfaces for other parts of the business so respecting the context of other's roles and aligning incentives is more important than proving your job is being done 'correctly'. |
|