Technical leadership - act of leading a group of people in a technical context
Shift from Maker to Multiplier
- Technical Leader
- Individual Contributor
4 types of technical leader
- knowledge cultivator
- the advocate
- the connector
- reputation score
- experience, knowledge, likeable
- the story teller
- No Parachute
- Your old job doesn't exists! (You cant go back anymore!)
- Writing well (and quickly) is an incredible asset
- always write down talking points
- organise thoughts and ensure intent is clear
- unorganised thoughts and talks in front of people -> lose credibility
- Stories are very powerful
- Pitching your team to candidates
- Pitching your team's work to execs
- Have a communications plan for everything
- Don't YOLO the comms
- Know your audience
- down / sideways / up
- Just ask what is on top of the others mind
- "Too many meetings" is often a symptom of misalignment
- Create structure and process around thing you do often
- it's okay for the rest to be messy (things happen once in a year 🙈)
- Always ask: "who is the decision maker?"
- who will be held accountable for the decision
- Credit always flows to the most senior/tenured/visible person naturally
- making sure credit flows to less visible person who really need it
- Leaders build organizations that mirror their personal strengths and weaknesses
- because people who emulate the leaders will get promoted more easily
- what is your biggest weakness and how do you compensate it in your hierachy?
- how do you ensure hiring people that are like yourself?
- how do you ensure diversity?
- Treat people fairly and with respect. It's a tremendous privilege to be thier leader.
- what to do if you are a glue
- have the career conversation
- what do you need to do to get promoted?
- Get a useful title
- Tell the story
- "Due to your work, ... happens"
- Giving up and do exactly the thing on the job ladder
- "That's not my problem"
"Our skills are not fixed in place, we can learn to do a lot of things"
- "Why did we decide to do it this way?"
- Record the why
- Do it along with the code
- status: proposed, accepted, superceded (?), deprecated (?)
- bias, tensions
- Why write ADRs
- Open decision making to all
- Write Decision Records
- Form Short-Term Special Interest Groups (SIG)
- Long Running Special Interest Groups
- Socializing Decisions
- Newsletter of ADRs
- report from each SIG on the work they have done
- discussion on short-term SIG and should they continue or not
- review and discuss open ADRs
- voting to adopt, or
- send back for more discussion
- Open discussion
- implicit commitment to maintain
- maintained by SIG
- simplest possible thing that executes all the components in the path, to show how each of them connects.
Ask questions. Ask questions drives you to understand people
Play back and verify.
"What does ___ mean to you?"
"On a scale from 1 to 10, what do you feel about ___? How can I help you from
"Even over" - "we will focus on even over "
eg: "fixing old bugs even over shipping new featuers", "quick iteration even over polished ui"
- socialise and get feedbacks in the early stage
- "How would you react if I said we should ...."
- "What would worry you if we decided to ..."
Write things down and share it as widely as possible