Tim Schraepen's Blog Yet another developer blog.

The Lead Developer Conference - Day 2

05 Jul 2016 • 24 min. read • Read the comments Tagged Experience Report

The Lead Developer - continued

The Lead Developer conference, or at least the one I went to, was held on the 23rd and 24th of June 2016, in the Queen Elizabeth II Centre in London, during the Brexit vote.

This is a post about all of the talks of Day 2, and I’m sorry that this one is considerably longer than Day 1. I don’t know what happened. :)

Day 2 

Michael Lopp - Leadership by the numbers 

So Michael Lopp, @rands, is a guy with a HUGE amount of knowledge. I’m very glad he was so generous to share with us.

He guided his talk somewhat weird and I didn’t fully understand what the stuff he was saying had to do with Leadership by the numbers, but the content was great.

He started off by testing the skills of the people that were captioning the entire conference by saying out loud Ok I gotta test this real quick… Supercalifragilisticexpialidocious. After the word appeared after 1-2 seconds, the crowd went wild. :)

These guys really did do an amazing job. I found myself checking to see what was said when some of the presenters went a bit fast for me to keep up with my notes. So thanks again guys!

Team Communications

I would be jealous to be in his team, because @Rands takes 30 minutes every week, no matter what, to have a 1 on 1 meeting with every member of his team. Just to check in, and have a feeling of what’s actually going on that week with his team. In contrast to the Performance Evaluation timeslots everyone dreads because it feels so forced.

He also has staff starting points, little 1 hour meetings to set the tone for the week. If you can’t easily fill an hour, something is wrong.

He then started talking about the long term costs of not saying the hard thing at the right time.

The obvious cost is that when you don’t say something, work isn’t getting done, team morale is taking a hit (and more importantly the toxicity spreads), and your sanity takes a hit as well.

The less obvious cost is that your credibility as a leader is taking a hit, and that there’s impact on folks you do not know. Their sanity is taking a hit. Michael has learned that everyone is replaceable.. I learned that when you work for Michael, Rands, or whatever his name is, and he shows you a slide of corn, you’re about to get fired.

Diversity, delegation and leading by example

Again, Diversity made an appearance on stage. This time in the form of the Asch Conformity Experiments, where the experiment shows that you can easily get influenced by other people. Again, be aware of the bias that you probably hire people like you and that wanting a diverse team is a no brainer. And also that as leaders, we should be a diversity allies.

This phrase fired a bunch of neurons in my brain You set tone and cadence… all the time. Just like kids who watch you do stuff and repeat your actions you do subconsciously. He gave an example of his own daughter using redirection to a new game she saw at games convention E3, when she saw him enter her room all ready to lecture her. He realized that she learned that from him.

As an easy change, you could simply start and finish meetings on time, and show you respect peoples time. This can set the tone for the whole company to do the same.

Watch his complete talk to find out what you might be horrifically bad at, and how you might direct yourself to a path of learning how to become better at it.

Also delegate when you’re in a stressy situations (e.g. the site is down). You know how to do it so let someone else do it and learn. Another great quote:

Delegation is a great way to grow a team.

Be unfailingly kind

He finished with a bit that hit home for me.

He talked about how he plays the videogame Destiny, an online shooter where you need to finish missions with a (random P_ick _U_p) _G_roup. Since there’s a huge variation of skilled people online, you’re lucky if everyone knows what to do and knows their role. And a lot of frustration and toxicity can originate from these situations.

But he plays this game with a friend who is Unfailingly Kind. It doesn’t matter how toxic other players are, or how little they know about the game. This friend has a lot of patience.

This was such a recognizable situation to me, and I strongly believe in being this Unfailingly Kind guy. But it’s really difficult to always be like this. I’ve got MAD respect for Michaels friend. And I’ll do my best to help people out in the friendliest way possible again.

Great keynote to start off Day 2 if you ask me. The tone was set again.

