Demo Culture at Golioth
The engineering community has undergone a remote transformation in the last two years. With such a radical change in corporate culture comes a number of challenges that an office culture never had to face. Is scrum still relevant in fully remote companies? Are standups needed? What is the process to onboard new hires into the engineering culture? How do we invent better remote-first approaches, rather than trying to (dysfunctionally) emulate an office experience in a remote environment?
A well implemented “demo culture” can help companies establish healthy habits for sharing, soliciting constructive comments without specifically asking for them, being a source of inspiration, and facilitating cross-team collaboration while preventing “silo-building” within the company. As we continue to build The Company of Golioth, we are also building The Culture of Golioth. This article will walk through some of the already implemented pieces.
How Demo Culture works
Demo culture also informally translates “lunch conversations” you might have had in an in-office setup into a more efficient, asynchronous remote equivalent. You no longer need to find a place to sit at the right table: anyone can be part of any conversation.
On a day-to-day basis, we use two tools to achieve our goals:
- Loom – A video sharing service to quickly record demos
- A “#demos” slack channel to capture conversations around the topic
An engineer might have a new feature on the Golioth back end that they have been developing, but it only exists on their local branch and local build. They decide to set up a small example application that tests the feature and helps to showcase that it is part of an upcoming release.
These manifest as 2-3 minute videos showing a very small part of development, possibly a subtask of an overall story in our development. Because they act as markers throughout a sprint, we also reference these during sprint reviews. This is especially helpful if there is work that wasn’t planned, carries across multiple sprints, or is an idea for an upcoming feature. Sometimes…the demos are just for fun or to showcase something the engineer is learning.
Benefits
You might be asking, “Why are you so informal about it? If demos and showcasing work are critical to The Company of Golioth, why not make it a formalized task that engineers need to do every day/week/sprint/month?”
The informality is one of the best parts, and also why it’s a part of The Culture of Golioth. We want team members to share ideas they’re having and to make it part of their process as they explore new things. Most of all, we want people to be excited about the things they’re working on.
On a broader basis, the entire company benefits. First and foremost is early access to new ideas. An engineer who shares what they are thinking about on a regular basis helps to start conversations that come up during formalized conversations (sprint planning). Since we are a fully remote company, video meetings are a necessity to transfer information, but also a hindrance to getting other work done (as in any company). Demos pollinate interesting ideas without the formality (and synchronous demands) of group video chats.
Another benefit is that demos always includes a hands-on approach, and not just a passing comment about “how something could be better”. This means that an engineer that doesn’t like the placement of a button could take the initiative to actually move it on their local machine and then showcase it, all without interrupting the flow of other engineers. They simply show the difference, state their case, and move on. There’s a lot of power in “show, don’t tell” to help foster understanding of the points being proposed.
When there are ideas that bubble up as a possible change to direction, either on a smaller development scale or even at a company level, we can start to discuss around this particular video showcase of the proposed change or demonstration. Because it’s informal, it’s just part of the “lunch conversation” mentioned earlier. Hashing out an idea that has come up in-person at lunch is much easier, unfortunately; you can immediately talk through what might be good or bad about a new approach. With Demo Culture, a video showcases the idea and the Slack channel acts as an anchor around which we can discuss. That feedback might also spin off future demos from the original submitter or from others. And they make it easier to come back to those conversations weeks or months later (more on that in just a bit).
Finally, in an ever growing company, we need more ways to interact with each other, as simple video chats will get harder to do. Watching someone on video is no replacement for sitting next to them at lunch, but can help to get to know someone’s personality and recognize their areas of interest. As teams grow, the tendency is for teams to silo as it becomes harder for everyone to keep track of more people. Seeing new, friendly faces showcasing something they’re interested in not only allows people in other teams to see what’s being worked on, but also might inspire new collaborations with other teams. Cross pollination is possibly the most beneficial output of Demo Culture.
Challenges
Trying to change company culture is always tough, even if you’re building it from the ground up. And we are! We are still a small team, so this is the right time to putting ideas and practices in place. But a corollary to that is the challenge as a company grows and shifts. When we bring on new employees, we will need to lead by example and work to maintain the culture over time.
As much as we can encourage employees to demonstrate what they’re working on, each employee is different. Some might want to only show completely finished work, whereas others might be comfortable showing an early demo of something. You need to plan for an uneven distribution, especially as new employees lean into the culture. At the top level, putting requirements on top of something like demos could negatively impact how they are perceived. And while we showed above that sharing demos should be very “low overhead”, it’s still important that employees feel like they have the time to think through and contribute something to the discourse.
Finally, the work itself can be another challenge. Someone working on a long term project might feel that there’s only something to contribute at the end. We still try to encourage them to share waypoints along their journey. It helps others in the organization understand what they’re working on, allows people to get excited about upcoming features, and solicits soft feedback from future stakeholders. In all cases, it’s important that we encourage our teammates to share whatever they feel comfortable and hopefully enjoy doing it.
Demo of a Demo
We must walk the walk! Let’s look at how this works in practice.
In our last blog post, we showed how to set credentials of devices over goliothctl and using the Zephyr shell. This was the result of lots of great work from our backend team over the past few weeks. Throughout the process, they shared progress and showed how it would work using different tools.
First our lead engineer Alvaro showed a demo of the provisioning from a shell on our test Arduino SDK:
Then Miguel showed how to set up credentials using goliothctl:
Then there was another demo where Alvaro showed how he was using goliothctl
Mike from the DevRel team showed how he was using this to provision devices for a training event, using similar methods that weren’t yet available to the public:
Finally this all culminated in a released feature that is now available to all users and that we shared publicly on the blog:
Demo Culture is an evolving concept
We are continuously codifying and experimenting with the concept of Demo Culture at Golioth. As we continue to build out this idea, we will share with the broader community. If you know of other companies doing similar things, we would love to hear about it on our community Discord or on social media. We will share some of the companies we took inspiration from below.
Reference material
The concept of “Demo culture” is not new as an overall topic. We have borrowed and modified from a range of different sources–most notably GitLab–to help bolster our initial concept of how it will work. What’s more, we continue to refine this process:
