Once upon a time, in the good old days of office work, we had a ritual called the standup meeting. It meant exactly what it said: we would stand up, gathering in a semi-circle with our coffee mugs, sharing updates on our work. Those were simpler times, but one thing always struck me as odd – the unspoken divide between the project manager on one side and the programmers on the other. It almost looked like a reporting line, but here's a revelation: it shouldn't be.
Fast forward to today, and the landscape of work has shifted dramatically. Some teams have been recalled to the office, affectionately dubbed the 'mothership', where their bosses can observe them busily ticking off tasks. The old scenery of subordination is back, albeit under the guise of 'team synergy'. However, those fortunate enough to be in a remote-first environment experience a different dynamic. The physical manifestations of subordination are gone, but don't be misled. The same underlying issues persist, only now they manifest verbally. In video calls and chat messages, the relics of an outdated hierarchy linger.
Dear Developer,
Let's get one thing straight: your product manager is not your boss. If they're assigning tasks to you, it’s time to push back. Why? Because software development is not about taking orders; it's about collaboration and shared responsibility.
Now, let's dive into the world of Scrum roles. You might not be working in a Scrum framework, but understanding these roles is crucial in grasping the concept of shared authority – or, more accurately, the lack of it. In Scrum, there's the Product Owner, Scrum Master, and the Development Team. None of these roles hold authority over the others. Instead, they work together, each with their unique responsibilities, to achieve a common goal.
The Product Owner focuses on what to build, the Scrum Master facilitates the process, and the Development Team, that's you, focuses on how to build it. Notice something? There’s no boss-subordinate dynamic here. It’s a collaboration.
So, why am I boring you with Scrum? Because it's a perfect example of how discipline and self-organization can coexist. Once you master these skills, you probably should discard the framework, because your mindset has evolved. You're not just following a set of rules; you're internalizing principles of effective teamwork and responsibility. Changing your behavior has changed your mindset.
Back to our main topic: the notion of a 'boss'. In many teams, there's no formal boss. Yet, if you act as if there is one, you're creating that dynamic by ceding your autonomy and shying away from responsibility. Why would you do that? Are you avoiding responsibility for the product? If that's the case, you might need to reconsider your role.
As a developer, your job is to develop – not just software, but the product and yourself. Embrace this role. Start by understanding your value in the team, voicing your opinions, and taking ownership of your work. You are not just a cog in a machine; you're a key player in a collaborative effort.
Remember, the project manager is there to facilitate, not to dictate. Your role is not to follow orders blindly but to engage actively in the creation process. It's about finding that balance between guidance and independence, following a framework, and creating your path.
In conclusion, don't let outdated notions of hierarchy dictate how you work in a team. Embrace your autonomy, collaborate effectively, and take responsibility for your part in the project. That's the essence of being a modern developer. So, start developing – in every sense of the word.