Slides / Notes

Ryan Alexander - Hacking verbal communication systems 

Ryan (@RNAlexander) Alexander took us on a deep dive into conversation.

I learned that a group conversation or brainstorming session is like a race. Where everyone that’s trying to talk next is at a starting line, holding their positions, waiting for the starter flare to go off (the one talking to stop talking).

But that there might be people in the conversation that follow the rules, waiting in their position. And that there are others that don’t, leaving the rest behind, before the starter flare was even fired.

This is sort of a semi-conscious, complex algorithm going on in every participants head. And exactly because it’s an algorithm, we can hack it.

I never thought about discussions or conversations like this, but it makes SO much sense.

Then I learned about the Occupy Together hand signals. Where you can announce your intent, without interrupting, to the participants in the conversation. Click the image for a clarifying explanation, or watch Ryans talk.

Seems like this would work WAY better than a simple “speech token”.

To facilitate everyone getting their chance to speak/communicate, the hand signals are more friendly to neurodiverse individuals. Moreover you can decide who’s next to talk on the basis of whether or not they have spoken, this is called Progressive Stack.

Great little talk with a boat load of information. Definitely worth your time!

Slides / Notes

Yan Cui - Tour of language landscape 

I’m sorry I didn’t write down all that much in my notes about the stuff that Yan Cui (@theburningmonk) taught us. But it’s because as I was sitting in the audience, it soon became apparent that this talk was gonna be a ridiculously interesting one and it would deserve my full attention.

Here’s the stuff I’m able to recollect though.

After a short introduction on the impact of language on the way we think, he showcased some really excellent examples of how features in certain programming languages can make your code more expressive. He took a bunch of features of F#, Clojure, Rust and Idris and explained how they could make your code less error prone and more expressive at the same time.

If you’re in to DDD’s Ubiquitous Language, there’s no doubt that you should watch this talk. Even if you have 0 experience with the languages Yan mentions.

He closes off his talk by encouraging everyone that didn’t know the programming languages he mentioned. He did this through debunking Malcolm Gladwell’s “10,000 hours to master something” rule, with Josh Kaufmans correction that says you can already be “good” at something after the first 20 hours.

Really, interesting talk, hitting all the stuff I love. Would highly recommend.

If you’re not into watching a presentation, read. his. blog! This guy is a library of himself!

Yan Cui, if you’re reading this: Thank you!

Slides / Notes

Crystal Huff - Dealing with Impostor syndrome 

Crystal (@crystalhmhuff) replaced another presenter at the last minute, and her presentation was very interesting nonetheless.

Impostor Syndrome is not a disease, unlike the term suggests, but rather a state in which you think you feel underqualified but when in reality you’re really not.

It can have real consequences such as being less effective as collaborators (because nobody wants to be seen making a mistake), getting fewer promotions (because an impostor feels unworthy), etc. In the end the negative impact comes down to being marginalized and being silenced.

It gets fed by sentiments like Fake it until you make it, when if successful, you actually will have been an imposter. Other things that feed into it are phrases like Women are bad at math. Even worse is when you give in to those stereotypes where you say for example Math is hard, let’s go shopping.

Other important, notable things that might trigger it are comparing your worst snapshot to someone elses best snapshot, and the Being Liked vs. Being Competetent dichotomy.

There are ways of combatting it though. And as usual it involves gaining more awareness. For example by asking your colleagues or friends about your strengths. Or by realizing your heroes struggle with this as well, and picturing the iceberg (illusion) of success.

Just the tip

Preventing Impostor Syndrome involves watching out for certain things that you say e.g. I’m not an expert, but…. If you repeat that phrase often enough, you’ll eventually believe it.

Compare yourself with yourself. Compare your past self (on your own personal scale of where you want to be in life), to your current and future self. Instead of comparing snapshots of your worst self to snapshots of somebody elses best self. This made a lot of sense, but it’s something you just need to hear more.

