Innovation as a function of coziness

Bringing in a Culture of Tech Innovation in your Organization

Coziness means the feeling of safety, abundance, and softness. In this article, I will portray the fact that innovation increases the more the feeling of cosiness increases and create a structure by the end by which this can be attempted in an organization.

I have documented this on the basis of experiments I have been running during my work as a manager and this contains my personal thoughts and notes.

Let us look at a dev from the lens of Maslows Hierarchy of Needs -

Innovation can only take place once the lower-level needs in the above diagram are taken care of. You cannot expect developers to participate in their higher-level needs if the items on the lower sections are not taken care of.

At least the levels of physiological needs and safety/security need to be taken care of, as well as a sense of belonging.

Only then can they focus on the higher-level needs which target self-esteem and actualisation.

Creating this base needs a few things in terms of employment -

- They are well taken care of. If you devs are focussed too much on increasing their package and targeting the next promotion, they won’t have the mental bandwidth to participate in innovation

- They feel like they are part of a tribe, where they are working with like-minded, ambitious people from which they can derive their sense of connection with their peers and don’t have to worry about strong negative feedback when they engage in innovation which is typically highly error-prone.

For this reason, creating that sense of belonging and taking care of their personal goals should be of utmost importance to the employer, to make space for innovation.

My hypothesis is - we see senior engineers or engineers higher up in the career chain participating in innovation higher than folks who just joined the industry because of this exact reason.

Folks who have been in the industry for a while have figured out (mostly) the lower three aspects of psychological needs, safety and security and love and belonging and hence can focus solely on self-esteem and self-actualisation needs that they have.

Now let us view this basis of the importance/urgency of grid

Innovation falls into the not-urgent but important bracket for most developers. Because of the nature of innovation, it is typically not needed unless we reach a state where it is needed. This means that unless they are working on a project dedicated towards innovation, they will never prioritise working on innovation unless mandated.

For games, this is handled by removing all forms of extrinsic motivation related to survival. But in the case of a job, moving completely to intrinsic motivation is a bit trickier.

As a tech leader, it makes sense to address this directly, mostly by making space at the beginning of the projects they are working on, to figure out a specific kind of innovation they can do and give them enough time to do it.

It should have enough space to allow for failures, such as the innovation not yielding the expected returns or the cost of implementing it becoming too huge in terms of time or financial cost.

Making this space can lead to continuous innovation in terms of learning or prospects because even if the innovation is not brought in, it can be scheduled in the future when it starts making sense or used as a base for other developers to start working off from.

Storing the learnings from these attempted innovations is progress.

Through my experiments, the learnings I have come across for this are

- You figure out what innovation to bring by making dedicated space at the beginning of an initiative by giving at least a week, to figure out how to bring it in and what all will be needed. If this is figured out, all is well and good. If not, this can be kept in the backlog, to be figured out or taken upon by the same developer / other developer in one of their next upcoming works

- You make space for the innovation to be brought in, near the end when the required urgent - important work is already done off and there is no chance of that getting affected. This creates that space of safety where they can deep dive into the innovation and figure out how it makes sense, deliver on it or if it dosnt’t work, document it for all folks in the team to learn from (including references for themselves in the future)

- The primary deliverable of an initiative shouldn’t make pre-emptive changes for the innovative work that will get delivered since it may fail and pre-emptive changes will add more extra work for cleanup and may lead to unnecessary entropy.

To be cleaner in terms of motivation, we should look at this from the view of the octalysis framework which is often used for gamification.

Gamification has received a bad name in the Indian Tech Industry because it is almost always tied to extrinsic motivation in terms of higher compensation, and faster promotions when the person involved in the gamified process has to "push" continuously to make sure they are where those needs are being taken care of properly. This leads to overwork, and burnout and directly touches the lower-level aspects of Maslow’s hierarchy of needs because their base needs always rise to whatever they are gaining out of the gamified process. This leads to a loss of motivation down the line when, for whatever reason, they are not able to meet the bar of the gamified needs. We often see this happening for the huge swatch of people who participate in the quick commerce sector in India.

Intrinsic motivation has to be derived from the aspects of personal and team empowerment, social influence and even the high-low difference of unpredictability which is brought in by bringing in the innovation.

This is based on viewing the process through the lens of the octalysis framework which is popularised by Yu-Kai Chou.

Employers who focus on giving the space for innovation have often been rewarded with disproportionate results in terms of overall efficiency (due to internal problems being targeted often via this new tooling that gets created) and creative product features that get built. This produces high dividends at a much lower cost compared to having a group of people targeting innovation, where the innovation gets linked to external motivation because they have to deliver something since it is connected to their performance.

Innovation should be a function of self-realization which means the managers of the people who are giving them this space, should also allow them this space to do discovery of the innovative methods by themselves. The "Space before and after" model helps in this since it helps reduce reactance because the manager is directing the dev to do something, which links it to their extrinsic motivation and increases fear of failure.

A way to approach this would be to -

- Ask the developer to figure out 2-3 experiments that can be performed after the initiative is done in a span of a week or two. Things which they can read up from different company engineering blogs, whitepapers etc. Give them space for this, no "do this while you fix these 3 bugs".

- Once the project is delivered and rollout is happening, let them try out these experiments before a new initiative starts. Let them choose which one they want to try out.

- If it works out and the quality of the deliverable makes sense release it.

- If it works but the quality is not good enough, make space for dedicated work on it in the next few weeks/months based on what is feasible. Ask them to document their learnings in a blog / internal document

- If it doesn’t work, ask them to document it in a blog / internal document. Other folks in the team who read this may find inspiration and use it as a base on the problem statements they are working on

This article was inspired by -

https://www.projecthorseshoe.com/reports/featured/ph17r3.htm

https://yukaichou.com/gamification-examples/octalysis-complete-gamification-framework/