Tech Talks at Work

One of the initiatives I sponsor at work which I’m most proud of are our weekly tech talks. The company had a long history of doing them, a small group of people would volunteer to talk about something for about an hour on a Friday afternoon. But the prep was hard work and there was no consistency. We could have talk three months in a row and then nothing for the next six. Worse still the same people always felt pressured into talking which seemed very fair on them.

Back in 2019 I went to the Leeds Test Atelier and attended a talk by Sophie Weston. She discussed what her company had done with tech talks and I was really impressed. She argued that the key requirements for any sustainable tech talks were:

  • Duration should be 20-30 minutes
  • The same time/location every week
  • DO NOT MISS A WEEK
  • Food

Inspired by this I went back to work and set about seeing if we could pull off something similar. Sophie had explained how important it was to keep the schedule going week after week. If you start missing weeks those odd weeks develop into hiatuses and then the entire thing stops. She also strongly advised bacon sandwiches but I didn’t have a budget so we relied on BYOB (Bring your Own Buttie) instead.

Over the next few weeks I set about pitching my idea and recruiting speakers. I wanted twelve. I figured that if I could find twelve people willing to give a talk and get them on a weekly schedule then it would be worth doing and I might stand a chance of the talks becoming a sustainable weekly occurrence. I got fifteen.

The Mic Drops began to take off. Photo by Christina Morillo on Pexels.com

We booked a meeting room and opened up Skype for anyone who wanted to dial in. We also made sure we recorded all the sessions so if someone couldn’t attend they could watch it at a later date.

At the time of writing we’ve had:

  • 60 consecutive mic drops pausing only for holidays
  • Over 20 different speakers
  • 20+ hours of recorded videos
  • 1700+ attendees

Even the global pandemic didn’t slow us down, we simply moved to 100% online!

So here are my steps for starting up your own weekly tech talks:

  1. Plan out your first three months in advance to make sure you have sustainability
  2. Hold your talks at the same time and place every week
  3. Unless for a specific reasons the talk and questions should take less than 30 minutes
  4. Record them
  5. Don’t limit to “Tech Talks” some of our best talks have been on sleep, agile, management practices, books, and communication skills. Encourage variety!
  6. Always have a back up speaker, try to have two
  7. Survey your department to find out what talks people are interested in
  8. Invite External Speakers
  9. Run workshops to coach the less confident speakers
  10. Anyone can talk and anyone can attend!

Have you run tech talks in your company? Did you follow a similar format to us? What worked well for you?

Communities of Practice

Many larger companies are following the lead of companies like Spotify’s to create engineer led communities, sometimes called Guilds. The concept is simple, and very good. Creating a cross team culture of engineering excellence to drive best practice forward among employees sounds like a brilliant idea. In this post I’m going to discuss my experience of working with Communities of Practice and my thoughts on their true value.

Companies usually start a CoP initiative when they want to engineers to take ownership of:

  • Defining Standards and Best Practice
  • Training and developing it’s members
  • Breaking down Silos around teams
  • Hiring and building a better team

It sounds great right?

As with most things the reaslity isn’t quite as straightforward as that.

Teams collaborating and self directing through Communities of Practice is a hard, but powerful concept. Photo by Canva Studio on Pexels.com

As anyone who reads my blog may pick up I enjoy a little amateur psychology, I believe it helps me in my role as a team manager. One of the things I’m acutely aware is the tribe mentality of scrum teams, when people get so focused behind their products they often find it difficult to see other teams as allies – too often they’re seen as impediments to deliveries or competing products. Forming a Community of Practice asks people to shift their focus and split it away from their scrum teams to think as a wider team. It can be hard to sit with two hats on!

So, how do you get started?

There’s a very good book by Emily Webber called Building Successful Communities of Practice which outlines a very good approach. She talks about a Community Maturity Model which outlines various objectives the forming community should aim to hit as they grow. By splitting out into distinct Potential, Forming, Maturing, and Self Sustaining phases. It’s important to realise that giving someone a goal and letting them go is not enough to build a Community of Practice.

With CoPs I’ve helped develop it’s crucial to start with a small group of engaged people who set goals and achieve them. Using these successes and achievements as an example to recruit more members and take on more ambitious goals. You can force dozens of people to join a meeting but you won’t get engagement, you want to be able to hold up what the community has achieved, show it off, advertise it, and ask other people if they would help deliver the next goal.

Communities should set their own goals. They need the ability to ask their members what work is needed and the autonomy to be able to go and make it happen. Otherwise they’re simply a vehicle for management to share project work between teams.

