Dev happiness fika

What defines a good work environment for developers? Is it that sharing and learning are encouraged? Or that there is time for pair programming? Full autonomous teams? Kickoffs and beer brewing? Or maybe ping-pong tables and a barista?

There are millions of possible answers to this.

All tech companies want to build a good work environment for developers to make it an attractive place to work. But it’s a hard task. Some companies send a management team on a field trip to Silicon Valley visiting the big tech giants such as Spotify, Facebook and Google. They seem to do fine so why not just copy them?

That’s a viable approach, but at Telia and the digital channels department, we chose a much simpler strategy:

We ask the developers what they care about.

Because every developer is unique. Telia is a company with big diversity among the employees. There is no single objective truth for what culture we should build, but all devs probably have their answer for what is important for them.

What works at hip Silicon Valley startups might not work at all for a telco in northern Europe.

Let me share our bottom-up approach that works very well for us.

Our process for listening to developers

For around 6 months now we have run "dev happiness fika".

Every Tuesday at 09.00, interested devs and managers in the digital domain department sit down together and have a "fika". A classic Swedish fika is an informal and social chat where you can talk to other people that you don’t talk to day-to-day. However, our “dev happiness fika” chat is not completely unstructured as classical fikas are.

Inspired by the lean community we run the fika as a “lean coffee”. We all know lean people LOVE post-its, so alongside the fika treats they serve as first class citizens during our meeting.

Everyone gets a bunch of post-its and we start writing down topics. Topics can include almost anything. These are some examples that have come up recently: "is it ok to work out in office hours?", "what does this new re-organization mean to us?", "I feel I don't get enough time to develop my skills, what can we do about it?". There is no pressure to write topics. It’s fine to just participate in the discussions around other topics. Then everyone gives a short elevator pitch of their topic to the rest of the group.

Next step is to vote. We do the "dot voting". Everyone gets three dots and puts them on the notes. You can vote on your own topic, there is no shame in that.

Then the topics are sorted after the number of dots in a mini kanban board with TODO, DOING, DONE columns. Start with the one on top.

Now the action starts. The original author of the topic kick-starts the discussion by repeating the elevator pitch. Then we talk for 7 minutes. One person watches the clock. When 7 mins have passed, we vote if we should continue talking, or move on to the next topic. The voting is done with the thumbs, a thumb up means continue talking, thumbs down mean "move on to next topic", and a thumb to the side means "I don't care". We never discuss a topic for more than 7+5 minutes.

This means we never get stuck in one topic but lots of different topics are covered. You almost definitely will talk about something you care about during this hour. Sometimes there is an action point and someone volunteers to follow it up.

Some examples of things that have come out of dev happiness fika:

• Learning Friday. Spend a full day learning whatever you want
• Full-Stack Feast. A bi-monthly internal conference

It’s the dev happiness fika that is the engine that produces all good initiatives for devs in digital domain department.

But the biggest benefit of these meetings is to have a meeting arena for devs in the organization. The action points are not always necessary. Sometimes just talking and releasing the pressure is enough.

A key aspect here is that managers are always present. Not mainly to talk - but to listen to their employees. This is a place where we as employees set the agenda. This would never have worked as great as it does without our awesome managers who actually deeply care about creating an awesome dev environment.

Try it out!

I want to encourage you to try this out in your organization. If you are a developer, you could start small with your own team. Try this structure when running a retro for example. Then you can expand and invite more teams and your managers.

And if you are a manager or a team lead, you should definitely try this out if you want to have another tool to learn how you can improve the work environment for your employees. And also get good ideas how to improve processes.

If you try it out, please let us know how it goes.