Lead Dev in London

I’m always excited when I get to go to a tech conference. They’re a nice change of context and medium for the constant task of absorbing new information and keeping track of what’s changing in the field (I program for the web, so “what’s changing” is everything, always). My day-to-day way of doing this is with an infinitely-growing series of browser tabs containing articles & blog posts I might or might not get round to reading. Conferences are a chance to spend some dedicated time listening to people speak eloquently and passionately on their topics, which makes a nice change and often gives new angles of understanding.

What made Lead Dev sound so interesting for me was the content, targeted at people who’ve been ‘promoted’ from developer to lead developer or team lead, and are now charged with solving people problems and strategic problems as much as hands-on technical problems. I’m not myself a lead developer or team lead, but I’ve noticed that what I always find most useful in conference talks is the “how did we make this decision, and what were the consequences?” and “how did our team break apart this problem, and then solve it?” stories. “How to use Hot New Library” and “Meet the hot-shot developer of Amazing Thing” talks are fun, but I’m rarely a user of Amazing Thing or in a position to implement Hot New Library (at least not until it’s aged through the hype cycle a bit). Strategy and problem-solving is always helpful (or, as Pat Kua reminded us on day one: “principles will outlast tools”). A whole tech conference focused on just that stuff sounded fantastic.

I got to attend Lead Dev through their fantastic scholars scheme, which assigned me a conference regular as a mentor to help orient me and answer any questions I had, and gave me a chance to meet the other scholars as a motivated & highly engaged sub-set of the huge conference crowd. My mentor was lovely, and being part of the scholars group was a wonderful ice-breaker and meant I never lacked for people to reflect on the talks with.

A lot of the common themes that echoed between speakers at Lead Dev are things I already believe: empathy and respect are powerful development skills, continuous learning is both essential and challenging, diverse teams are effective teams, and people skills are the hardest and most essential skills of all. Already believing those things in no way reduced the impact of the wisdom that was being shared. I spent two days nodding along, scribbling notes, and in one awkward moment, spilling my tea everywhere because I was so struck by something I heard.

Something I noticed was that a lot of the companies and organisations with substantial vendor presence and/or big groups of employees attending the event are ones that have crossed my radar in the last few years, in a good way. These are places that I’ve noticed sponsoring events and programs for underrepresented people in tech, recruiting through community groups like RailsGirls, and places where I know there is >1 woman in the tech and tech management teams. They’re also places that maintain high-quality technical blogs that I refer to often, and open source projects that I use everyday. Compared to the company presence at other conferences I’ve been to, it felt like a slice of the tech community as I wish it always was- open, community-minded and as diverse as reality is.

Below are my notes for some of the talks- not all of them, but the ones where I made notes about things that I’d really like to remember. These mostly aren’t direct quotes, they’re my own interpretations & take-aways- you can view the slides here, and I’ll link to videos once they’re up, too.

For another perspective & more detailed notes from these talks, check out Sole’s notes for Day 1 and Day 2. Malcolm Young’s notes are also a good read.

(Some of the) Talks: Day 1

The talk that was most timely and valuable for me was Maria Guitierrez’s talk about how to structure personal development. I am someone who usually has two dozen browser tabs open, three simultaneous books I’m reading, and an infinite, totally unmanageable list of things I am trying to learn and document at any one time. I’ve been wanting to get better at this, and have collected an also-unmanageably large list of aspirations for how I will do that. “I should write that up in a blog post” is something I often think when I emerge from a bug-hunting code dive with some new knowledge, and then I immediately get distracted by the next thing.

What I found so valuable about Maria’s talk was that the techniques she gave for narrowing the list from an unmanageable infinity to a manageable handful are things I’m pretty sure I can do. The structure she suggests is a full-day annual goal-setting to generate a list of goals, a shorter weekly reflection against the list, and a 5-minute daily reflection on what was learnt today. Limit the content-hosepipe of blog posts, books and podcasts to things that are on the list. A technique she suggested for generating the list is to go through your role description, and do a self-assessment of your level of skill in each area. Focus your energy where it’s needed. The idea that I could (and actually should) put some sort of a boundary on what I am attempting to learn at any given time is both common-sense and a total revelation.

