11 June 2017
This post captures my learnings from the The Lead Developer 2017 conference. I’m going to admit that I have missed a lot of nuggets as my brain couldn’t contain the amount of goodies I found in the conference. The conference is jam-packed with so much lessons! I have also collected all of the resources mentioned by the speakers at the last section of this blog.
What is important is seldom urgent and what is urgent is seldom important.
- Dwight Eisenhower
Time management is one of the biggest challenge for new tech leads. One of the most overlooked task is the task that is important and not urgent, which is the top right box of the Eisenhower Matrix. You need to plan these tasks. @patkua shared that it very easy to be trapped in the top left box, where you are constantly in fire-fighting mode to tackle the important and urgent tasks only.
One of the other trap of new tech leads is to focus too much on techs. This is why it is important for you to set your own personal objectives on a yearly basis, as suggested by @mariagutierrez. You have to set and prioritise them by yourself, nobody is going to do this for you. You’ll need to balance the topics that you are keeping up with, don’t only pick up techs but also pick up people and business skills.
This section is fully covered brilliantly by @adrianh. It’s fascinating to find that most of the methods he uses are actually coming from the User Research field because no other fields have covered it better! I have included the books that he had recommended at the last section of this blog. Here is the dos and don’ts to help you improve your 1:1s:
| Dos | Don’ts | Notes |
|---|---|---|
| Shut up (and listen) | “Wait” | It’s common for people to wait for the opportunity to talk and not actually listening. |
| Ask for stories | Ask about futures | ‘Tell me about your worst day last week’ vs ‘Would you be happier if I give you a bonus’ |
| Open question | Leading question | ‘How can we help the QAs’ vs ‘Do you think TDD training would help the QA?’ |
| Be polite | Be an asshole | Watch your body language. People know when you are not interested. They will not know that this is the fourth time you are hearing about the same problem. |
| Write everything up | Trust your memory | |
| Analyse observation | Jump to insights | Separate insights and observations. What people tell you are mostly observations, not insights. |
Leveling up others is your job.
- @JillWetzler
If you have been a lead for a long time, you might have forgotten how it feels like coming in as a junior. @carlyhasredhair shared one of the biggest fear she had when she first enter the software engineering field: ‘Am I improving at the appropriate pace?’. Your juniors might have the same fear, hence set your expectation correctly.
To help set your expectation correctly, @rkoutnik has recommended these new redefined job titles. He has entirely remove the concept of junior and senior, hence you can focus on just levelling up your other team members:
- Do you find that most of your time is simply closing tickets, and your team rarely considers your input? Your title is Solution Implementer.
- Are you given general problems and left to your own devices on how they’re fixed? When brainstorming, is your input considered by your teammates? You’re working as a Problem Solver.
- Are you given near-total autonomy in choosing what you work on? Can you tell your boss “That’s an interesting idea but my time would be better spent elsewhere” (and not get fired on the spot)? You’re a Problem Finder.
People would not feel empowered if they are assigned tasks that suit their level; Problem Solver who are given Solution Implementer would not get the autonomy they need and will eventually quit. @JillWetzler reiterated this further by sharing the 70:20:10 model of career advancement:
The last interesting thing to note on mentoring, @rogaladominika has noticed that the estimation skills of juniors can be made better by simply sharing to them these facts:
Giving feedback when it sucks is your job.
- @JillWetzler
Your team will not improve without feedback. I will not repeat on how important it is to relay feedbacks to your team members, as numerous speakers have mentioned this fact repeatedly. As pointed out by @earcalson, one of the most important aspect of a feedback is you should talk about action, not behaviour. This also goes along with the structure of giving a feedback that @JillWetzler had suggested:
At the peak of abuse of the Agile Manifesto, “We’re Agile, We Don’t Do Documentation” talk by @birgitta410 is right on point to recover the importance of documentation. @birgitta410 and @anjuan had highlighted the footprint that most of us missed in the Agile Manifesto (emphasis theirs):
That is, while there is value in the items on the right, we value the items on the left more.
- Agile Manifesto
The problem with this part of the manifesto is, it can be interpreted differently depending on which era you had entered the software development world. The Agile Manifesto is created on the era where heavy, thick and comprehensive documentations/specifications are created.
Do not do documentation just for the process.
- @birgitta410
Always, always ask the reason of why we are documenting our software. Done correctly, documentation will spark a more efficient and effective discussion. When it’s too comprehensive, people might not read it or it even might be too complete for engineers to stop thinking creatively. I can’t help to highlight that this principle applies to everything that you do in software development: Do not do something just for the process.
Cultural Awareness is your job.
- @JillWetzler
Different people from different countries will have cultural differences. One of the metric shared by @patkua is the Power Distance Index. I find this metric very interesting as I have worked in Malaysia (PDI: 100) and the UK (PDI: 35), which happen to have a very different Power Distance Index and I can definitely relate to them.
How people interpret the result of performance reviews are also different in every country. @roidrage shared how the two countries in his team have a different scale in their performance reviews:
Family background will also contribute to cultural differences, which was outlined by @kwugirl as the ask vs guess culture. It is important to note that neither is better than the other. Here is an excerpt from the original post (Ask MetaFilter):
In some families, you grow up with the expectation that it’s OK to ask for anything at all, but you gotta realize you might get no for an answer. This is Ask Culture.
In Guess Culture, you avoid putting a request into words unless you’re pretty sure the answer will be yes. Guess Culture depends on a tight net of shared expectations.
- @tangerine
Last but not least, here are some tips shared by @JillWetzler to make you more aware on this subject:
The engineering culture cultivated by @roidrage in Travis CI is an interesting one:
These practices help engineers feel both the successes of their work and the pains from the real users.
Slack has zero tolerance for arrogance, as shared by @carlyhasreadhair. For everyone to grow better, everyone needs to have the ability to not feel stupid. This is why they do not hire arrogant people. Slack put empathy and respect to the utmost importance.
| Source | Reference | Link |
|---|---|---|
| @patkua | StrengthsFinder 2.0 | Book |
| @patkua | Talking with Tech Leads | Book |
| @kuwgirl | Congrats! You’re the tech lead. Now what? - Eryn O’Neil | Video |
| @adrianh | Interviewing Users | Book |
| @adrianh | Practical Empathy | Book |
| @catehstn | Engineering Manager Slack Group | Link |
| @birgitta410 | ADR Tools | Github |
| @birgitta410 | The back of the napkin | Book |
| @roidrage | Open Organization | Book |
| @roidrage | Turn The Ship Around | Book |
| @jillwetzler | Female Career Advancement Summed up in One Useful Diagram | Video |
| @lara_hogan | Demistifying Public Speaking | Book |
| @patrikkarisch | The Accessibility Machine | Github |
