Values are an interesting thing, everyone has them, even if they're not aware of it. I started thinking about mine during the past year.
It's not just individuals, also groups of people, communities, companies and even whole countries share a common set of values. Many companies even explicitly define and share them on their website. For example Bitmovin.
Companies do this because it helps align employees on a common goal, on a common way of working, and therefore increases efficiency.
As an individual knowing your values can have similar benefits. You know what's important for you, and can work towards getting it. Just imagine how great work could be if your way of working would be perfectly in tune with the organization. Every behavior expected of you is something you display naturally.
When there's total alignment, that's when you'll be able to do your best work. And it will be considerably more fun too.
What are values (to me)?
Before I start talking about my values let me clarify what exactly I mean by that.
To me, values are about how the work is done. Not what the work is or what work I'm interested in. Just how it's done, how the company works.
Professional interests, what I want to work on, and what I want the company to have (e.g. huge impact, millions of users) is a different topic. Equally important and related, but in my book not values.
Quality and efficiency
To me it's important that work can be done with high quality, future-proof and that it solves the root problem. This means first and foremost one thing is needed, time.
There has to be enough time to properly think about the problem, find the best solution and implement it. What I really don't like to do is always implement the fastest solution, therefore putting band-aids everywhere until the codebase is a Frankenstein monster and no one understands it any more.
Quality doesn't stop at the codebase though. It's also important that the end result, the product, has high quality. This includes design, UX and in case of APIs, their design too.
Efficiency is related to quality in the sense that if there's enough time to do high quality work, it's usually also efficient.
It means not doing work multiple times. For example if there's a feature A, with subfeatures A1 and A2, it would be best to develop both at the same time. Not develop A1 and a few weeks later A2. Doing that results in duplicated work because at first only A1 is thought about, and later A1 and A2 together.
It's worse if another developer is tasked with implementing A2. Then they have to understand the existing code, what the previous developer thought and come up with a holistic design for both.
Another example is if there's not enough time to think properly about a new feature, and only after 2 months it's clear that it has to be completely rewritten. Might have been fast in the beginning, but in the end twice the time is spent.
So in short, quality in efficiency is about doing the best work in the least amount of time.
Wholistic thinking is about thinking of all aspects, not just the ones in front of you, which is applicable to many situations.
For development this means engineering quality, product quality, the people in the company, future plans and also the business side. All of that is important to create good software. And in the end it's about solving business problems and making money. Which means sales and marketing are also important departments to consider during development.
Building the most amazing software that no one uses and doesn't make money is a quick way for companies to die.
This point seems to contradict my first value a little bit. The business doesn't care about high-quality software. They care about features and bugs, the internal quality is of no concern to them.
There it's on engineering to find a tradeoff. Developers shouldn't be forced to only work fast and disregard quality, but it also shouldn't be that they end up developing a new language where it's not needed, just because it's cool.
Wholistic thinking applies also to discussions. Usually I have an opinion, and others do too. Important is that I raise and talk about all points, not just the ones that support my opinion. It's not about pushing my opinion on others, it's about finding the best way forward.
Problem solving is another area where I think it's important. There is the problem that you see and try to solve. Then there is the reason why it exists, why it even is a problem, previous and other issues in the same area and so on. Thinking deeply about it leads to real understanding and solutions that far outperform others. It's the difference of really solving the problem or executing the task at hand and maybe creating issues for the future.
Ownership and autonomy
Ownership means to me that I care about the system, its UX, architecture, code quality, features, bugs and that it's running smoothly. It means that if there's critical a bug at 8pm, I'll fix it. And it means that I'll try to add new features in a coherent manner.
Autonomy is the way to get ownership. The higher my impact on decisions, the higher my degree of autonomy and therefore my sense of ownership is. This doesn't mean other people shouldn't be involved. Autonomy also means being able to ask the right people for advice.
Ownership can have many forms. One can take ownership of an entire system, projects within that system, particular features or simply the work their doing. Depending on how far reaching autonomy one has and how many other people are working on it.
A system architect will own the system's architecture, but not its code. Developers will own the code. But when the same code is touched by 20 different developers, and the next time they see it it doesn't look like anything they wrote, ownership dwindles.
Another important aspect is focus. The example above has little of it. If, on the contrary, 3 devs work on only 1 service and no one else does, they will feel strong ownership there.
Ownership is something that comes naturally to me. I own my work and stand for it, the good parts and the bad. Autonomy has to be given by the organization and is necessary to improve the bad parts. If I'm not able to improve and fix my mistakes I'll feel bad.
Trust and respect
Trust and respect are cornerstones of human interaction for me. It's important that I respect my colleagues, interact with them that way and that they do the same in return.
Trust has many facets. One is that I can be sure that when I say something stupid, it's not used against me. This is about psychological safety.
Another is that people are trusted to do their work diligently. They are hired to take work and responsibility off others. If they are then micromanaged the responsibility is still with the micromanager. Which happens when the manager is not ready to trust someone else to do the work.
A very important point about trust is that it has to be given before it can be earned. Meaning that my manager has to count on me to do the work properly, not micromanage, and then I can prove that their trust is warranted. If you don't choose to trust someone, it's almost impossible for them to prove that you actually could.
In this post I thought of values in a professional context. It is of course also be beneficial to know your personal values. That's a post for another time.
When you have values, it's also necessary to define what is not important to you. If everything is important, nothing is.
I didn't lay it out explicitly, but in essence it's the opposites of the values. Take quality and efficiency. The opposite would be to develop and release a lot of features. I'm content working on one thing for a couple months while others want to crank out feature after feature.
Another example is autonomy. I want to be given a goal and work independently towards that while others strive in a more rigid environment.
Everyone has different values, and that's good. Different people are needed in different roles. There are no 'better' values than others. So start finding out yours!