Last week I had the opportunity to attend the Lead Developer Conference, a two-day, single-track conference with over 400 development leads from the UK, Europe, the US, Australia, and New Zealand. The event included an excellent array of speakers representing development leads at companies including Slack, Atlassian, ThoughtWorks, Amazon Web Services, GitHub, Shopify, Couchbase, and many other organizations.
Overall thoughts
Why didn’t anyone think of creating this conference sooner?
Whether someone is leading a team of engineers for the first time, or has been leading teams for many years, this conference offered many valuable insights. I found myself nodding yes more often than not, relating to many of the stories shared by the speakers. The conference helped validates some of the things we do right, and gave me a number of great ideas for things we can do better within our organization.
The event had a good balance of speakers from a variety of countries, which gave the event a well rounded perspective on managing engineers globally. If anything was missing from the event, it’s that I would have liked some breakout sessions to pick a topic and discuss them in a smaller group.
Day 1
Patrick Kua, ThoughtWorks
After some initial introductions, the first day began with Patrick setting the stage for the entire conference with an overview of the state of being a technical lead.
Patrick talked about transitioning from a developer to a first time tech lead to a seasoned tech lead, and emphasized some of the challenges as your value changes from code quality and feedback into other priorities.
He mentioned that first time tech leads sometimes fall into the trap of thinking they have to make every decision, or even worse rewriting the work of an engineer rather than giving them feedback to improve, which can demoralize their team members. He also noted that a first time tech lead needs to manage people problems rather than avoiding them, trust their team and support them, and help resolve arguments when necessary.
Patrick discussed that the transition to an experienced lead is far less shocking than the first transition from an engineer. He mentioned that the world is no longer binary, and that sometimes it is better to wait and observe before acting, when the right direction is unclear. It’s also important to remember that you do not need to have all of the answers as a tech lead, and its ok to show your vulnerabilities and to be human.
To remind the audience that you do not need to be liked by everyone, he told the fable of the man, boy, and donkey to much laughter. He further reminded us that tech leads are not alone, that people are complex and not interchangeable robots, and then briefly covered his situation leadership model where you switch leadership modes based on the situation.
Patrick encouraged the audience to identify their own approach to leading, which may be some combination of being a good coach, shepherd, shaman, and champion depending on the situation. And he finished by reminding us that we all have the power to say no.
Heidi Waterhouse
Heidi then gave a talk on the seven righteous fights. She started by comparing compound interest and how technical debt can compound if challenges are not solved early in the process.
Her seven righteous fights are localization, security, extensibility, documentation, affordance, acceptance, and accessibility. She had several fun points for each point, in particular covering the idea of a homunculus for affordance, and of course the obvious localization vs. localisation, a very simple example for the US vs. UK.
I thought this talk did a great job of giving some real examples and things to consider as you work through these fights, where these items are often ignored early, leading to big challenges and technical debt later. Be sure to check out Heidi’s story of the talk, which includes further thoughts from her and comments from the audience.
Atlassian
The conference had a few short vendor talks, which are usually the lowlight of a conference. However, in this case, the speaker read a poem he created that compared autonomy vs. visibility, in the context of tech leads and the Atlassian suite of products. It was very inspired and fun. I later spoke with the speaker, and he said he created the poem a few nights prior to the event as he was struggling with how to say something meaningful and fun in just a few short minutes.
Mike Gehard, Pivotal
The next speaker proceeded to talk about the Journey from Monolith to Microservices. The talk itself was interesting, but I felt that it was fairly divergent from the focus of the conference, so I tried to think about the talk from the perspective of a tech lead rather than the specifics of microservices.
Mike shared one of his favorite quotes, from Kent Beck: “Any decent answer to an interesting question begins: it depends”. He also emphasized that when migrating from legacy to something modern, it’s important to start with API level tests, as unit tests will likely become irrelevant, and this will help with the migration. He noted that if you cannot build a decent architecture with a monolithic system, you run the risk of just compounding your problems with a microservices approach. And he mentioned that it’s important to delay technical decisions as long as possible, which ties in nicely which my thoughts on the paradox of choice, which is that everyone wants infinite choice, wants to be able to pick something fast, but wants to be able to easily change their mind later if it turned out to be a bad choice.
Lorna Mitchell, IBM
Lorna gave the first of several lightning talks, with a very quick overview of the Wonderful World of WebHooks. WebHooks are essentially a way for a client (but not really a web browser) to efficiently get notified when a data service has an update, without the overhead of a persistent connection.
Dan North
I was very excited to hear Dan speak, as he’s known to be the father of BDD, as I was curious to see how his thoughts on testing and agile were related to his thoughts on leadership. Dan delivered an excellent talk on How to make a sandwich. Really his talk was on the ways to give feedback in a manner that actually encourages your team.
He talked about different types of feedback (reinforcing, stabilizing, oscillating) in a very captivating manner. He talked about timing and the approach, and how a few subtle word choices can be the difference between effective leadership and having your team be offended.
Dan discussed why feedback matters (to help us improve, remove obstacles, and validate our approaches). He joked that giving feedback should not be about controlling others. Feedback is a system which is offered or sought, and then heard. He emphasized that feedback, both positive and negative, needs to be specific to be useful. For example, talk about a particular situation, specific behavior that is observable and concrete (without using judgmental words, and saying why), and the impact this is having on the team or project. Otherwise the feedback is either shallow or will not improve the situation.
At this point I was wondering when we were going to learn to make a sandwich! He concluded with three models for feedback.
The porpoise approach is to provide feedback only with goodness, which is based on how porpoises are trained. People are often keen to please you, so you will offer specific positive regard, and assume that everything else will self-correct. In Dan’s experience, most things will self-correct.
The sandwich method is to offer specific positive regard (specific, sincere), offer a growing edge (positive or negative), and end with general positive regard (specific, sincere). To work this needs to be genuine or else it will be perceived as just hiding bad news inside of fake praise, and the growing edge needs to be supportive and specific. He finds this is an effective technique when working to build trust with a team.
Once that trust is built, feedback can often evolve into an Atkins approach, without the bread of the sandwich method!
Dan also reminded us that when you receive feedback, a genuine thank you is all you really need to say! I see that Dan’s philosophy for BDD is really the same as his approach for managing a team: understanding how humans think and relate that to solid technology and process.
ThoughtWorks
ThoughtWorks gave a short vendor talk, which told the story of Jean Bartik, an early ENIAC programmer, where developers always worked in pairs. It was an interesting way to explain that some may think of pair programming as a relatively new idea, but its origins date back to the earliest programmers.
Duretti Hirpa, Slack
Duretti mentioned how fortunate she was that her parents blessed her with a unique name, which is great for SEO. She then talked about some of the things they do at Slack to improve their approach and foster excellent working environments with minimal process, or in other words how to get them to eat their vegetables.
Games are one way to foster human connections, by increasing the empathy team members have for the group. We observe this at SitePen, where playing or having fun together (even though we’re completely remote) allows us to form stronger bonds with each other.
She talked a bit about meetings, which was interesting given Slack’s emphasis as a tool to reduce meetings! Her suggestions included making sure that all meetings have agendas, are interruption-free (so each person can speak without being cut off mid-thought), and allowing members to take turns. I think we can all learn from these suggestions, including me. She also mentioned that the chit chat during the first few minutes of a meeting is the most important part, as it allows you to connect with your team and as them as humans. This concept would be repeated by others, and is something we take to heart at SitePen as well.
Katie Fenn
Katie gave a lightning talk on Modular CSS. We’re explored using Modular CSS for Dojo 2, so I was familiar with the topic. It was good to see the idea of having CSS modules with unique class names that are inserted by a CSS framework introduced to this audience.
Yasmina Banaszczuk
Yasmina delivered an engaging talk based on her research on networks, hiring, and retention. She talked about the challenges of competence bias, and gave the very funny example that the name Kevin is apparently not associated with intelligence in Germany, but the name Alexander is.
She also spent a fair amount of time talking about ways to build culture, and that free beer isn’t culture, but techniques for getting teams to relate to each other and grow from their diverse perspectives is.
At SitePen, we try many things here which we think work well. For example, to be less biased during the interview process, we first give the applicant a code activity to complete, and we only conduct an interview after we’ve seen that we like their code. This allows us to reduce bias and snap judgment. In fact we do not conduct our interviews in person to avoid the Malcolm Gladwell style of bias, and we place no emphasis on background traits such as which school someone attended. No organization is perfect, but it was great to hear some affirmation that reducing bias in hiring can lead to solid results.
Joel Chippindale, Future Learn
Joel shared an engaging talk on how your team can tell stories through their commit messages. It was a great analysis of how bad commit messages are not very useful, and good commit messages are a great way to document intent and history of a codebase. Future Learn has a very detailed blog post, telling stories with your git history, so I won’t repeat that here. I will simply say that we have a strong preference for this as well, as we’re big believers in creating code and documentation to express the intent of our code. It’s also something where we think ES6 and TypeScript improves upon JavaScript, meaning that the language makes it easier to express intent, making it easier to maintain your source code tree.
Sam Lambert, GitHub
Sam gave a talk about building new things on top of old, which was a somewhat surprising talk from GitHub as most of us think of them as a relatively new organization. He started with a brief overview of GitHub, which was fine though I think we all know about GitHub!
The talk was primarily focused on GitHub’s approach to their engineering philosophy as a half remote, half in-person organization. He emphasized simplicity, modularity, composability which are concepts we take to heart, and which every organization should.
One of our big messages around our current work is that it is easier to add complexity than it is to remove it, and Sam said the same thing!
He also talked about the GitHub Enterprise challenge, where it originally took 40 minutes to spin up a box. So they rebuilt this approach from scratch, in shell, and now it takes two minutes to build because they chose a lower level, faster technology. This has allowed them to reduce their complexity, and greatly reduced the time needed to add features that appear on their hosted service to their on premises enterprise service.
Nickolas Means, WellMatch Health
The last talk of the day, How to crash an airplane, had to be my favorite of the conference because of Nickolas’ incredible story telling skills. He is a fan of plane crashes, and roped us in with the first 20-25 minutes of his talk being only about the events that transpired in the United Airlines crash near Sioux City in 1987.
Many speakers would keep relating their story to the topic, but he saved that for the very end, which really helped immerse the audience in his story. Through a series of surprising events, the United crew found themselves flying a plane where one engine had failed and the hydraulics system had completely failed. This flight would be the first in modern aviation history where anyone survived a crash where the pilots effectively lost control of the aircraft.
The point of the excellent story was that United had implemented an approach to crew resource management, which switched the industry from a thinking of “whatever the captain says” to a model that included everyone’s input while still leaving the captain in a strong leadership position. No matter how much fail safes or how much redundancy you think you’ve created, things can go seriously wrong. Software development is a team activity and with the right culture we can do amazing things together.
From the audio and video coverage, to the model DC-10 aircraft, Nickolas had the entire audience captivated throughout the talk. It was a great way to end the first day of the conference. I caught up with the speaker during the reception dinner, and confirmed his passion for software development, airplane crashes, but also the time and effort to craft such an engaging talk. Well done Nickolas!
Conclusion
Beyond the points above, the conference had several overreaching themes that I found great for a conference:
- Acceptance and diversity, promoted through the code of conduct, but carried throughout the talks. It was especially important given the UK Brexit vote that was taking place that day!
- Accessibility, with speakers warning if their slides had excessive motion, to closed captioning provided for all talks
Day 1 of the Lead Developer conference provided an excellent opportunity to hear stories and learn about the techniques used by a variety of organizations and teams in managing their development process. Make sure you read part 2 of this post, which will cover day 2 of this event. The conference has also made videos from all Lead Dev sessions available, in case you want to hear the sessions in their entirety!