The video discusses a common challenge developers face when trying to gain more influence in decision-making beyond just writing code. Many developers expect their code to communicate their reasoning and intentions, but code alone only shows how something is built, not why it is built or what trade-offs were made. The speaker emphasizes that if developers want to have a say in decisions, they need to explicitly share their reasoning, including the user problem, trade-offs, and the responsibilities they want to take on, rather than expecting others to guess.
The distinction between implementation, design, and technical leadership is highlighted. Implementation focuses on how to build a solution, design addresses what belongs in the system and why, and technical leadership connects these decisions to the team’s work. Titles alone do not clarify which part of this spectrum a developer wants to own, so clear communication about responsibilities is crucial. Without this clarity, developers risk being stuck in the “ticket-taker” role—completing assigned tasks without influencing broader decisions.
The video uses three examples—Sarah, Mark, and David—to illustrate common pitfalls. Sarah understands the legacy system but keeps her design reasoning to herself, resulting in fixes that don’t influence future changes. Mark completes assigned work without understanding or questioning the user needs, missing the bigger picture. David wants more influence but asks for a title without defining the scope or responsibilities he seeks. These examples show that coding skill alone is not enough to gain influence; clear communication of intent and responsibility is necessary.
To move forward, developers should prepare a short note for their lead before starting new work. This note should outline the user problem, one trade-off, and the responsibility they want to take on. If the user problem is unclear, they should ask questions rather than guessing. They should also be transparent about what they are willing to give up if they take on new responsibilities. This approach creates a concrete proposal that can be discussed and agreed upon, rather than vague ambitions that lead nowhere.
Finally, the speaker encourages developers to be honest about their career goals. If they want to stay focused on deep implementation work, that is perfectly valid and should be communicated without apology. Not everyone needs to move into architecture or management roles to be successful. The key message is to stop expecting code to communicate what hasn’t been said and to actively engage in discussions about responsibilities and decisions. For those seeking promotion or leadership roles, the speaker offers one-on-one coaching, with a link provided in the video description.
