Make Your Harder, and 10 Other Ways to Adopt a Total Ownership Mindset

When Codrin Băleanu was a junior software developer he used to print out his code on paper. He would select a particular intricate piece of code, send it to the printer, take the papers with him, and read them quietly. He would read until he saw the workflow in front of his eyes, until he could visualize the data flowing as smooth as rivers.

 
Now an Engineering Lead at Levi9, Codrin describes himself as 
simply a person who gets paid to do what he likes

. And he credits most of his career advancement to that attitude that made him read code on paper until he understood it completely: 
Total Ownership Mindset
.

1. Own the project

“Total ownership” is a concept that gets thrown around a lot during agile meetings. It might sound a bit intimidating, as it sounds like people are expected to do much more than their fair share and to place work, the customer, or the project above everything else, including personal life. But Codrin says the concept is completely misunderstood.

 
“
I think of it like a car I just bought,
”
says Codrin.
“
It is mine, I take care of it. I treat it with care, I don’t want it to get scratched, I don’t want to smash it into walls.
”
A car owner might seek to always improve his car, buying accessories, equipping it with new gadgets, and finding ways to make it run better.
“
In the same manner, if I own my work — be it a customer, a product, a task — I take care of it. I want it to work better, faster, and to be more interesting.

”
 
In other words, total ownership does not mean that your work never stops, but rather that you treat it as if it’s your job to make it better.
 
Here are 
10 pieces of advice
from Codrin about how to approach and boost your ownership mindset.

Rule 1: The customer business is your business

The first rule of the ownership mindset is to understand the business of your customer and understand how that business creates money, part of which will end up in your pocket. If your customer has an issue, you’ll be able to move mountains and do anything that needs to be done to solve that problem. You might end up solving problems that are not part of your expertise or technology, but that will help you grow. This is the root of total ownership.

 
Part of owning a project means understanding that you and the customer are fighting for the same goal.
“Listen to the customer when he talks about business,”
advises Codrin.
“
Your mind might be tempted to wonder, but if you understand the business, you’ll be able to open conversations, reframe your proposals from a business point of view and get your point of view across

.”

2. Own your code

When you hear “be the owner of the code” you might be tempted to think “of course I am, my code is my baby”. But that’s the opposite of what it means! If your code is your “child” and you get defensive about it being cut, changed, transformed, you are harming the product and business.

Ownership means always looking for ways to make it better, at the cost of your own ego sometimes
.

Rule 2: Pick up the trash

When you walk on the street and see a piece of trash, you will probably take it and throw it in the bin. You can do the same in a project: if there’s a part of work that nobody wants to touch — a procedure, a database — own it. Make it your goal to fix it, repair it, solve it.

 

Refactoring is part of the same mentality of picking up the trash

. For example, if you have a 2000-line Javascript program, don’t be the one that adds another 100. Refactor. Clean up after yourself, don’t postpone this for a future date, because you’ll never get to it.

 
Refactoring might not be part of the job description or existing inside a story point, so you have to convince the customer that the process is essential. However, try and explain it not from your point of view (“this code is messy”), but from the point of view of the customer. Focus on the value that refactoring will bring, such as: the code working faster, it’s easier to extend or it’s easier to maintain and repair if there are any bugs found. No product manager or architect or customer would refuse the cost. The condition is to bring value.

 
“Here is my rule,”
 clarifies Codrin.
“
If I repeat a line of code a second time, I consider a “yellow” warning. If I have to repeat the same line of code for a third time, I stop and I refactor. I never broke that rule

.”

Rule 3: Wreck something

Once you have an ownership mentality, you will understand accountability. Once more, the concept of accountability sounds scary, because it’s often associated with blaming. Codrin Băleanu sees this differently:

“accountability is seeing the bigger picture and asking yourself: Is there something that could be broken if I change this one line of code?
 Don’t be afraid of failure. Unless you experience it, you’ll never be a good engineer. Wreck something.
”
 
