Learning through Exploration Days
As an engineering manager in a software technology company, I strive to extend the knowledge of the teams. After all, the best ideas come from the people doing the actual work — the more they know, the better ideas they can come up with.
So what do we do? We initiate and encourage hackathons, learning tasks, and research spikes.
Usually we provide 48 hours for people to work on initiatives and demonstrate them. We encourage people to get out of their long-lived teams and form new teams for that event. Meeting new people and getting higher diversity of ideas is always good for innovation.
Although we aim for a real demo at the end of those hackathons, the learning experience is something we care even more. The learning we look for is not just on the technology side, but also about getting experience with idea gathering, getting experience with presenting your ideas to stakeholders, and the experience of working with people outside of your team.
The way we launch those events is by self-selection technique. We gather everyone on our site and we let them self-form into teams. We facilitate such an event and it takes 90 minutes for all teams to form. Read this article I wrote about how to let team self-select themselves around new products . We facilitate the hackathon events in a similar way, but instead of defining products, we define initial vogue use-cases that teams gather around (they can change the use cases later on, but it provides an initial focus). The energy is high in such events. Although we don’t mandate participation, 99% of the people do participate.
We learn a lot in those events — both about technology and about people. For technology, it is obvious — we explore new technology areas and experiment with them. For people, this is the part I like the most, as we encourage people to step out of their comfort zone — we see people leading discussions in big forums, stepping up on the big stage and presenting their ideas to stakeholders, collaborating with people they barely know. We come stronger out of those events, both on the technology side and on the personal side. Not all of the teams manage to get to a proper demo, but as I wrote before, the learning journey is what matters here.
We encourage engineers to extend their knowledge to other technology domains — becoming a T-shape engineer. As we know people are busy with the day to day tasking, we provide people the proper space to learn. Learning tasks that are being integrated into the teams plan is common. In order to be practical, we try to have the learning task just before the team needs to deal with a technology domain, so the theory can be turned into value while it is fresh in mind.
We acknowledge the fact that great designs emerge as we learn more iteration by iteration. We don’t fix the designs up front, but rather allow variations and we have research-spike tasks that allow teams to choose the best options at the latest responsible moment.
To sum it up, we encourage learning and scheduling time for this is essential to our organization’s success. For more information on this, please refer to Management 3.0 Exploration Days.