Earlier on the first day, Adrian Howard described the role of manager as an organisational developer, with the team members being the customers of the organisational product. With a vision of servant leadership (“Be Alfred, not Batman”), he shared some really useful active listening tips: reflecting someone’s own words back at them, for example “Can you tell me more about {thing the person said, in their own words}”, asking for stories rather than bounded and leading questions, and distinguishing in notes between an insight on the part of the listener and an observation from the speaker. His book recommendation (which might go onto a future reading list if I decide that building listening skills is something I should focus on), was “Practical Empathy” by Indi Young.

Anjuan Simmons opened with a delightful insight into a development career as a hero’s journey, in which at some point the hero can take on the role of mentor to a new hero. I really recognise this path for myself right now- I’ve been working as a developer for a while now, and am increasingly looking for opportunities to mentor people at an earlier stage, while still looking for mentorship and guidance from people who’ve gone a few more adventure cycles than me. Anjuan spoke about influence and leadership in the spheres of people, code, customers and scheduling, and shared the profound usefulness of preserving dignity at all costs, especially in situations of conflict.

Release cycles for native mobile apps are a whole different beast than for the web, but Cate Huston’s talk was full of relevant insights for any development sphere. Defining and exploring in-depth what the catastrophic failure would be for any app- if it’s a text app, that’s losing text. If it’s a gaming app, it’s losing points or streaks. Users will never return after a catastrophic failure. All teams need to be able to clearly articulate the company priorities, and multiple teams working on the same product need to have their incentives aligned, or they’ll be driven to undermine each other.

Giving and taking feedback is notoriously hard. Erika Carlson’s talk encouraged us to think about why it’s so hard- what’s the fear in giving/receiving feedback? What’s underneath the fear? What opportunities can be gained by pushing past the fear? Breaking feedback up into the categories affirmative, constructive and passive, she reminded us that feedback is a skill, and skills need to be practised or they won’t develop. There was gem in there about kindness versus niceness- a nice person might avoid giving difficult feedback, but a kind person knows it needs to be done, for the good of everybody. We got some good tips on receiving difficult feedback (say thank you, go away to process it, and reflect and respond once the feelings have subsided a little), and how to give it (be collaborative about how & when is best, be specific, name behaviour rather than personal traits, practise out loud).

Day one ended with drinks, snacks, and bonding with some of the other conference scholars about projects, community, and how our heads were spinning from the number and quality of the talks.

(Some of the) Talks: Day 2

On day two, Birgitta B.’s talk about Agile Documentation was another one that was exactly the right thing for me to hear at exactly the right time. The importance of common understanding versus the constant decay of out-of-date documentation is a very familiar struggle. She gave a few recommendations for what should be documented: things that everybody on the team should understand about the application, things that don’t change very often, things that turn up often in conversation with people outside the team, and things that are complex, hard to change and that need to be explained repeatedly. Documentation can be a way to find and address code smells- describing a complex problem can be a way of exploring that complexity, and identifying if it needs to be addressed. I was really inspired by some of the paper model kits Birgitta shared, as ways of modeling a system while discussing it, and by the strategy she suggested for documenting architecture decisions using ADR-tools. This was a great talk about how to have “just enough” documentation, created and updated when needed (and not before), made of maps, how-to’s, history and creative sketches.

Continuing the theme somewhat, Mathias Meyer talked about working in diverse distributed teams, and pointed out that written communication & decision-making can also function as accidental documentation. It was cool to see some examples of the principles and tools of open software development that the TravisCI team bake into their incident response, decision-making and team-onboarding, like using Github issues for just about everything (including procurement), and running company culture discussions as both open and opt-in- invitation open, participation invited but not manditory.

Sabrina’s talk on big rewrites made some valuable points about when to do it: basically, when the cost of not doing it rises to be equal to or greater than the cost of doing it. Explaining when this is to non-technical stakeholders isn’t always easy, so she suggested making the pain of the bloated please-rewrite-me codebase as visible as possible by explaining the impact on feature development time. Before embarking on any big rewrites, hash out the technical approaches with prototypes, and take Fowler’s “strangler” approach to the rewrite for maximum value and flexibility.

As well as the rewrite, there’s always the option of deleting features and code. To know what to delete, Sabrina suggested defining exactly which features support the core value proposition of the product, and flagging everything else to be considered for deletion. As a way to prioritise time, she suggested identifying the current biggest blocker, removing that, and then repeating for as long as necessary or possible. A suggestion that I have written little hearts around in my notebook is that a team can farewell deleted and deprecated features and projects with obituaries or other ceremonies for closure.

