Never Say Always

An advanced robot leaning forward

Ideals, principles and values

People just love to hold on to them. I get it. 

It gives us a sense of control over the chaotic reality. It also provides us with the feeling that we are making the world a better place if we stick to those. It makes us feel better about ourselves.

 

Here are some examples:

  • Offering your seat at the bus/subway when an elder walks in
  • Making an effort to return a lost wallet to its owner
  • Making sure to greet all friends & family at the holidays or on their birthdays
  • Never come empty handed to a place you were invited in

 

And so forth.

 

For some of us – those are guidelines we live by. It means that we’ll make an effort to follow those, but from time to time we may decide to ignore them for various reasons.

For many of us, however, those are most likely to be translated to rules. Rules we voluntarily embraced and took on ourselves. It means that we rarely question those anymore and follow them almost blindly.

In this post I’ll make the claim that turning ideals, principles and values into rules is probably not in your best interest. Although I believe this statement applies both to your personal & professional life – due to the nature of this blog – I’ll stick to the impact of those on your professional life.

 

When principles, ideals and values become rules in your workplace

Let’s take some examples of PIV (principles, ideals and values):

  • Making data driven decisions
  • Production issues should be followed with a post-mortem
  • Each task should have a Jira ticket
  • Product managers are the ones assigning tasks to the engineering team
  • Office days are Monday and Wednesday and everyone should make an effort to be in the office these days
  • You should avoid code-duplication when possible
  • Specs should be the single source of truth for the ‘what’ and the ‘why’

 

And I guess you can come up with plenty more.

Now, the list above makes total sense to me. I can easily agree to any of the items on that list.

However, when turning this PIV list into rules, it will transition to the following:

  • We must make data driven decisions
  • There must be a post-mortem after each production issue
  • Each task must have a Jira ticket
  • Only product managers are the ones assigning tasks to the engineering team
  • It’s mandatory to be on Monday and Wednesday in the office
  • You must never duplicate code
  • Specs are the only single source of truth for the ‘what’ and the ‘why’

 

Note the usage of ‘must’, ‘only’ and ‘mandatory’.

Those are strict terms, and strict is the opposite of flexible.

It’s therefore quite clear that if we turn PIV into rules we are losing flexibility.

 

It could be that having those as strict rules is exactly what you want. But what about the others around you? And what about the business? Is it good for both of them as well?

 

Let’s take the post-mortem rule from above as an example:

When you insist that each production issue must be followed with a post-mortem it means that each production issue will have a meeting on the calendar with many participants. Is this the best usage of everyone’s time?

After all – production issues are happening all the time. Have you counted the accumulated hours spent on such meetings?

Have you revisited the data and verified that all these post mortems actually reduced the amount of production issues by an order of magnitude?

 

I’m not claiming in any way that post-mortems are useless. Talking openly about incidents in a blameless manner with a real intention of improving – can be really beneficial for the organization. However, when it becomes a rule, and all production issues are being discussed in length – then you pay in speed, people will start taking them less seriously and I’m not sure the ROI will actually be positive

The others PIVs above follow the same principles:

  • When you insist on making only data driven decisions then you are totally ignoring the value of intuition and you also force situations where a decision cannot be made until the data becomes available (sometimes it may take weeks).
  • When you insist that each task must have a Jira ticket you eliminate the possibility to close tiny issues between departments that take only a few minutes (or even seconds) to resolve.
  • When you insist that only product managers can assign tasks to engineering that you’re forcing them to become a bottleneck in situations where tasks would otherwise be closed in a friction of time.
  • When you force people to always be in the office on specific days, you don’t allow them to react to life events that take place from time to time, specifically on those days. You may therefore increase resentment and risk a retention problem.
  • When you don’t allow any code duplications in your engineering department whatsoever, you may risk situations where the engineers are spending a great deal of time working around a code duplication in a module that no one cares about.
  • When you only allow ‘official specs’ to be the single source of truth for the ‘what’ and the ‘why’ then you are forcing your PMs to compose a full product specification even for tiny requirements (where you could use a short Jira ticket instead).

 

Most of the time rules will be slowing you down. This is their main negative impact. However, as you can see – unneeded rules may also generate resentment among your people. People will start complaining that they are spending too much time in meetings, that processes take forever and that the policies are too strict.

