“10 tips to become an awesome tech lead”
Speaker: Bart Blommaerts
For more blog posts from JavaOne, see the table of contents
Not one free seat in the room and long wait list line. [I wait listed and left the keynote 5 minutes early to ensure I got in]
Role of Tech Lead
- Provide tech leadership
- Protect team from interruptions
- What new libraries/frameworks should we use? What are risks?
- Communication – bridge gap between devs an business
Do we need one
- In ideal world, don’t need tech lead
- Hard to do everything by consensus
- Unlike the lego movie, everything is not always awesome
- Business still needs point of contact
- New people still need training
The ten tips
- Advocate for change – don’t want people to be afraid of prod, need to evolve. Try to make stupid processes better. OODE – observe/orient/decide/act
- Work through failure and success – prepare for failure, don’t finger point (“we”), take responsibility, learn from failure, problem if you are fixing the same bug twice – that is process failure. Celebrate success – sprint celebrations, feature complete, congratulate team/individuals
- Stay technical – write code, review code, tech vision (and get buy in; ideally with everyone contributing to it), evolution of code. Don’t forget about security/networking
- Time management – be available – spending time on tech design, talking to the business, project management (ex: help write user stories) and code
- Be a mentor for your team – facilitate discussion. Help team becomes stronger developers. Delegate. Optimize for the group/team
- Surround yourself with other tech leads – on a personal level, see what others do to get ideas and learn. On an organizational level, look at common org/architecture along with interoperability/dependencies
- Interviewing potental new team members – know your goals. For short term,, looking at tooling. For longer term, look at eagerness to learn. Don’t use stack overflow to find questions; pick things relevant to your project
- Embrace cultural differences – diversity, culture, family. Your users are different too.
- Estimating is hard – “Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.”. Planning poker. Uncertainty is normal. Add 20% for test/debug/polish/documentation/wtf moments.
- Interfacing with the outside world – want to be the go-to person, but not the single point of failure
- Faciliate an agile and awesome team
- Not difficult for tech lead to make things worse
- Need to experience same pain as everbody else on team – you are part of the team
- Be realistic. Not possible to answer every question. Also, need to connect teammates to each other. Ok to request time to look into a question as long as you get back to them. Also ok to suggest pairing.
- Not making a decision is worse than making the wrong decision becuase not doing any work
- Interview style – comfort people (they are nervous; start with a siimple question like “what is the difference between an interface and abstract class in Java”), offer options, build on responses like “what is the difference between interfaces/abstract classes in Java 8”, show interest, bonus question
- Offshoring – work gets done while sleeping, communication harder. Prepare work for remote teammates since they can’t talk directly to business. Harder to make everyone feel like part of team. ex do a night shift “most developers work better at night” [I am so non standard here!] Keep history ex: Slack
He commented about people working nights the last couple sprints to ensure success on the project. [That sounds completely against the sprint of sprints being sustainable]
My take: Nice to have a good tech soft skills talk. I noticed that Bart referred to “technical lead” as “he” whenever he used a pronoun. I wonder if it’s like that in his native language. Google translate says both tech lead and developer use “le” (are masculine) in French. This was more obvious at the beginning; he switched to “you” after a bit. And he said he/she later on.