Comment by Frost1x
3 years ago
And what if the same major thing breaks but you were asked to do it? Your necks on the line and you did something wrong that you were asked to do correctly. The problem is that part of current micromanagement environments isn't just about micromanagement but also passing down risk and responsibility to developers.
You can do the change work in a feature branch and propose the idea after the fact. If there's interest "I've already done it." Stakeholders get a bit of instant gratification like their request just materialized into thin air. If they're not interested, don't mention it and let the work go unused, rack it up as professional development time and work.
I do this fairly often. If a decision has a bunch of real risk associated with it I make sure to get sign off and create an appropriate evidence trail to pass risk back up when it's passed down. Much of work is just passing risk and liability around to PYA.
Because if you're asked to do something, someone has presumably thought it through and accepted the risk to the business/client.
I'm not sure I'd keep someone on the team who did a branch AWOL and proposed the idea after the fact. Doesn't show much respect for the team, that time could've been spent working towards goals agreed by the whole team.
If you don't have a lead or management environment with ears open to exploratory change, tech debt payoff or "do it better" tasks or whatever... and you have to manage up so much... that sounds like an issue to me.
If you consider such behavior 'AWOL' then you've bought into modern development micromanagement and may be part of the issue. That perspective doesn't believe any degree of autonomy and desires drone teams who just crank out on orders. I would never work in such a role or environment, but to each their own I suppose.
There's also an assumption buried in there that any time spent working is somehow owned by you, your leadership, or the organization and not your team or teammates time. I've personally spent plenty of hours "off the clock" investing in directions I think are correct in an IC environment and it's paid off many times (I've also wasted my time on occasion but it's my own time and my choice). If you have slack in your schedule or want to push something out by taking initiative, then the type of management philosophy describe loathes initiative, creativity, and innovation in engineering. It's a great way to drive those abilities out of your teams and organizations.
It's good to foster teamwork and target goals but you also have to give your teams some degree of autonomy, otherwise just as the article describes, they will leave from the drudgery. The allure of technology is the tangibility of innovation. If you rip that off development, for many, the work becomes unenjoyable, tedious, repetitive, etc.
> Part of the issue
What issue? My projects are delivered on time, on budget and to the customers expectations without undue risk or unpredictability. That's my job.
Nobody on my teams would say I micromanage them, everyone has a large degree of autonomy within a framework of shared goals and shared values that keeps efforts working towards cohesive results.
With autonomy comes responsibility to the team, business, customer and every stakeholder ... so yes, i'd consider it AWOL to undertake work that doesn't respect the input of everyone else by getting agreement beforehand.
3 replies →