[Frost1x]

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.

[sirsinsalot]

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.

[Frost1x]

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.

[sirsinsalot]

> 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.

[Chris2048]

> Nobody on my teams would say I micromanage them

Perhaps that's b/c you are apparently in a position to get rid of people who "go AWOL" despite maintaining "a large degree of autonomy".

If autonomy is prefixed on "within a framework of shared goals and shared values" then why do you think individuals can't do work based on their own conception of those shared goals/values, rather than requiring signoff first? Autonomy is being able to make (and execute) decisions on your own (possibly based on shared information/value/etc) - requiring signoff is not autonomy, it's merely the ability to participate in decision making.

[sirsinsalot]

There really shouldn't be an issue getting work approved and visible to the whole team (if anything for team input, collaboration, opportunities for others to object).

If you're working for the benefit of the product/team I don't see why you would need to, or have an issue with this.

Strange.

[Chris2048]

> team input, collaboration, opportunities for others to object

You don't always need a ticket for this, if it applies at all. I'm not unaware of these benefits, but the burden lies with you to demonstrate devs cannot be trusted to be autonomous, or choose the appropriate mode of collaboration.

> getting work approved

Why is this always needed?

> If you're working for the benefit

This is a strawman, you can do this without the overhead.

Who do the approvers seek approval from, for the same reason(s), and who do they seek approval from?

> visible to the whole team

This is what standup / status updates are for. It takes all of a few seconds, no approvals needed.