I like to tinker. It’s part of how I got started in this business… as a 10th grader I remember eagerly awaiting each edition of the electronics hobby magazine I subscribed to, and often buying and assembling projects from kits or components. (There was also the time I ruined my mother’s electric frypan – but that’s another story…) Recently I’ve been tinkering with a Raspberry Pi 3, Windows IoT Core, and various Node.js frameworks. My direct goal is to build a “Jenkins build status” dashboard, using a strip of addressable LEDs to display the status of important automated build and test jobs. But my larger goal is to become familiar with technologies and frameworks that are new to me and may be useful someday.
Google, of course, is famous for encouraging engineers to tinker. Google’s “20% time” is apparently responsible for many of its ground-breaking innovations – even if the cynical moniker “120% time” (20% time on top of the regular workweek) has a lot of truth to it. 3M is also famous for innovations spurred by time allocated to tinkering – one account I read attributed the ubiquitous Post-It Note to one such project. Agile coach Rachel Davies recommends a “gold card” that teams can play every so often to work on something of their own choice. The common themes are clear… Time allocated to a project of one’s own choosing plays into the inner drive aspect of autonomy that Dan Pink describes in the book Drive; and engineer-driven experimentation can produce value both incremental and revolutionary.
I’ve been thinking about the role of tinkering when it comes to engineering projects. I’ve observed that many engineers I have worked with have a multitude of ideas of how this or that could work better, or “what if we tried…” speculations. As with all innovations, we’d expect some to pan out and some to not be successful. But one observation I have made is the consequences of not allocating “time to tinker”… I’ve seen individuals on project teams with maybe-great ideas that – if successful – might create something significant, revolutionize the product being worked on… or at least increment the team’s ability to be successful over time. I’ve seen teams live with this tool or that tool that is frustrating on a day-to-day basis. I’ve seen teams in a position of not being able to incorporate fresh approaches into a product because no-one on the team has taken the time to develop the expertise or perform the “could this work?” experiments. I’ve seen project teams that are reluctant to try this or try that because there is a focus on getting the defined work done. Not that there’s a problem with focusing on the defined work – on a day-to-day basis, producing the product or delivering the service is what pays the bills. But I wonder how an organization might transition to realizing the value of “time to tinker”…
With that context, here are my starter thoughts on what enabling “time to tinker” might look like for an organization…
- Limits and discipline: getting the defined work done still needs to happen, and to have an allocation of “time to tinker” can’t prevent the core work from getting done
- Transparency: knowing what each other is working on allows people with a common interest to collaborate
- Clarity of ownership: it can’t be ambiguous who owns the IP from a company-sponsored activity
- What about service projects? In cases where we a client is being billed for a project, clarity of ownership – and also value – is extremely important. On one client-facing project I experienced, the client’s product owner actually encouraged the time-and-materials contract engineering team to allocate time each sprint for tinkering!
- Support for experiments: for example, using a code branch to try something out, so that experiments don’t get accidentally incorporated into production code
What else? Do your engineering teams have time to tinker? What might happen if they did?