Crystal also inspired us to help each other prevent it by critiquing with kindness. Compliments are better when they’re personal. A good compliment is positive, not physical, specific, and honest. See Dan North’s “How to make a sandwich” presentation about feedback. When you notice someone else struggling with impostor syndrome, help them remind themselves of their happy thoughts and experiences.

I did reach out via the company Slack channel for someone to tell me 3 awesome things about me and here’s what I got.

You speak your mind, even to people you don’t know that well. You’re not scared (you don’t show it at least) to try out new things. When you’re enthusiastic about something, you shine your ray of enthusiasm onto other people. (you pull them along)

So thanks for helping me combat Impostor Syndrome!

Slides / Notes

Gil Zellner - How to not burn out your monitoring team 

We switched to a more ‘techie’ track with Gil Zellner (@heathenaspargus) giving tips on how not to burn out your monitoring (operations) team.

But before he did, he reminded us that the cost of hiring a new employee is 1.5 to 3 times their salary. So you might wanna retain those guys at ops by helping them as much as you can.

Caution

Do NOT watch this presentation or the slides if you haven’t seen Game of Thrones episode 9 of season 6 yet, there’s a massive spoiler in his slides. :)

Easy changes you can do to help (takes days to implement):

  • Mandatory half day off after night production issue.
  • Allocate weekly time to resolve or automate issues that kept us up at night.
  • Wider rotation (more people on call).
  • Follow the sun (if you have multiple timezones).

Medium changes you can do (things that might take months to implement)

  • ALERT ALL THE THINGS leads to alert fatigue.
  • So only alert on symptoms, not suspected “causes”
  • Only alert on actionable stuff
  • Only alert on business breaking stuff.
  • Direct alerts to relevant parties.
  • LOG ALL THE THINGS can tremendously help the team that gets woken out of their beds at night, but can lead to overwhelming stuff, especially if you also log success.
  • Connect detection scripts to correction scripts.
  • See Facebook Auto Remediation.

For the hard things (that might take years) he mentioned some AWS stuff I didn’t pick up on, but maybe you will so check out his slides (if you have seen Game of Thrones!).

Slides / Notes

Monika Piotrowicz - Lessons from growing a team 

Monika Piotrowicz (@monsika) talked about her experience of growing into a leader of dev leads.

A lead will have some combination of tech knowledge and skills, understanding of the business and product, and trust from their team. All so they can help develop their team.

And you can’t build a version of someone in only one day that has all those qualities. So what you want to do is encourage those traits in your entire team and see who picks ‘em up.

You can do this first of all by simply asking who’s up for becoming a lead (in the future), then talk about what it involves, and create opportunities for those candidates.

To help your colleagues and yourself grow, fill in the blanks

Most impactful thing I can do today is …

Right now I’m not great at …

In a few months I want to try …

Remember to Make Space for your candidates to grow. I trust you to do the right thing - here’s a list of things you should do is not how you make space. :)

This was all pretty great advice, but this one I felt like sharing with our current coach.

Every time you think you’re protecting your team by going to a meeting yourself, delegate to the team instead.

Slides / Notes

Thomas Lobinger - Working backwards from the customer 

Thomas Lobinger (@tlobinger) works at Amazon and talked about their (literally) backwards approach of aligning a team on values and creating a shared vision.

What I mean by backwards is that they’ll start with the end goal and work backwards from there.

So what they do is first they create a mock Press Release that shows, among regular stuff like title and summary, a quote of the customer and the team.

This helps them in not only creating a shared vision and understanding, but also a shared motivation. It’s what we usually try to do with a Mission statement of a project team. But I think it goes much further than that, because you’re imagining what impact your end result will have on the users or your clients.

After they’ve written this, they’ll create a FAQ document from the perspective of customers and stakeholders.

During the creation of the Press Release the team will have come up with a bunch of questions that you might be able to include in the FAQ as well. I think I can compare this to trying to figure out non-functional requirements during an RFP.

