This might not be the best thing to say out loud, but I sometimes have issues with authority. I like to own my own processes, manage my own time, and do things the way they work for me. That's not to say I'm a lone wolf or cowboy by any means. I thrive in teams. My favorite past time is advocating for my fellow developers and debating ways in which we can improve ourselves and our software. I wouldn't be where I am today without having been a part of fantastic and largely successful teams.
Perhaps I'd better say I have issues with incompetent and micromanagerial authority.
I've worked in a number of diverse teams. Each with their own process structure, hierarchy, politics, etc.. Far and away, anecdotally speaking at least, the most successful teams I've been on were developer lead, developer centric, and developer trusted teams. The most successful teams I've been blessed to be on were not micromanaged by a PM asking for hourly updates, task validation, and queries as to whether or not the deliverable would be ready by the end of the arbitrarily scheduled two week sprint.
Rather, the successful project managers trusted us to do our job, facilitated quick and simple stand ups, and made sure we had focus and vision toward the successful end goal. They made sure we understood the requests, were comfortable with our assignments, and, to hammer this home, made sure we had VISION. It was never the product of Gantt charts, spreadsheets, and arbitrary deadlines.
We don't have a developer issue
Too often, organizational management seems keen on preventing developers from creating products that fulfill compelling, and crucially, customer requested needs. I've often seen developer's interest in the discovery of "why" the software is being built undermined by the "when". The most important thing a developer can do nowadays isn't fulfilling the client's needs; it is instead about getting something Done by Date. Done becomes a product no customer wants or can use because the process of discovery critical to agile methodology has been eschewed in favor of arbitrary completeness. In addition, the product is likely riddled with chaos because the team has been repeatedly focused on creating new features instead of characterizing their own work and removing the chaos.
We have a management issue
A toxic and prolific pattern in project management is when developers are asked to estimate software project requirements upfront for the entirety of the project, then rigorously held to those deadlines regardless of the complexity and nuance extant in software development. This results in Aglie-Fall sprints which leave all parties disgruntled and ready to burn the codebase to the ground at best. Developers don't like missing deadlines any more than anybody else to exist. We take pride in our work and want to produce the highest quality software we can be proud of. We don't like being asked to burn down our hours, or really even keep track of hours in the first place. This is why so many developers advocate for poker, or t-shirt sizing when in sprint planning sessions. Hours break promises.
Traditional management is focused on running factory-like assembly lines and order fulfillment using fixed, known best practices to schedule known duration tasks. Software development is made up of many unknown duration tasks. This fundamentally unpredictable nature makes traditional management's predictive planning techniques particularly unsuited for software projects.
Adherence to rigid process and outdated, MBA-practice-driven-management ignores danger signs of a project going off the rails because the legacy MBA bias built into the organization causes management to apply anti-patterns like:
- Devs that take a reasonable amount of extra time to check their work and remove the chaos are characterized as 'kinda slow'
- Devs that notice something is amiss with product/market fit are gently steered back to their keyboard to implement more features, with the promise that "we'll handle tech debt in the next release"
- Devs who implement features quickly so that another silo can check them for 'quality' are appreciated because they are getting to Done quickly
- Devs that wander into the field and notice that customers are really struggling to use the product are carefully steered back, with the promise that "we'll address these concerns in the next release"
- Dev Managers that try and understand the Big Picture of product/market fit, packaging, and pricing are patted on the head and sent back to focus the dev team on implementing the scoped features that no customer wants
Don't change developers, change management
Traditional management needs to evolve; they should start by listening to what developers are saying management should do
- Provide a clear sense of purpose, vision and mission
- Invest in my growth, provide me opportunities for advancement
- Grant autonomy and delegate authority
- Trust those you hired until trust is lost, and handle lost trust appropriately
They should also listen to what management shouldn't be doing:
- Do not micromanage - Developers design and write the code, not the managers
- Have a technical background - There is nothing worse than a manager whose eyes glaze over when a dev answers their question
- Don't just cave to political pressure - Company politics are firmly in the realm of management, please diligently represent the team
After listening to developers, traditional management needs to throw out the following ill-suited-to-software practices:
- Predictive planning based on detailed estimates - Predictive planning is used to organize known duration manufacturing and order fulfillment tasks, not software projects
- Tasking developers with creating Detailed Estimates
- Work Breakdown Structure - Again, this is great for known duration tasks, not software projects
- Arbitrary Due Dates calculated from flawed detailed estimates
- Blindly accepting scope