Feb 09 2016
Newton's first law of motion states:
"An object at rest stays at rest and an object in motion stays in motion with the same speed and in the same direction unless acted upon by an unbalanced force."
In other words, objects tend to keep on doing what they’re doing...
Last Friday my CEO asked me to write a blog post.
“Write down all the problems you solve in a week — big and small — and you’ll know what to write about,” he replied, and promptly walked away.
So what are the problems I solve? My coding days are well behind me; I don’t design user experience; I don’t manage projects day to day. Turns out my primary purpose is that of the “unbalanced force” — helping companies who may be stagnating, hurt by inertia.
The relative inability of larger organizations to “innovate” is well documented and/or debated. There are countless “How To” resources to study, such as “Ten Great Books on Innovation” and “Ideas for Brainstorming”.
But, in my experience, the desire for change, or a lack of ideas, have never been the constraints to innovation with larger companies. In fact, the commitment to “innovate” in an established business often manifests itself, most unfortunately, as only a commitment to study how to innovate, to propose, to document, to model. Creating a system ripe for “analysis paralysis”.
This false commitment often produces:
Months, quarters, and years pass by, along with real HR, management, and opportunity cost. Often the desire exists, the domain expertise almost always exists, but the process and path forward do not match.
A few common side effects include:
So how do you apply an “unbalanced force” to create change?
“Don’t wait, the time will never be just right!” Napoleon Hill
Today’s tech stack, tools, and talent make it much easier to do something than ever before. Out in the world, beyond your corporate walls it is happening organically — open-source projects, Meetups, bootstrapping, code intensives, hackathons, experimenting. All of these things happen because those driven to innovate, learn, and grow, make time to be around like minds and make something.
At MojoTech we encourage this behavior with “MojoTime” — giving everyone the freedom to ideate, explore, try, learn, teach, gather and do anything that interests them. This “free period” might seem at first glance to be an opportunity to “waste” time, but a funny thing happens instead. People apply this time with and without their peers to solving problems big and small; making things that make their work more productive; learning new tools, languages, and frameworks; designing a new UI for their favorite app, and even writing blog posts on things they are passionate about!
Over the past three years at MojoTech, I have spent a great deal of my time helping companies large and small, new and old, understand that innovation is a byproduct of culture, not a task to be assigned. Give your brightest, most enthusiastic, most knowledgeable people the space to explore and, believe me, they will. Again, a lack of ideas will not be the constraint!
Risk aversion, however, can be a paralyzing constraint. Risk is real, risk is ever-present. For clients that have a stated desire/need to innovate, we try and frame risk as a steward of progress, not a limiter.
“Don’t worry about disrupting your business, 100 startups are already working on that.”
“The risk of doing nothing is always higher.”
“The more software we write before users try it, the greater the risk we are building the wrong thing.”
Once risk is understood to be a good thing, an immutable thing, you can get down to focusing on opportunity. And starting…
The “arc” of our engagements with established companies is a common one - not much different from that of a graduate student. The client will use us to help them first learn the skill, then do the skill, then teach the skill - and that of course leads to mastery of the skill.
Some examples include:
A structured exercise whereby a Client Product Owner (sometimes a marketer, sometimes a technologist, sometimes a customer advocate) brings a product/service/feature concept to the table and we will come out the other side with a development plan/prototype/demo/alpha. Armed with this process, they often perform that function for future concepts internally and then come back to us for some help in execution. Even better, they then start to evangelize this process in different groups in their company (Hint: it works for non-technical challenges too!).
So often, many great product/development resources are “held back” by maintaining legacy systems. The modern tech stack is moving quickly, but smart people can adapt and thrive and often the quickest way is to combine learning and doing. Paired with a MojoTech team, the client team gets hands on - and hands on in the context of a real development effort versus learning in a vacuum or just in theory. There are thousands of really strong engineers latent inside established companies, schooled and skilled in software development, but simply a generation behind in terms of modern languages, frameworks, databases and systems. This is a massive opportunity for established businesses - as we have seen time and time again in industries like healthcare, financial services, and electronics manufacturing. An amazing thing happens when a small group moves to the modern tech stack - others line up to learn, hiring becomes easier, the snowball grows.
This is one of my favorites… a controlled twist on the Hackathon concept. Two teams are formed to flesh out the same idea. This is a powerful way to encourage self-managing teams, avoid staleness and focus on delivering. This can be design exercise, a rapid prototyping effort or even a working product. It is less about the task, the scope, or the “winner”, but more about exploring, learning and doing.
So to return to the physics metaphor from the start:
“Objects tend to keep on doing what they’re doing…”
So it makes sense to make sure we are always doing the most important thing, that we have our best people working on those things, and always remembering that if we are not, someone else surely is.