Principles, Not Directives

To inspire innovation requires giving teams freedom to explore

Mar 10, 2022

While it is supposed to be a weekly publication, some weeks are just too busy to sit down and write. That was the case with my week in Singapore. First, it was just a week, so three days are already lost in a haze of jetlag. Then because it is just a week, I am packing in the meetings.

I would show you my calendar for that week, but it would be a sea of blue blocks one after the other. I normally advise people not to do this and to purposefully schedule in think time during the week. In this instance though, I felt I had to make up for two years lost to COVID and not connecting with my network in Singapore. The consequence of such a rushed agenda was sore feet and crashing in my bed before 10 pm every night.

I am not complaining though. I felt fortunate to even have a week available to spend time with so many awesome people in the Singapore tech community. Some were old friends and some were new faces. I sat down with founders, IT leaders, investors, and influencers. The incredible diversity of people, backgrounds, and ideas made for an informative and inspiring week.

I tend to find my most rewarding and enriching meetings happen over meals. There is a phrase called “breaking bread” which describes fostering a meaningful connection over a meal, an act as old as humanity itself. Thus it was Saturday morning, the last day of my stay in Singapore, that I had a moment of epiphany breaking bread over a classic Singaporean breakfast of kaya toast and soft cooked eggs with a friend and IT executive.

My friend has had quite a long and successful career as a Chief Information Security Officer and IT leader. He has helped transform the security and technology posture for a firm range of firms across many varied industries. If there is one thread that has weaved it way through every single one of his experiences, it would be the question of culture.

In his relatively new role, the challenges are multifold. A significant percentage of the apps and underlying infrastructure are built on older technologies. Many of the key systems are built as a monolithic, highly coupled codebase. The languages, tools, and frameworks used cover the spectrum of technology fads and trends. On top of this, there is little in the way of strategy other than a vague notion of moving to the cloud while the culture is wedded to the past.

Culture can be a bitch. Neither of us used that exact word, but in the context of transforming an engineering team used to legacy development, changing the culture to adopt new ways of thinking feels like an impossible task. You can tell people what to do, you can force change upon them, but it is a whole other thing to get them to listen and do what you ask. Top-down mandates may work in the military or autocratic governments, not so much anywhere else.

When we were young kids, one of our favorite words would be no. Any parent reading this knows what I mean. The word held so much power in our simple, developing minds because it would result in the big humans doing the craziest things in response. As adults, we learn to stifle our verbal no, but relish the power of our internal no, especially when it comes to change. We are creatures of habit, ruled by our subconscious lizard brain that views anything different as a threat to avoid.

This is why transformation and innovation are so hard to support. Change equals danger and several of our cognitive biases are predicated on that very nature. It does not even have to be rational, such as a threat to one’s employment status, loss of access to power, or change in one’s level of autonomy. We sometimes avoid change simply because we do not like it.

On a personal level, I have learned to skip over the lizard brain in three ways. First I identify what it is and when it emerges. The book Thinking, Fast and Slow by Daniel Kahneman is the bible when it comes to detailing cognitive biases. The second component is to adopt a growth mindset as described in the book Mindset by Carol Dweck. Then the third way is to view the world not as a limited pie to fight over, but a world of plenty which Peter Diamandis brilliantly describes in his book Abundance.

This learning comes from introspection and self-awareness over many years of mistakes and missed opportunities. There is no such analog at the organizational level though. And no, you cannot force all of your staff to read the three books I listed above. I was at a company that once told everyone to read “Who Moved My Cheese”, and then saw resignations skyrocket over the next six months.

As my friend was describing the situation of how to get engineers to adopt a more decoupled approach to their architecture, a thought occurred to me. Engineers generally do not like other people telling them how to write code. Results are generally much better when you instead state the problem to solve and let the engineer figure out the best approach. Much like the GPS in your phone or car, you set the destination, then let the system find the best route there.

The best run organizations are not ones that get into the weeds on how to do things. They do not encumber their employees with burdensome processes or layers of bureaucracy. Telling people what to do stifles creativity and suppresses innovation. Instead, you want to inspire exploration, experimentation, mistake making, and learning.

I call this idea “setting principles, not directives”. Directives are how typical top-down, hierarchical companies operate. Executives call the shots and employees are just there to execute orders. Whereas principles are a guide for why we do certain things and how we collaborate together as a team. Employees are then empowered to come up with the best solutions, supported by management that provides resources, expertise, and access for employees to do their best work.

What does setting principles look like? At Amazon, these are our sixteen Leadership Principles, which are the bedrock of our culture. They are integrated into our hiring practices, built into how we promote employees, and tied into how we prioritize our work. We also have concepts such as “two-pizza teams”, “one-way vs. two-way doors”, and “day 1 culture”, that are the operating system for our global organization. When we hire people based on these principles and give them the autonomy to leverage their skills, we enable employees to “invent and simplify” and to “think big” in delivering results for our customers and the company.

When you lay out clear operating principles, it gives clarity as to who owns the solution. Rather than being ambiguous, you are granting agency to employees to find the best solution. In the case of leading an engineering organization, this could be establishing overarching tenets such as building functionality as decoupled services, shifting left on security, or ensuring all AI and algorithms are inherently explainable. This leads to much better results than dictating what programming languages to use or forcing developers to write code in a certain way.

Whenever you are faced with putting some process, procedure, or guidelines together, consider whether they are principles or directives. Are you telling people what to do and where to go, or are you stating the destination to allow people to find the best path? If you give teams the freedom to explore, you might be surprised at how much better the results are.

What type of organization are you in, one that is driven top-down or one that operates bottom-up? How can you apply a principles based approach for your team?

Mark Birch, Editor & Founder of DEV.BIZ.OPS

DEVBIZOPS

Principles, Not Directives

To inspire innovation requires giving teams freedom to explore