After a bit, this attitude gives you more time to innovate, learn or research. And this — as you’ll come to see — is the only way forward.

3. Own your time

One advice of Codrin for those who want to adopt a total ownership mindset might be summarized as “Don’t be the British Empire!” Sounds easy enough, right? But here is what it means.

 
“When the British Empire was at its peak, one of the reasons for its success was its ability to take people who were completely unprepared, place them in a factory and have them produce luxury goods, without any training. They had reduced manufacturing to such a degree, that any person was expandable, a cog in the mechanism.”

While an admirer of British Empire history, Codrin warns that
“
If you repeat everything ad infinitum and do everything the same for years and years, you become expendable. The industry will disappear
.”
 
A developer will never feel motivated and engaged in a British-Empire-like process. Simply repeating other bits of code does not leave you content. Being a developer means having the space to be creative and innovative and that also means pushing against being busy all the time. 

Developers are creative beings
.

Rule 4: If you are 100% busy, you have no time to think

“If at this moment, you already know what you’ll do in the next 3 or 6 months, then that’s a problem. This is Agile done badly,”
 says Codrin. Cramming the schedule with tight-fit plans leaves no space for innovation. You cannot bring anything creative into something that has been planned for the next 6 months.

 
“
When we are blocked by work, we don’t have time to think
. Always push against this. And you do this by continuously improving processes, so they are better and allow you time.”

Rule 5: Innovate. Innovate. Innovate

Monoliths will always fall, just like all the previous monoliths fell when Netflix appeared. In old companies, processes are what they are, people are working and business is going just fine. But all the while, someone from outside is looking at those processes, analyzing them, and seeing spots that can be done better. This is why process innovation is key to staying relevant.

Rule 6: Change your way to work

Things tend to quickly get into a routine, but routine is the death of innovation and creativity. You always need to change something — sometimes as simple as changing your way to work. Another example is how you approach a story point, change a technology or change your entire playing field. In time, this will help you to not be scared by anything new, because change will be ingrained in you. You will stay relevant to the market.

Rule 7: Be lazy

One of Codrin’s favorite advice to young developers is to “be lazy”. By that, he means to be very critical with the time they designate for writing code.

 
“Sitting in front of a computer for 8 hours does not make you a software developer.” You need to always have the mindset of ‘what else can I do?’. Or, on the contrary, the work might be boring —then find a way to make it interesting. “

For example, if you just type data, write a script that automates the process. Make the machine work for you. Be lazy.
”

4. Own your progress

As a junior, Codrin used to look for the hardest, most scary thing to do.
“I was scared by many things: Linux, databases, VIM editors, the cloud. As I felt overwhelmed by the new, the only solution to that was to learn. I would use a book, a tutorial, or a video.”

 
“
If your job is too easy, make it harder
.”
This attitude sums up Codrin’s approach to how the ownership mindset, together with continuous innovation ties up to professional progress.

Rule 8: Identify the people from your future

In the end, this ownership attitude is something that benefits not just the customer and the company, but the developer himself.
“
Recognized seniority comes with hard work and involvement
. Seniority is something you gain. It is not given to you,”
 he says.
 
As a practical advice on how to push yourself on the road to a higher rank, Codrin says to look for the people coming from the future: your future. Identify the people you want to be like 5-10 years from now, as they represent your future. Learn from them to increase your chances to end up like them.

Rule 9: Own your job to own your purpose

The road to seniority is peppered with “why”. “Why is this needed? Why does the customer want this? Why do we do things a certain way?” Having the answers to why gives you not only ownership, but a sense of professional purpose. When projects are too complex and opaque to understand, Codrin encourages team members to look for the right person to ask questions, until they gain a deeper understanding of its purpose.

“
If you don’t understand why you do something, and what is the purpose to which you are contributing, you’ll never like what you do
.”

Rule 10: In a changing world, your mindset is the constant

IT is an industry of p
meer...

Naar vacature

Meer vacatures van Levi9