Finally, these formative and fragile communities need real organisational support. They need people to have goals set around forming the community, these people need time (I recommend setting the expectation of a day a week out of regular team duties), they also need a discretionary budget. Breakfast, coffee, prizes, and events go a long way to getting people in the door to hear what you want to achieve and once you’ve got them a social budget is a great way to help those cross team relationships form!

If you’ve been involved in Community of Practices or “Guilds” as they’re sometimes known let me know. What advice would you give to someone who wants to form them in their organisation?

Why (and How) I Started Speaking at Conferences

I did my first public speaking event at DDDNorth in February and then followed it up with a second presentation recently at the Leeds Testing Atelier. In this post I want to discuss why (and how) I went from audience member to speaker.

I’ve always been slightly in awe of people who have the confidence to speak in front of fifty, a hundred, or even more people! A friend of mine started doing technical talks a few years ago and after meeting a few more people who give talks I was rabidly running out of excuses.

I read somewhere that the fear of public speaking comes from our most basic tribe instinct. We’re afraid of making a fool of ourselves, of being ostracised from the tribe, and ultimately being seen as an unworthy partner. Even today, when we strive to create safe teams we’re still afraid of standing up and giving presentations to our colleagues.

So the question becomes what changed to make me want to push through this fear?

I’d been giving internal tech talks at work for several months. We used to do them over Skype, personally I found talking to a microphone much easier than talking to a group.

Something interesting happened when I started speaking about various topics at work. People came to talk to me about them!

I quickly realised that the natural progression of learning was to present. The work you do when you put a presentation together helps you focus your ideas, strip out what isn’t important, and ensure you have your topics clear in your mind. The best way to continue your learning is to allow other people to challenge you. In other words, the only way to become the expert is to act like an expert.

Now, I don’t claim to be an expert. But I like to think that the work I’ve put in pulling these presentations together has helped me learn the topics, but also clarify things in my own mind. There’s always the fear of a question you can’t answer, but there’s never any shame in not knowing something – that’s another opportunity to learn!

That brings us to the How. That part is actually surprisingly easy. There are loads of local tech community groups around, and you can quickly find a list of conferences in your area. Chances are they’re the same ones you’ve been going to for years!

Most of these conferences and groups are run by volunteers and most are crying out for speakers. Get in touch, get a date – nothing focuses the mind like a deadline!

Hopefully that’s encouraged you to go and give speaking ago – remember your audience want your talk to be a good one. Here are my top three(ish) tips to public speaking:

  • Submit the topic you want to talk about, not the one you think your audience wants
  • Don’t put bullet points in your slides, they steal your thunder and effectively makes you, the speaker superfluous
  • Don’t talk about pet projects (in the nicest way no one cares) or give sneak precious into something you’re selling (be generous with your knowledge)

And one for luck

  • Memorise your opening, the hardest bit is the moment just before you start speaking!

The Importance of your Local Development Community

I recently saw a post on LinkedIn, I’m fairly sure it was an advert for in house training but the message rang true. One manager turned to the other and said “If we train our developers they’ll get better and leave!” To which the other manager replied “But worse, if we don’t then they might stay!”

One of the most common reasons I hear from departing team members is boredom, that they want to go somewhere else and learn new things, use new technologies, and learn from other people. I myself have preached to friends on many an occasion that you learn more in your first few months at a new job than all the time afterwards combined.

You want the most eager, hungry, and interested developers on your team. You want to be able to retain them by introducing them to new ideas. It’s also your responsibility to keep your long serving members of staff from stagmenting and falling into a development rut.

The answer is often closer than you may think!

Local groups of developers are not hard to come by. I’m based in Leeds and to my knowledge we have Agile Yorkshire, Leeds Sharp, Leeds Code Dojo, and Leeds DevOps. Groups of people who meet regularly to discuss ideas, listen to speakers who bring new and exciting topics to the table. By visiting these groups I’ve been introduced to AngularJS, Microsoft Cognative Services, F#, .NET Core, and many many more…

By encouraging your developers to attend these events you motivate them to go out and find new ideas and technologies. Far better for them to have a night out, come back full of new knowledge than decide they’re fed up of using the same technologies over and over.

So how can you encourage participation in these events? Why not arrange to go as a group? Encourage someone to speak and bring the team along to support them. Plan a team night meal afterwards or ask someone to bring ideas back to your own internal training. Who knows, you may even bump into your next hire while you’re there!