Then they’ll create Mockups of what their product/solution will look like. It should tell the story of how a user would use the product they’re going to build.

I’ve noticed that, much like Simon Brown’s (@simonbrown) C4 Diagrams, with this approach they’re effectively zooming in to their product, but from a less technical perspective. Every level of detail seems to put more focus on the users perspective. You know… the one we’re actually making this thing for.

Of course Thomas doesn’t just write these documents once and then be done with them. They iterate over them, so when they come across questions or more insight that should go in their Press Release, they put that stuff in there and update the rest accordingly.

So really what they’ve done is come up with a sort of Living Documentation that is able to continuously provide a Shared Understanding and Shared Values on a team.

If you’re looking for more information about this, it seems Werner Vogels (@werner) already wrote a blog post about this exact method back in 2006. Or simply watch his talk.

I do believe that it’ll work better for products you’re making yourself and innovations, rather than projects you do for clients, because there are no feedback loops from clients. But it’s easy to imagine asking the questions or verifying the assumptions that will come up when creating these documents.

Maybe it’s a great additional method to working on RFP’s or starting teams around a new project.

Slides / Notes

Penny Wyatt - Overhead, not downtrodden 

Atlassian’s Penny Wyatt (@pennozewyatt) gave us a bunch of tips when working in Quality Assurance.

  • Embrace you’re in an overhead team.
  • Broaden your view, work towards the company and customers goals.
  • Cost is not value.
  • Leaders are overhead too, so focus on where you can add value.

She told an anecdote where she spent 3 extra months testing stuff because the devs didn’t catch a lot of edge cases. At first she felt great because since it took her that long to thoroughly test the application and improve the quality of it. She felt like her role got validated because of this. Of course those 3 months were not perceived as extra value, but as extra cost.

There were better solutions to build in quality in to that team, like working more closely together with them. And focusing on installing quicker feedback loops.

They moved closer towards this goal by putting more accountability on the Quality Assurance team, so they wouldn’t just be accountable for quality, but also for development speed.

This caused them to work in close cooperation with the development team. And eventually get renamed from the Quality Assurance team to Quality Assistance team. Moreover because they were helping the dev teams become more accountable and more interested in quality.

Even though this caused her to do less Q&A, it produced more value in the end. She made the comparison to how management can also be considered overhead.

Instead of trying to get better quality by adding more developers, they can be able to get more value AND better quality from a smaller team, by letting the team improve their performance.

Slides / Notes

Melinda Seckington - How to succeed at hiring without really trying 

Melinda Seckington (@mseckington) made a compelling analogy of choosing between a closed box that had the label strawberries on it, or a transparent box where you could actually see the strawberries along with a label containing nutritional value etc. to choosing a company you want to work for.

Then she explained how at FutureLearn they’re making the transparent box, by focusing internally on helping colleagues write and speak, authentically.

The idea is that by doing this, you turn developers in evangelists for their teams (and by extension for your company).

The amount of support devs at FutureLearn get for this goal is staggering, and FutureLearn’s culture absolutely embodies this knowledge sharing and evangelism mindset.

To me personally this was eye opening. Because I’ll notice one of my colleagues has accomplished a great feat, and I’ll ask them to blog about it, but they never actually do. Usually they’ll come up with stuff like I’m not an expert, or I can’t write, I’m too nervous, I’m not a good speaker, Nothing I do is worth speaking about, …

From now on, I’m going to try and change my approach, by offering to help them write or prepare for a presentation. Try to help them take away their fears and blockers.

In any case, Melinda’s talk is a presentation you should show to your HR colleagues and/or your guild leads.

Slides / Notes

Laura Czajkowski - How to deal with the cultural divide and internal advocacy within distributed teams 

Laura Czajkowski (@czajkowski) works from home, for Couchbase. She was so kind to share her experience doing this and some pro-tips to help deal with the typical problems.