Picking up the earlier discussion of mentorship and learning, Carly Robinson spoke from recent experience about mentoring junior developers, and what makes for effective mentorship. Mentorship is a relationship, so solidarity, empathy and fit are important, and it’s one where the goal is for someone to grow within their craft, so craftmanship is also needed. She gave some great structures for discussing expectations, like outlining what is expected in terms of commitment and progress in three, six and twelve months, and sharing how the parties define success for themselves as mentor or mentee. She suggested tracking progress and explicitly acknowledging progress as a way to counteract imposter syndrome, and pointed out that stretch projects need to have a real risk of failure to count as a stretch.

With Randall Koutnik’s talk we got an interesting perspective on how to describe career progression for a software developer. Rather than years of experience- a metric that only describes someone’s ability to continue to exist- he argued for a career ladder based on the sophistication of a person’s problem skills. The person with the least experience takes a well-described problem with a well-understood solution, and implements it. Someone with a little more experience can break down a big problem into its implementable parts, and someone with a lot of experience can, with deep understanding of business and software context, go and find problems and set the direction of the solution.

Sally Jenkinson gave us an insight into the journey from working as a developer to working as a strategist. This might happen because of a desire for more responsibility, a scope-creep in someone’s role, or their interest in increased reach and impact. It’s a hard move to make: meetings and responsibilities multiply, it can get lonely, and internal and external ‘maker’ snobbery can make moving to a ‘multiplier’ role identity crisis. Still, she argues that it’s a valuable transition to make, as developers can make excellent strategists, translating between business and development teams and having a solid understanding of estimation and problem decomposition. She encourages using developer skills to build prototypes, and working hard on reducing technical jargon in communication with the use of tools like the “Up-goer 5” text editor.

Crystal Huff ran through the importance of inclusion and working against bias in hiring practises, and Jill Wetzler continued this discussion with the importance of retaining and advancing diverse teams. Jill told us that trust as leaders must be earned, and a workplace must be safe to be productive. It’s the job of a leader to develop cultural awareness and cultural competency, and to stay aware of things happening in the world that might impact team members who are different to themselves. If something happens that might impact a team member, she recommends inviting but not forcing conversation about it, and letting the impacted person guide the conversation. Since a lack of constructive feedback can hinder advancement, work on the skill of giving good feedback to someone different to yourself, including practising, and accepting that there might be tears. Using structure to give feedback reduces the likelihood of bias leading to different sorts of feedback for different sorts of people, and she recommends checking feedback both from leadership and peers for bias before delivering it- “Would this feedback be given if this person wasn’t X?”. To counteract the tendency of people to seek proteges and offer sponsorship of people like themselves, actively and intentionally seek out people from underrepresented minorities for advancement opportunities. Work constantly to level up your whole team.

The final talk of the second day and the entire conference was another incredibly timely one for me, since I’ve recently done a couple of talks and found them both rewarding and terrifying. Lara Hogan, author of Demistifying Public Speaking, gave a delightfully meta talk in which she continually referenced her own use of the techniques that she was explaining as she spoke. She recommended keeping yourself engaged as a speaker, and therefor engaging your audience, by delighting yourself throughout your talk with things you genuinely like. Pictures and jokes should delight rather than distract or potentially offend. Her biggest advice was to practise, and to solicit feedback- this is advice that I’ve heard before, but her suggestions on how to do it were interesting. I liked the idea of recording yourself speaking and sharing that for feedback with a small number of people so that it doesn’t have to happen in real time- this both makes it easier to fit into people’s schedules and might help me get over my shyness in asking people to watch me speak.

She suggests giving your feedback team specific guidance on what you want feedback on, and if your talk might involve Q&A, practising answering bad, hostile or ridiculous questions, as well as comfortably saying “I don’t know”. It’s important to practise continuing through a failure or a fumble, and to make back-ups of slides and notes so that you can recover from technical failures. Power poses are a good way to build energy right before getting onstage, and once a talk has been given it should be celebrated and rewarded with some sort of ritual of achievement.

My last note from Lara’s talk is “Buy ‘Demistifying Public Speaking’”, but in fact I was lucky enough to win one of the copies being given away as a conference prize! I got it signed by Lara, and am seriously excited to have a copy on hand as I grit my teeth and put myself forward for more opportunities to teach and talk.

After the last talk I wound up at the pub with some scholars and a few other conference attendees, trying (and failing) to pick highlights from the two days of talks. As I left there were still crowds of scholars, speakers and other conference-goers filling the pavement outside the pub with their greetings and reflections. Two densely packed days of information just barely beginning to settle in.