# Responsibilities and ownership
In the previous post I have explained that the team is fully responsible for developing the product. Thus, to thrive, it is very important to take full ownership of the product. A feature that was developed by your colleague does not work? Take ownership. Fix it. Don't complain about how it was your colleagues fault. You're a team - you should take full responsibility for everything your team does, not just what you do. Obviously, if the colleague notices the bug and is available to fix it, no need to jump in and take over - but you should always offer help and get it fixed asap. Also, if the colleague broke the law or did some crazy stuff like purposely deleting the production environment - no need to take the full ownership.
Especially during fuckups, it shows, how the team handles ownership. If your colleague does a major fuckup in the production environment on Friday 3pm, what are you going to do? Tell him to enjoy his weekend and leave? Or help him recover from the fuckup as quickly as possible? While I agree that this should not happen in the first place, it happens. We're all humans and there will be fuckups. You can do many things to mitigate the risk, but there's always a risk. I will cover some specific fuckups and how we handled them in a later post in more depth.
Taking ownership and being responsible about the product is not just about handling fuckups. It also means that you do the very best to delivery the best possible output. You are not developing a short-term project to make a client happy where the code, quality or speed does not matter as much. I'm an advocate of being pragmatic and not prematurely optimizing. It's still part of your responsibility to recognize issues in code quality, product quality, performance and so on and keep an eye on it. If you come across any possible improvements, talk to the team and prioritize.
In our team I've experienced the greatest ownership so far. Even from freelancers. When shit hit the fan, we were all there to help. No blaming, just getting it done. We surely talked about it afterwards on how to avoid those issues in the future, but we didn't point fingers. If your colleague is a normal human with normal emotions, he/she will already feel bad enough for messing up - no need to emphasize.
Many of the features or process improvements were actually suggested by developers, talked through with the business and product owners and then implemented.
For me, having this kind of responsibility and actually making use of it comes with building a bond with the product and team. I have a hard time keeping work and personal life separated and I don't mind. Work is a big part of your life - usually taking up ~40+ hours of your week. Simply shutting off after work and not thinking about it any more just does not work for me and I think it's the same for many other developers. However, I love what I do and I love being able to have a say in the product development.
If you want the rest of the team to take more ownership, one very important thing is to always explain the reasoning behind something. You have a great suggestion on improving the product and want the team to help you? Don't just explain your implementation details and what you want to do, explain why it improves the product. It is far easier to have your team back you up, if they understand why they're doing it.
Especially in product development, where the team has a lot of freedom, but also responsibility, it is crucial to take full ownership. It is important to stay disciplined. The freedom and possibly lack of deadlines allows you to theoretically spend way too much time looking for the perfect framework/implementation. You should keep a high quality standard, however, you must also be pragmatic at some point. A good stigma is the Pareto principle (opens new window). You might now it as the 80/20 rule, meaning you get 80% done in 20% of the time/effort you put in. Usually, you get pretty far if you follow the rule. It does not mean, you should stop implementation and testing because you reached 80%. You should still question yourself, if the amount of time you are investing is worth the outcome. Do not abuse the freedom that comes with product development, you still need to get shit done.