Is that what you want for your organization?

 

Another side effect of rules is related to my previous post about creativity and thinking out of the box (you can find this post here). Rules & thinking out of the box don’t play nicely together. Rules create the box that you are trying so hard to break out of

It’s not trivial to show the direct correlation between the rules mentioned above to ‘out of the box thinking’. I can only tell you from personal experience that the more you rely on rules for ‘protecting’ yourself from the chaotic reality, the more you become dependent on their existence. And if you are used to living by rules, it’s very hard to promote creative thinking, which by its nature, requires a lack of boundaries.

So, what should I do?

Stick to guidelines.

Again, the list above (in its original form) – is a great list of principles to work by. Just treat those as guidelines and leave room for flexibility.

In addition, try to think for a moment what your core principles are.

Core principles are the principles that you revert to, when you are not sure what to do. Those are the principles that also help you to understand whether you should stick to your guidelines or ignore them for the given, specific case.

 

My core principles

If you are unsure how to come up with your personal ‘core principles’ let me try to help you by describing you mine.

Each of the core principles I have chosen to adopt in my professional life was well thought and considered.

Also – I admit that I started my journey with tons of principles and rules, and learned over the years to let go and stick to what matters.

Here are my 3 core principles that guide me in my professional life:

  1. Speed
  2. Product market fit
  3. Be a decent human being (or in other words – don’t be a jerk)

 

Speed

Speed is important because otherwise you’ll run out of money before you reach product market fit. If you have already reached PMF or your company is cash flow positive – then speed is still very important for staying ahead of the competition. 

You need to have efficient processes in place, and make sure you work only on the things that move the needle.

Now – here is the beauty of this: 

This core principle is backing up (and could be the origin of) the ‘postmortem’, ‘Jira ticket for everything’, ‘PMs assigning tasks to engineering’ and ‘avoiding code duplications’, because those principles are tuned towards an efficient process.

And if sticking to one of those, in a very specific case, means you’ll be sacrificing speed – then you don’t need to follow the guideline in this specific case.

Product market fit

I can’t really see how an organization can become really successful if it doesn’t sell a product its customers can’t live without. You may have a cute business without reaching PMF, but you need to really delight your customers if you want to become big.

And if the organization I’m in has reached PMF already then I’d probably swap this core principle with either growth or market leadership.

Anyway – this core principle is promoting the ‘data driven decisions’ and other principles not listed here about meeting with customers, setting a north star, etc..

Be a decent human being

Well… to be honest… You can build a really successful business by sticking to the first two core principles only. I’m familiar with at least two companies, where this core principle is not part of their culture 🙂

This one is for me. At the end of the day – work is just work. I come back home, and I look at myself in the mirror. It’s important for me to know that I treated everyone with respect, even though there were disagreements or tough decisions to be made. 

It’s just the person I want to be.

 

To summarize

Principles, values and ideals are good to have, and probably should be followed for most of the time. Be careful of following them blindly though.

Understanding what are your core principles will significantly improve your decision making process and allow you to be flexible when needed.

 

Last – even if at some point in time it made sense to you to adopt a specific value or principle – it doesn’t mean it still makes sense to do so now.

From time to time – re-evaluate your PIV and see if you’re not following merely a romantic value you adopted in your childhood, which is no longer relevant to your life and doesn’t serve you anymore.

I once asked a colleague why he sticks to a specific principle. He answered: “I don’t know; I don’t question my principles”.

I don’t know how to say this delicately: This is not a smart thing to do. Always ask yourself ‘why’ you do what you do, and always have a good answer to this question.

 

So… that’s it for today!

If you found this post/series useful – feel free to let me know in the comments. If you think others can benefit from it – feel free to share it with them.

 

Thank you, and until next time 🙂

 

Related posts

A man is buttoning his suit

The CEOs You’ll be Working With

The previous posts were somewhat ‘heavy’ so today I’d like to have a shorter and lighter post. Hence, today we’ll be discussing the various types

Two robots sitting back to back

Asta La Vista Baby!

Maybe I’m late to the party, I don’t know, but it took me some time to process it. I gave it a lot of thought

A man wearing a box

No Sacred Cows

This post is probably gonna be beneficial to all sorts of people and not only to product managers. This is because today I’m gonna talk