[sanderjd]

Why does my team need to know that I spent two minutes fixing typos in engineering documentation? Also, if they do want to know this, they can subscribe to the changes being made to the documentation repository / system and then they'll see what I did.

Is this really for visibility within my team? Or is it for some kind of external visibility?

[treis]

>Is this really for visibility within my team? Or is it for some kind of external visibility?

Both.

>Why does my team need to know that I spent two minutes fixing typos in engineering documentation?

Nobody said typos.

>Also, if they do want to know this, they can subscribe to the changes being made to the documentation repository / system and then they'll see what I did.

How is that more efficient than you taking 30 seconds to write a ticket and 15 seconds to talk about it on stand up?

If it was important enough to go update the docs why isn't it worth the 1 minute to tell your teammates about it?

[sanderjd]

Nobody outside the team needs a single iota of visibility into my efforts to keep our internal documentation tidy. Anyone who is keeping tabs on this is wasting their time and needs to find something useful to do.

> Nobody said typos.

The claim in this thread is that a ticket is necessary for all changes, and fixing typos is a change.

> How is that more efficient than you taking 30 seconds to write a ticket and 15 seconds to talk about it on stand up?

I'm so confused. The "that" here is making the change itself vs. making the change itself and doing two other things. The way it's more efficient is that you do just the one thing, instead of that one thing and also two other things. Maybe I don't understand your question...

[treis]

>Nobody outside the team needs a single iota of visibility into my efforts to keep our internal documentation tidy. Anyone who is keeping tabs on this is wasting their time and needs to find something useful to do.

This is naive. Someone above your team is superficially watching how much work your team does. If you don't document it then it doesn't get counted. You want it to get counted if you care about promotions and raises.

>The claim in this thread is that a ticket is necessary for all changes, and fixing typos is a change.

Not in this thread. The original complaint is opening a ticket for updating internal documentation.

>The "that" here is making the change itself vs. making the change itself and doing two other things.

No, the "that" is watching a repo instead of you taking a tiny amount of to tell the team you wrote some documentation.

[sanderjd]

> This is naive. Someone above your team is superficially watching how much work your team does.

It is not naive. Top down micromanagement is certainly common but it isn't inevitable. I have worked in multiple businesses with healthier management cultures. I'm sorry if you haven't.

> The original complaint is opening a ticket for updating internal documentation.

Yes, the rebuttal to which was "that's stupid don't do that" to which the claim was "it's normal to require tickets for every change", which is what I said the claim is. I wouldn't be pushing back on a claim like "nearly every change requires a ticket, but not minor edits to documentation like fixing typos". But that's not what people are advocating here.

> No, the "that" is watching a repo instead of you taking a tiny amount of to tell the team you wrote some documentation.

What thing are you saying is "telling the team"? Filing the ticket? So the team is subscribed to the feed of new tickets then? Why not just be subscribed to the feed of new changes to the repo? What do you see as the difference between those two things? Or is "telling the team" the standup status update about it? In that case, can't I tell them about the change I made directly? How does having a ticket help?

[treis]

>It is not naive. Top down micromanagement is certainly common but it isn't inevitable. I have worked in multiple businesses with healthier management cultures. I'm sorry if you haven't.

Again with the unjustifiable leap to an extreme. Nobody said micromanage.

> So the team is subscribed to the feed of new tickets then

Yes. Scrum teams do a quick rundown of the board on standup. That's your opportunity to tell them what you did and why.

[sanderjd]

What you are describing is micromanagement. It is not necessary for you to say that's what it is, nobody ever thinks what they are doing or that what they favor is micromanagement, and yet that's what lots of people are doing. And that's what you're describing.

> Scrum teams do a quick rundown of the board on standup.

This is a major anti-pattern! What's funny is that other people I've been debating with in these threads have made the point that stand-ups aren't so bad because it isn't about status reporting, it's just a really quick get together ritual. And yet this is what lots of teams actually do, pull up the sprint backlog and have a planning meeting every single day.

What you're describing is a micromanaged process of very dubious value. I recognize that this is what lots of organizations do, but (to circle back to the article) it is very much the opposite of what companies like Google do, and not because they don't have tons of compliance and auditing requirements; they do.