Kniha: Talking to Tech Leads (Patrick Kua)
This book is full of experience of actual Tech Leads. They share their experience on what is their job about, what are their challenges and what skills they need.
What Tech Lead does?
Focus on big picture He has to see software application as a whole. He has to think about future and about whole full context of the application. About business part, about other teams if there are some and about all stakeholders involved.
Focus on the team He has to make sure that team’s working is smooth. He has to watch team interactions, see or even anticipate conflicts and solve them. He has to motivate individual team members and support them in their learning and development. He also has to make sure that every team member is going to the same objective and that it is the right objective.I like the quote “We are not paid to enjoy ourselves at work, but it doesn’t hurt.”
Technical solutions Developers usually focus on their task at hand. Tech lead focus on common things. He set code quality rules and make sure they are followed. Often Tech Lead and Software architect is the same person so software architecture is another responsibility. As is managing technical debt. Tech lead has to think about influence of particular changes on deployment and other operations and on long-term maintainability.Tech lead also should write code. This it is not a priority but, even from my experience, it is necessary to write some code. Otherwise it is much more difficult to make decisions about code and you loose credibility for the other developers.
Communication bridge between non-technical and technical people As Tech Leads are usually recruited from former developers this is tough one. Tech lead spend lots of time on meetings with business people and his task is that developers and business understand each other.
Tech Lead’s skills
Sometimes it looks like Tech Lead has to be team’s MacGyver – person who can solve any problem. He has to be competent in lots of technical things but unlike developer he has to be able to
- facilitate team’s discussions
- sense conflict or other blocker in the team and solve it
- motivate, teach and develop team members (also to know their feers and aspirations)
- explain complex technial things to non-technical people
- be assertive and make technical risks visible and understandable for non-technical people
- make a guesses about future risks and impact
Other interesting points and quotes
- When starting with a new team, I ask myself, “Does everyone feel comfortable expressing their opinion?”
- First seek agreement on the core problem being solved, before entertaining any solutions.
- As a developer, you probably spend most of your time giving opinions. Your Tech Lead role requires you to now listen to all the opinions and find the best solution. I do not present my ideas first but encourage others to share their ideas.
- Watch out for when an individual unnecessarily adds another way of solving a known problem. It may point to hidden conflict in the team.
Other books mentioned in this one
- Benson, Jim and Tonianne DeMaria Barry: Personal Kanban: Mapping Work | Navigating Life, CreateSpace Independent Publishing Platform, 2011.
- Managing Humans: Biting and Humorous Tales of a Software Engineering Manager Carrots and Sticks: Unlock the Power of Incentives to Get Things Done Target Risk 2: A New Psychology of Safety and Health Agile Estimating and Planning Planning Extreme Programming Blink: The Power of Thinking without Thinking
- “Your Brain at Work” (David Rock)
- recommend these books: Becoming a Technical Leader by Gerald Weinberg Notes to a Software Team Leader by Roy Osherove Presentation Zen: Simple Ideas on Presentation Design and Delivery by Garr Reynolds
- books like Crucial Conversations: Tools for Talking When Stakes Are High, How to Argue & Win Every Time: At Home, At Work, In Court, Everywhere, Everyday and Behind Closed Doors: Secrets of Great Management.
- StrengthsFinder 2.0
- Anything by Weinberg is amazing, but if I had to choose one, it would be General Principles of System Design (although Becoming a Technical Leader may also be fitting in this context).
- Brown, Simon: Software Architecture for Developers, Leanpub, 2012.
- Cohn, Mike: Agile Estimating and Planning, Prentice Hall, 2005.
- Derby, Esther and Johanna Rothman: Behind Closed Doors: Secrets of Great Management, Pragmatic Bookshelf, 2005.
- Gladwell, Malcolm: Blink: The Power of Thinking Without Thinking, Back Bay Books, 2007.
- Patterson, Kerry, Joseph Grenny, Ron McMillan and Al Switzler: Crucial Conversations: Tools for Talking When Stakes Are High, Second Edition, McGraw-Hill, 2011.
- Rath, Tom: StrengthsFinder 2.0, Gallup Press,
- Spence, Gerry: How to Argue & Win Every Time: At Home, At Work, In Court, Everywhere, Everyday, St. Martin’s Griffin, 1996.
- Weinberg, Gerald M and Daniela Weinberg: General Principles of System Design,
Overall I liked the book. Although all Tech Leads were talking about similar topics it was worth reading all of them.