If you ever did some remoting yourself, you’ll recognize a lot of her descriptions. Most notably missing social talk and work discussions because of the absence of a watercooler (or coffee room), and lag (delay) issues with VOIP tools.

Watch her presentation for some pro tips on dealing with these situations.

If I ever work remotely again I’ll be sure to try out her tip on bringing your morning beverage to the friday mornings stand-up, and talk a bit about your weekend plans. This helps in getting to know your remote colleagues a bit more.

Slides / Notes

Camille Fournier - Rebooting Culture 

To close off this years The Lead Developer Conference, Camille Fournier (@skamille) talked about her own experience of bringing a Culture of Fear to the team she managed the first time she became a leader, noticing this and how she changed it around.

This was my first time experiencing Camille, and I don’t know if it’s because of her background as a developer, but all the things she pointed out, is very near to my heart. And she was talking about these things with such a passion… Validation feels great! So thanks Camille! :)

Speed

First she talked about Speed.

She reminded us that engineers like to ship, and be a part of something that matters.

Making sure your team can work as fast as they can is one of the most important things you can do. So remove resource constraints (e.g. code freezes), and be impatient with things that seem to take too long.

Structure

Then she explained how good Structure helps you get context quickly, and that Structure comes from failure. Failure in structure usually leads to getting rid of that structure, which isn’t always an appropriate response.

This reminded me of a story someone at our LeanCoffee shared about a team that had visible bottlenecks in their scrumboard, and decided to stop doing scrum.

Ambiguity is a bias factor, or how vagueness in job or role descriptions can be interpreted in a way that suits you. What you want instead is transparancy. She showed this really quick example of an excel sheet with DnD traits being used as measuring points. Take a look at this once her slides are up.

Here’s another nod to HR and people tasked with doing performance reviews. If you keep changing the interpretations of vague roles

Structure is not how to detail instructions on how to do it. If you find yourself doing this, ask yourself if you can’t automate that instead.

Relatedness

Vulnerability is the opposite of a culture of fear.

If I remember correctly I think she meant that when there’s room for feelings of vulnerability, i.e. there’s a safe environment to experiment and fail, both emotionally and technically, it empowers people.

Like how Kerth’s Prime Directive makes for great retrospectives.

Related to Vulnerability, you need to have Healthy Conflict.

Tina Turner wants violent conflict to resolve issues

Not because you’re Tina Turner in Mad Max Beyond Thunderdome, but because it draws out important data.

What I’ve noticed is when conflict is avoided all the time (as is common in Belgium), nothing can be learned, and it can lead to passive aggressive behavior.

Here’s another tip for leaders. Telling people You can’t criticize if you can’t come up with solutions yourself is a bad thing.

Instead, ask them to really articulate their criticism. It’s more effective to replace feelings of conflict with curiousity.

She also shared this fun definition of meetings:

A meeting consists of a group of people who have little to say - until after the meeting.

Empathy

Because Camille felt like we hadn’t been given enough gems, she closed off her talk by telling us that Empathy is a learnable skill.

This is such an important statement actually. Much like how Responsibility is generally considered a trait, so is Empathy. But they’re both not.

How is it learnable though? Camille told us it’s as simple as asking about how somebody is doing, and really listen. Even if you don’t really care all that much, just do it. In time, you will care about Peter hurting his knee.

In hindsight, her talk was the culmination of what I expected from this conference, and at the same time it was a summary of what all the presenters before her had been saying.

What I’m trying to say is, watch her presentation now!

Slides / Notes

In conclusion 

Writing these blog posts have been great to recollect the abundance of shared knowledge and I’m glad I did, even though it took me quite some time. Hope you readers were also able get some use out of these posts.

I’m so glad Jan Sabbe recommended this conference to me last year. It really was an inspiring two days, full of new knowledge to share.

Thanks again to everyone involved! Hope to see you next year!

Related Posts