I attended The Lead Developer conference last week.
I took a lot of notes, which was quite a pleasant surprise. The organisers recorded the talks, and they’ll be up in the next weeks but here are my notes for day 1 in the meantime (or in case you don’t even know what to watch first when the talks are finally published!). Update: the slides from the talks are listed in their blog.
Also please note these notes are essentially taken for me, not for you. So if something doesn’t make sense, I’m sorry, but there’s not much I will do 😛
Patrick Kua – the constant life of a tech lead
Constants → expectations → patterns ⇒ strategies
How do you do this?
Tech will change. You can’t predict what’ll happen. But principles outlast tools. Example: Parnas’s paper on modularisation and information hiding. Refactoring by Martin Fowler–they are “old” resources yet still current.
Learn something you can use in a different context or using a different tool.
People are unique. How do they learn? Strengths finder is a good resource to get started. The idea is to use your strengths rather than focusing on improving your weaknesses. And people can complement each other.
Concept: Hofstede’s cultural dimensions theory. Different perspectives between nations.
Apply perspectives. Use the strengths of each member. From diversity comes strength… if you allow it (let each one come as they are to the job).
But don’t box people. Archetypes !== stereotypes.
Lead: move from maker (lines of code you can write) to multiplier (how many things your team can do).
- Give them power ups
- Give them useful feedback
- Appreciate their uniqueness
- Avoid bottlenecks (you?)
Time – there’s never enough.
Concept: the Eisenhower matrix.
It’s too easy to get caught up reacting.
Concept: double loop learning.
A single loop feeds back from Result into Action.
A double loop forces you to continuously evaluate the mental model, to make sure you understood the problem, by feeding back from Result to Action and Mental Model.
Concept: get a coach, have them challenge your ideas.
Dominika Rogala – things you wish you shared with your team before they agreed on that deadline
How much time do you actually have?
- A year is less than 250 days.
- A month is less than 20 days.
- A week is less than 5 days.
Estimations will fail.
Trap: “I’ll do it in the meantime”. “Meantime”: where the focus is stored.
Trap: things you can’t predict. The research trap. Context switching. Outsourcing. There are many traps!
Concept: priorities !== deadlines. Each member of the team has a priority they use, what is on people’s minds? It’s essential to agree and share on the top priority.
How to set deadlines effectively? Make sure team members know about:
Adrian Howard – How to talk to earthlings?
New manager: no one told them what to do. And maybe haven’t even had a good manager either.
Managing !== telling people what to do.
Now your customers === your reports. You build the organisation, not the product.
An stereotype: that engineers suck at people.
Idea: learn from psychotherapy and ethnography. They have many techniques you can use to manage people.
How to do effective 1-1s? Their aim is to understand people’s goals. UX call these “research”.
- Active listening (i.e. shut up). We’re badly socialised into poor listening. People talk in paragraphs and we tend to want to fill the silence after the paragraph but NO! Stay quiet! If there are no gaps, people will keep talking. Count to 10 (internally) to let them keep talking.
- Hear what was said (don’t misinterpret). E.g. if you don’t know “blah”, ask: “Can you tell me more about blah?”.
- Pay attention.
- Dive deeper, actually understand.
- Ask for more info.
- Also use to redirect conversations if going astray-bring them back to the problematic areas.
- Mistake: Asking about the future. Answers are usually wrong.
- It’s better to ask for stories. “What happens on the worst days?” “What was the worst/best day last week?”
- Mistake: leading questions. They lead you… to build the product no one wants. And they are even worse if you’re in a manager role: the explicit power relationship makes them sound like something akin to “direction”, and people think this is what you want them to do.
- Ask open questions. “What do you think would help with ABC?” rather than “Do you think this team should use ABC?”
- Mistake: being disrespectful. If people don’t see the rest of your day, they can’t understand you looking “bored”.
- Be polite.
- Don’t look pissed off.
- Don’t be scary.
- Pay attention to first encounters and your body language (“am I being read as annoyed”?)
- Mistake: trusting your memory.
- Write notes.
- What you want to discuss
- What you discussed
- Separate insights (what you deduct) from observations (what was said) to understand root causes
- Write notes.
The stereotypical leadership built about power doesn’t really work.
Instead: “stalk” before you talk, sell or build.
Don’t try to be Batman. Be Alfred.
- Robert Greenleaf – Servant leadership.
- Indi young – Practical empathy.
- Stevel Portigal – Interviewing users.
Katherine Wu – Ask vs Guess cultures
Ask vs Guess concept first appeared on an Ask metafilter question.
The “guess” people avoid asking unless the answer will be yes (“offer culture”). But if you’re offered something, is accepting that exerting pressure on others?
We have the responsibility of making messaging well received by others. Understand the other side.
Concept: the Seattle NO. “No”, but not obvious to everyone.
- prioritise efficiency
- no ambiguity
- gets what you want (in the short term)
- open conflict
- make people uncomfortable
- prioritises not hurting feelings
- more polite
- hard if bad at reading social cues
- can feel like no one is listening
Guess people don’t normally ask so if they do, it’s a big thing and it’s a good idea to pay attention.
With remote work you lose body language so you can miss cues.
How is your team culture? Is it “ask” or “guess”?
If you’re from “ask”, make a “guess” friend, and ask them questions: which nuance can you see here?
- it’s not what “guess” say, but what they don’t say
- listen closely
- apologise if you realise there’s more than 1 interpretation
If you’re from “guess”
- Remember that people might be unaware of “the rules” (the “guess” rules, the assumptions)
- Resist the urge to soften your “no”es
Check in with people even if you don’t need something right now. Improve the relationship. Also check that they are on the same page. Don’t second guess.
A way to ask “guess” people: “I have a question…”
- “… but it’s OK to say no”
- “… but it’s OK if you are busy”
- “… but I understand that you’re busy”
Talk about communication styles.
- For example, if someone has trouble speaking up and they tell you, find how you can help them (for example explicitly seeking their feedback in a meeting).
- Decide how much time should someone be stuck before asking for help
If someone starts a question with “I’m not sure I understand…”, it’s another way of saying “can anyone help me?”
Just because no one has objected does it mean all is OK. Silence !== OK necessarily.
Maria Gutiérrez – Time to focus on your goals
There’s lots of info available to us – it’s almost like a curse!? And we have FOMO.
You own your personal development. It belongs to you. It should be portable.
A manager should help, but not map your future.
A day to work in your plan. Yearly theme.
Self assessment: where are we? where do we want to be? Areas needing work. Look at a similar work profile in other companies. Choose a few areas to improve—possibly a mixture of tech, business, etc. Set priorities.
Pay attention to timebound learning opportunities — things you can do now that will teach you something valuable, and won’t be available in the future.
How do you get from A to B?
Learning activities. Make learning part of your day.
Timebox social media.
Nurture a diverse network, use it to find recommendations.
On Sundays, look at your progress and plan for the week. Every night, reflect on your progress.
Rob Allen – 5 features of a good API
or how do you know if it’s fit for purpose?
- Good error handling
- Good documentation
- Good security
Concept: an API is an app itself.
Decouple representation from data. Move faster.
Concept: Hypermedia in APIs.
Put links to things in responses. If things are explorable the APIs are easy to learn. E.g.
Concept: Documentation shows me that team cares.
Can I find the documentation?
RFC 6906. Profile link on responses.
- tutorials: help your integrators
- reference: if it’s extremely tedious to write, I hate you if you don’t
As an API person, the best thing you can do is learn cURL.
Documentation is a key driver of word of mouth communications.
Anjuan simmons – leadership lessons from the Agile manifesto
Reading: 21 irrefutable laws of leadership.
“Leadering” = Influence.
So you go from “code smells” to “influence smells”. Can you find effect of your influence in others?
Agile concept: people and interactions over processes and tools —the latter do not build software.
Motivate: preserve dignity at all costs. Better than toys or perks. You can disagree but still maintain dignity.
Even a tool like slack can affect your company’s culture (jokes that are not shared by all culturally, putting them off).
Agile concept: software over excessive documentation. But not all documentation.
Agile concept: working over perfect. Don’t fear surprises. Fear inflexibility. Bake time in for improving things.
Cate Houston – YOLO releases considered harmful. Running an effective mobile engineering team.
With the App Store, your continuous delivery is a NOPE.
Suggested solution: Short and rigid release cycle.
- Short = don’t make people wait.
- Rigid = don’t patch things in, they make releases slower.
Short and rigid creates a regular velocity. Predictability. Be realist, say no.
What is your UX catastrophe?
Bad onboarding = users don’t come back.
Say no enough that the top priority is clear or advancing.
- user success with a given action
- volume of support required with a give action
Remote colleagues: need to be friendly, but not necessarily friends.
Best way for teams to fight? Give them conflicting incentives.
Invest in things that make everyone more productive.
Automate processes which can be done inconsistently or are better done by machines. E.g. style guides: so we never have to discuss this again. Save time for reviews.
Accountability: people have expectations from each other. But they have also agreed to be accountable to something.
With teams, the output is the team, not your work.
Being transparent as to what you are working on (as manager) is good.
A stand up forces the team to start the day with some intention.
Encourage a non judgmental space. A culture of blame is toxic.
Think medium term. Short is too short. Long is too unpredictable. We might not get there.
Erika Carlsson – Fearless feedback for software teams
Feedback is a response to behaviour or performance to increase awareness and shape behaviour.
- Affirmative = reinforce
- Constructive = reshape or deter
- Passive = devalue/condone through inaction (“not important” “quite ok”)
Why giving feedback?
- To improve performance
- Fix problems before they become toxic
- Improve communications and trust
Concept: mosquito problems. Something that happens 14 times a day eventually turns into a monster!
Feedback is hard, and not practised enough (neither giving or receiving feedback). The lack of practice creates fear, but you can fight fear by practicing!
Concept: “this is not a problem, it’s an opportunity!”
Fear = opportunity of growth
This is not who we are, we can change
- what am I afraid of? Have I done enough?
- what’s the underlying fear?
- what are the steps to overcome this fear?
- what do I get by moving beyond that?
Feedback should be: specific, thoughtful, direct
- impact (outcome)
Example: “in yesterday’s meeting when you interrupted I felt frustrated and hurt”
Example: “on this call when you provided this info it made the team successful”
- Listen actively. Confirm understanding (re-paraphrase)
- Say thank you. Be positive (“thanks”) and constructive (accept without getting defensive). Do not fight back. Confirm the understanding. Say if you might need time to think about it. Acknowledge. Acknowledge!
- Respond (later). Take time to assess emotions. Complete: “I feel __________ about this feedback”. Sit with the feedback until you feel less emotional. Hours, days… Decide if or how to act. (It’s good to think/process before giving feedback too).
- Assume the best. Positive intent. The person is sharing feedback because they want you to grow. Feedback is a gift!
- Be specific. Focus on behaviour. Don’t give too much feedback at once.
- Let it land. Effective critical feedback needs to be direct and unmitigated. It can be uncomfortable. Don’t soften it.
- Be collaborative. Ask before providing unsolicited constructive feedback: “do you want to listen to feedback? When? How?”. Confirm understanding. Follow up.
- Avoid antipatterns.
- Don’t attack people’s character.
- There should not be retribution for feedback.
- And not constructive feedback in public, unless there has been public disruption-you want to make the team aware that feedback has been given and the behaviour was not OK. You don’t want the team to get passive feedback.
- Avoid anonymous opinion. It can destroy trust (although it can be good when there’s a power imbalance)
Lead by example – good feedback culture starts with leadership.
- Regular feedback practice:
- Structured activities.
- Mutual 1:1.
- Peer feedback exercises: say nice things to each other.
- Team retrospectives.
- Organise feedback training for the team
Practice: with team mates, friends, mentors, peers, colleagues…
Challenges: tell someone something great they did. Ask someone something I do well and something I can do better.
Nickolas Means – the original Skunk works
(This was more on the story-like keynote side of things, and so I mostly listened to the absorbing narrative on how planes to take aerial photography etc were built and designed by a small team that cut corners on what didn’t matter in order to build what actually mattered).
Spend time and money on the things that matter.
We don’t have the need for planes this fast anymore (satellite photography etc). Needs will change over time.
Take old parts to build new prototypes.
Stealth plane was unstable in x, y, and z!
Reading: Kelly’s 14 rules and practices
Give the team context, so they can take good decisions. Sometimes they won’t. Build a culture of no judgment.
Want more? Here’s the notes for day 2.