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 permanent changes. One company rises, and three others fall. As systems get more and more complex, ownership gets distributed and it gets more and more difficult to understand who is in charge of what. The only way to navigate the continuously transforming landscape is to have this one constant mindset: total ownership.
