It Is Not Your Responsibility?

Responsibility isn't just in your job description—it's your ladder to growth. Break free from your golden cage.

It Is Not Your Responsibility?

There's a good chance that's bullshit. Sometimes you might think something is beyond your duties, your typical, default duties. Let's put helping juniors on the table, for example. An obvious topic. You can get by in your career without it and somehow it'll work out. Nobody told you about it during recruitment, and it's probably not written in your contract either.

But so, what?

If you explicitly state that something isn't your responsibility and leave the topic, concluding it with only that sentence, then it's poor form, it will be difficult for you to climb the ladder of a programming career. Let's think about this a bit deeper, because each of us, every day, is a slave to our golden cage.

Golden cage - Refers to closing oneself off to other viewpoints or attitudes. It may result from strong self-confidence, arrogance, or in most cases, getting used to the surrounding reality. Which makes it difficult for us to see something more than what we are accustomed to.

To be clear. It's not about agreeing to everything because you must be proactive, nice, lead by example, and deal with every buck-passing. It's about not reacting instinctively with a defensive attitude because you're being proposed an activity different from what you've been used to so far.

Consciously analyze activities that appear in your daily life. The fact that you haven't done something so far doesn't mean it's beyond your duties. However, if you're sure that it really is, then think about what you can gain from it. If nothing, then diplomatically decline and don't get involved.

If you want to move up and increase your capabilities, there's no other way than to fulfill your current duties and grab those that relate to the role one step higher.

Simplified thinking scheme. Use it to decide whether to take on something or not.

It's clear that every undertaking has its pros and cons. And there's no point in distorting reality. The question is whether those cons you see really are cons.

Therefore, before you judge something, analyze it, understand it, give yourself a moment to be with it. It's worth taking a moment for deeper analysis. It's normal that you might be thrown off balance if something seems like a "brazen attempt" to dump a new responsibility on you. Remember that where nerves appear, decisions can be wrong. Cool down, think, and return to the topic. The person proposing something to you doesn't always need an answer right here and now. Your goal is to move higher. Without attempting to take on new topics, it won't happen. 🤷

Take responsibility for what you do.

Development isn't just about coffee in the kitchen, fruit Thursdays, team-building events for big 💰 or training. All of this is to make your reality easier, but at the end of the day, professionalism is expected from you. A coddled story? Maybe, but I have experiences indicating that IT has become (perhaps it always was in its own way, I don't know) a place where contrived ego has nested quite well.

In my opinion, today's modern programmer isn't just the coding guy. My perception is that for a real programmer, coding is just a certain slice of what belongs to your basic duties.

And what can I list here?

  • Working with the team (not to be confused with working in a team).
  • Helping with product version releases (and no, this isn't the responsibility of leaders).
  • Code reviews.
  • Communication with business (and no, this isn't the responsibility of leaders).
  • Delivering value (not just through code).

And these are probably just a few of them. Our daily life is more complicated. We are "entangled" in many things, and please note that everything around is there to write better code. Code should be the result of all these interactions and activities that happen in our daily lives.

Working with code is that cherry on the cake, but before you take it off and eat it, bake yourself an elegant cake first, meaning focus on the people around and the processes. You need to participate in them too.

Would you believe that I've encountered a situation where "seniors" didn't want to prepare new application versions (clicking through in CI/CD tool), thinking it was the responsibility of team leaders?

That's roughly how I felt when I heard it.

👉 Demand from yourself to be an engineer and a professional. Development isn't just coding.

Don't lose sight of the goal.

In line with this, your goal must be to look for new activities, new interactions with team members. Every offer to help will bring you closer to promotion, a raise, and eternal glory.

Amen. 🤜🤛


By the way, Radek Maziarka, one of Poland's leading consultants, also recently addressed this topic.

Czy my DEV, QA, UX, SEC (... inne role techniczne w produkcie) jesteśmy… | Radek Maziarka | 27 comments
Czy my DEV, QA, UX, SEC (... inne role techniczne w produkcie) jesteśmy tylko narzędziem w procesie? 🛠 Bazą do posta jest odcinek Better Software Design Mariusz Gil o dev-grzechach kariery w IT z Wojtek Ptak (materiał poniżej). Już któryś raz na spotkaniu słyszę: "To nie jest moja odpowiedzialność, ja mam to tylko..." - Dev: zakodzić... - QA: przetestować... - UX: zaprojektować... "... zgodnie z tym co mam napisane w Jirze." Jako inżynierowie mamy ogromny wpływ na nasz biznes, na naszych klientów. Nasze rozwiązania zmieniają otoczenie biznesowe, sprawiając, że firma rozwija się, a użytkownicy rozwiązują swoje problemy. Jednocześnie spłycamy naszą rolę do bycia "robotnikiem" na linii produkcyjnej. Wziąć taska, przerzucić, zakończyć. Mój trud skończony. Jak ktoś ma nas, inżynierów, brać na serio, kiedy sami siebie nie traktujemy poważnie? 🤔 | 27 comments on LinkedIn

The mentioned episode of the Better Software Design podcast:

O siedmiu dev-grzechach głównych kariery w IT z Wojtkiem Ptakiem
Kod często można zmienić relatywnie łatwo. Jednak zupełnie inaczej jest z własnymi nawykami czy podejściem. Dziś na czynniki pierwsze rozkładamy kilka typowych “dev-grzeszków”, które z perspektywy osób odpowiedzialnych za całe piony IT mogą przeszkadzać w karierze. Ponieważ technologia to niestety nie wszystko… Moim gościem jest dziś ponownie Wojtek Ptak, Executive Engineering Director oraz Head of Development w Revolut Business. A jakich tematów dotkniemy podczas rozmowy? Choćby tego, że błędem jest nieposiadanie planu.

~KB