“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?
• Coaching
• 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

1. 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
2. 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
3. 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
4. Time management – be available – spending time on tech design, talking to the business, project management (ex: help write user stories) and code
5. Be a mentor for your team – facilitate discussion. Help team becomes stronger developers. Delegate. Optimize for the group/team
6. 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
7. 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
8. Embrace cultural differences – diversity, culture, family. Your users are different too.
9. 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.
10. Interfacing with the outside world – want to be the go-to person, but not the single point of failure
11. Faciliate an agile and awesome team

Other notes/tips

• 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.