Deploying an internal engineering conference
Internal DevOpsDays, Engineering Conference, Tech Summit. There are many names, but in all cases, it’s an effective tool for bringing an engineering organization together to generate shared vision, shared mental models, and to sustain momentum on a transformation. Even with a high functioning engineering team, these are opportunities to encourage the team to continue pushing the envelope.
When?
When transforming an organization, the best time to deploy the conference is after the team has already gained some momentum. This is the opportunity to step on the gas. Deploy the conference too early and the teams will have many questions but no way to find their way to a solution. Deploy too late, and… there is no deploy too late, other than to miss out on the time where more momentum could have been achieved.
How?
I’ve run these types of events at multiple companies, from startups to large enterprises like Salesforce and in between. In most cases, we’ve loosely patterned these on DevOpsDay events.
They can be run in-person (preferred if you can afford it) or virtually. If your company has a good hybrid working culture, that can be an option as well.
Day 1
Morning
The idea in the morning of the first day is to get everyone on the same page. The event should kick off with an executive introducing the event so that everyone understands the event to move the engineering forward in a leap is sanctioned and supported. This may be a leap, but it’s still evolution, not revolution.
The introduction can be followed by the keynote and plenary sessions. The important thing is to keep everyone together for the first half of the day. The aim is to get everyone thinking about the same things, in their own ways.
Afternoon
After a break for lunch (as communal as possible, even if that means Zoom breakout rooms), are the Open Spaces. A number of time slots are allocated for discussions. People propose topics in which they are interested and are assigned a discussion room (in whatever form). If there are too many topics, people can vote and the most popular topics will win. The goal is to foster good discussion so don’t let the groups get too small or large (depending on the size of your organization and the meeting space available).
Closing
It’s great to close with a fun activity like Ignite Karaoke (with alcohol depending on your culture/rules), where there are random slides you put together that auto-advance every 15 seconds for at least 5 minutes and people can take turns presenting slides they see for the first time when the slide appears on the screen. Hilarity ensues. If in person, dinner in small groups is a great option.
Day 2
Day two can either be more of the same like Day 1, or I like to run Hack events (or a mix of the two). If running a hack event, it gives the opportunity for the engineers to build on the discussions they had the day before. Because they know the hack event is coming, they will be thinking of ideas during the discussion.
Rules for hack events:
-
No product backlog work
-
Org leaders should never be on teams, they will unconsciously influence the hacks
-
There is no requirement to produce something (learning is valuable), but you can’t win if you don’t present something
-
It’s fun to come up with wacky categories (Most creative, most likely to be replaced by ChatGPT, etc) and let people vote for their favorites.
Outcomes
I’ve seen amazing things produced at hack events. I’ve heard amazing discussions at summits that have set the course for months of excellent engineering work. The conference itself is an investment without guarantees, but somehow, great (even if subtle) outcomes are guaranteed. You just need to set the stage for them to happen.