I’ve read lots of press lately around ‘the new startup revolution: do a startup on a shoestring’. I love it, I’ve done it, and it’s what ‘Starting a Tech Business‘ is about.
But I think the real ‘revolution’ will happen when individuals who have been scared off tinkering start doing so in a new wave of hands-on creativity. This raises a few questions that I’ll answer in this post:
- What’s the working definition of tinkering?
- Where’s this supposed ‘revolution’ coming from? What’s driving it and who cares?
- How do you know when you’re doing it? Not doing it but should be?
- What practical things can you do to foster tinkering?
What’s the working definition of tinkering?
Tinkering is what Eli Whitney did- he invented the cotton gin without a degree in engineering. It’s what Steve Wozniak and Steve Jobs at Apple Computer. The tinkerer is highly attuned to the world around them and isn’t afraid to try creating or mending things.
Where’s this supposed ‘revolution’ coming from? What’s driving it and who cares?
Before ‘high tech’ became an industry on to itself, everyone was a tinkerer. Once the industry around computing and software grew to a certain scale (around the late 60’s, early 70’s) it became highly professionalized and ‘technical’ topics were left to ‘professionals’. What’s changed is that with modern computing infrastructure the barriers to tinkering have lowered while the improvements in distribution of technology products have raised the rewards. Building an iPhone app is a good example: purpose-built toolkits and abstractions make doing an app easier while the ready-made marketplace allows the individual to access millions of users.
Starting a technology-enabled business is easier and more rewarding than ever- got it. But what about more everyday stuff? If you consider a startup to be a venture where a team has to work to a goal in an environment of uncertainty, then every company is full of micro-startup’s contributing to its objectives.
Most meetings I’ve been in for the last ten years could have done with less talking and more doing. I’ll bet if you’re reading this post you’ve probably had a similar experience. Even the smallest amount of tinkering, mocking up a prototype or documenting a structured investigation of users, can make a big difference. It determines whether you have something to talk about in a meeting or whether you’re just speculating. I’ve been in meetings going over prototypes and customer investigations that were locomotives of productivity and many more meetings without them that were thieves of time where nothing of importance was accomplished. Assuming you’re still bought in, this brings us to the next question.
How do you know when you’re tinkering? Not tinkering but should be?
While there’s no exact litmus test for tinkering, you can usually recognize it when you see it. Blogger Andrew Chen recently posted ‘Growth Hacker is the new VP Marketing‘. The basic proposition is that because of the importance of promotion online and the relatively ‘technical’ nature of that promotion, the best new marketers are increasingly engineers. I would say the same could/should be true for existing marketers that learn how to tinker.
Consider as another example the project manager that, instead of going between ‘the businesspeople’ and ‘the engineers’ instead mocks up a prototype in Balsamiq. They ask the businesspeople ‘Is this what you meant?’ and the engineers ‘What do you think of building it like this?’. Personally, I think that going out and learning about customers in a structured way and then producing developer-ready outputs (like agile user stories) is a legitimate form of tinkering.
You’re probably missing an opportunity to tinker if:
- There’s a lot of back and forth between departments on what to build or how to use a piece of technology.
- You’re spending time in arguments about what the user really wants.
- Products and projects are being delivered and it’s not what the recipient expected.
- You’re transitioning between learning and design to development and you’re not already tinkering.
For this last one, consider that an iterative technology development cycle has four main activities that operate in a learning loop: learning, designing, developing, and delivering:
While this is a distinct cycle, you are always overlapping in these processes and each quadrant represents the intersection of the three adjacent actives. Transitioning between learning and design to development is where you’d be at the beginning of an agile development cycle. At this juncture tinkering is particularly important. You’re in the early phases of developing something and what you get after all that work is extremely sensitive and dependent upon how well you package your learning into your design and how well that design informs the development process.
What practical things can you do to foster tinkering?
Pretty much regardless of your particular role (senior or junior; technical or non-technical) the single best thing you can do is to be the kind of tinkerer you want to see in your organization (to paraphrase Ghandi). If you want to see design documents that are organized around agile user stories, do one yourself. If you want people to start developing prototypes, spend the weekend making one. Does your example have to be outstanding? No. I think the most important thing is just doing it.
The second best thing you can do is to deflect, repurpose and generally discourage negative feedback. Few things will have a more chilling effect on tinkering, particularly if it’s new to your culture (even just the culture within your part of the organization). This doesn’t mean you have to tell people their work is great if it’s off target. It means that you should focus on the positive parts and the next steps.
The third best thing is to cultivate mentors that can teach and facilitate tinkering. If you’re in a non-technical part of the organization, try to sell someone in the technical part on helping your team learn how to be better tinkerers so they can supply higher quality inputs to the technical team. Make sure the technical folks have a finite achievable goal- rather than teaching non-engineers to code, find something more soluble like mock-up’s or user stories. Pick small thing and build on their success.
Thoughts? Please share them.
