Or, How Shifting Developer’s Mindsets Leads To Happier Developers
“We need to be MORE creative, MORE innovative…. Give me more innovation!”
Most organizations try to commoditize innovation. They do this by creating a dedicated innovation lab or an innovation team. The team’s goal is to drive the future growth of new technology within the organization. Often, this is the only way that true future technology can be developed. Dedicated resources in a controlled environment may get the best results sometimes. But, does that provide for general innovation amongst the entire platform?
The biggest problem with the innovation lab approach is the size of your team. Not everyone gets to work on the innovation team. This means that people start to feel left out. Like if they are not picked for that team that there’s something wrong with them.
“Why do I not get to work on the Innovation team? Am I not innovative? Am I not creative enough. Am Ijust supposed to build what someone else designs?”
This can affect the engineers to a point where they don’t want to work on the ideas coming from the innovation team. They may even start to resent the innovation work.
First, you need to understand what you are trying to do.
Are you trying to create a brand new idea, brand new product, or brand new platform? If so, the Innovation team or lab may be your best approach.
But, are you trying to drive innovation within the platforms or applications that you already have? If you’re trying to drive innovation across your entire platform then there’s a better way.
How do you run your development teams today?
For most of us, the agile process is mundane. It’s an endless loop of:
- Feature requests
- Understanding the stories meaning
- Getting to the root issue
- Estimating story points
- Creatively solving a single feature
In that cycle, we may encourage our team members and developers to think creatively about the solutions that they come up with. But is that still limiting in its own way?
We are allowing our developers to solve a very specific feature request in a creative manner. But, are we allowing them to go beyond those bounds and become innovators in the platform itself?
The solution lies in how we think. We want to become enablers of our development teams giving them the ability and the permission to be innovative in their day-to-day job.
We didn’t build a new team or building. We simply allowed everyone to be empowered, gave them the “OK” to think differently. We then supported their efforts by listening and creating a process to roll the ideas back into the product.
Funny enough it starts with a simple question, what would a software owner do?
Asking this question shifts the thought process of the developers. It moves from “how will I solve this problem” to “what would I do if I was in charge and I owned this platform”?
Software owners are concerned with far more than just implementing a feature in a creative way.
Software owners have to think about how that feature compares with other products they are selling against. They have to see if that feature really benefits the platform and be willing to push back on those that don’t. They need to be able to take that feature and look beyond the ask to see what other enabling features would make that a first-class product.
What are the results of this way of thinking?
Developers will start to “look past the ask”. Every feature request takes on a new context. Developers may have good reason to request to scale back the request. Through research, they may determine that the feature was not used in other platforms.
On the other hand, the developers may feel like the feature request does not go far enough. After research, they may feel that adding or expanding the request would greatly increase the functionality of the platform. This expanded functionality is now coming from the core development teams, from those that know the platforms best.
This new freedom can turn into a whirlwind of creative and innovative ideas. But, you need a process to keep track of it all. The process does not need to be complicated, in fact, if it is it will fail.
Process Example
- Breakdown the feature request
- Compare the feature to the “open market”
- Backlog any changes or updates to the original feature.
- In a backlog review, discuss and features brought by this process first.
What about the “open market” comparison? What if you don’t have a direct competitor? Is this worthless?
You may need to break down the feature. For instance, say you are working on payment functionality. You might not be creating a Stripe.com but can you compare what you are doing against Paypal, Stripe, and Amazon? By taking a small amount of time to not reinvent the wheel you will get a better product.
Companies feel that innovation can only come from a dedicated team or a lab with a dedicated budget. But innovation can be a mindset that’s driven by every member of every team. This requires that managers and developers both have a forum for these ideas. A place to raise these concepts and be able to change how things get developed.
Encourage people to think as if they own the software platform that they’re working on. Put them in the mindset that their profit and loss were based upon the ideas that they put into it. Help them measure how competitive they are to the market. It will start to drive innovation from the lower tiers up to the higher tiers.
This solution does not need more money, a dedicated budget or, a special team environment. All you do is give your engineers the freedom to raise ideas and a process to be able to handle them. Your process needs to have the ability to rank them and roll them into your dedicated sprint schedules.
You are creating ownership and dedication in the teams. You create an environment for your teams that shows that you care about their ideas and that they are valuable members of the team.
