[carlisle_]

Great insight, my key takeaway is this:

> The fewer people you need to make decisions, the faster you can make them.

This is the only way I’ve seen a “rockstar” or “10x” get stuff done as fast as they do. They only have to talk to a couple of people at most to start making big changes. The more large and stable a company gets, the more they seem to want to spread decision making power around the org. This appears to be very counterproductive, and it’s nice to see the simple truth called out.

[nickjj]

This is really it.

There's a world of a difference in what you can do if you have free reign to make most technical decisions with full autonomy (self guided R&D, picking stuff, spiking it out, doing it for real, etc.), perhaps only reporting back weekly outcomes to a CTO and also asking their advice as needed to align on big picture goals while nothing is ever blocked.

vs.

Most decisions needs to go through someone else, which then turns into an adhoc request for another department which then has to ticket it out and implement things on their schedule. They could be a great team and do everything in the best way you can realistically hope for but before you know it, things that were literally 1 or 2 hours of dev time end up taking 3-4 weeks simply because they have other things going on too. You keep repeating this pattern and it's how something ends up taking 6 months instead of 2 weeks. It's also one of the most frustrating things to be blocked. It forces you to context switch between many things to keep yourself busy. You spend all of your time reacting to eventually getting unblocked in an uncontrolled way instead of just sitting down and cranking it out. That means you might have to jump back into something you worked on 2 weeks ago and re-get all of that context back in your head.

I know in an Agile sense every team should be self sustained and can own their work from beginning to end but from an infrastructure perspective you may run into scenarios where you need resources created by another team because in a bigger org it's company policy. The blockers could be a combo of waiting on that other team or waiting until multiple people sign off on moving forward with XYZ tech.

[altacc]

One of the reasons enterprise organisations are so slow to adapt and release new products is the number of people needed to make a decision. I've seen large companies try to implement agile and it generally fails because they can't shift to quick & effective decision making processes. Greenfield projects that get developed quickly due to independence and have great promise for the future get the hug of death as soon as management decides to bring the project into the same decision making as the rest of the org.

[salmonfalls]

This is the exact case that I have been in the last two years or so. As a greenfield project being one of the first in the newly implemented Agile work. Everything was amazing in the beginnig with quick decision making. However as soon as we 'went live' and were forced into the established change control workflow development grinded to a halt. We now implement features at a snails pace compared to before.

[azemetre]

I feel this in my soul, I'm not even allowed to update internal documentation in our repo without linking it to a JIRA ticket.

[mr-ron]

I mean, thats pretty normal for any stage tech organization.

The question is, who gets the right to create a jira ticket? Maybe you can do it, or just one other person. Thats not a big limitation at all to moving quick.

Edit because this is causing a stir:

Engineers within teams should have the right to create tickets themselves. Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds. Updating documentation may require a pull request. Controls (SOC compliance) may require that work is tracked to tickets.

The core questions I have is, who can create the tickets, and how detailed do they need to be?

[azemetre]

I disagree with it moving quickly, all it does is encourage me to not update documentation and not actively improve the code in other ways due to inane bureaucracy. And surprised surprise, no on else on the team wants to document anything either; people get burnt out because they have no autonomy and just leave.

All is good tho! We followed the process and that's the only thing that matters.

I wonder what the corporate equivalent to "I was just following orders" is?

[mr-ron]

If an engineer can create a ticket and work on it, thats not reducing autonomy. Thats adding accountability.

If documentation requires a pull request / merge to update, often you have set controls that require a jira ticket. Its super common to not allow engineers to make solo commits without a pull request.

If an engineer sees the creation of a jira ticket as a limitation, or if they are not empowered to create their own tickets, then Id agree its a problem.

[lostdog]

That ticket is just adding friction to getting things done. Why can't you track the pull request itself?

This one instance of friction might but seem like a big deal at first, but the attitude is what causes slow development and burnout. First there's this tiny process, and then why not add a few more bita of process on top, until finally your merge process takes longer than writing the updated documentation, and so people stop doing it.

Instead of asking "why can't you just do this process," you should be asking "why is this process necessary at all?"

[mr-ron]

Imagine the inverse where you have a team of engineers working on their own projects. And you dont know who is working on what, or why. Because there is no pull request yet.

Who requested this change? What is the scope? Where is the upfront documentation?

Now imagine the PR is ready to be merged. Since the engineer doesnt like documentation (as you are suggesting) then theres little context into what this is doing, who it will affect, and what types of changes can be expected.

Now imagine those PRs create a bug and causes an outage. Where do you look to determine the context into why this decision was made?

Now imagine a dozen of these teams working on the same repo. How do you coordinate who is working on what and what types of releases need to be schedueled?

[carlisle_]

Is creating the ticket really adding value to the engineering process? In your example you already have the engineer making a PR (presumably peer reviewed) and a commit, what’s the ticket really needed for?

[mr-ron]

It can add value if done right. Just as you typically want to make a design doc / rfc before working on a project, you often want to describe what you are doing before you do it.

This can protect the engineer / team against scope creep, as well as determine the context of why work was done when you may need to understand more context (in the case of a bug for example).

Also it increases accountability and transparency. It is common that teams want to know what other engineers are working on and why.

[treis]

It's not a lot of value but it's also not a lot of effort. At minimum it gives a little bit of visibility into what you're doing and why to the rest of the team. That's probably worth the 2 minutes it takes to create a ticket.

[notyourwork]

What is normal about this? Engineers should be empowered with ownership. Adding. friction or barriers to enabling engineers to make what they own better is backwards and counter productive at best. At worst, it discourages proactive willingness to make an improvement.

[nix0n]

If it's in a repo, it's normal to need a PR to change it. And, it's normal for a PR to need a ticket.

Alternatives to creating a new ticket could be:

1) Link to the ticket number that was used, for creating whatever you're documenting now. Use the "blame" report.

2) Link it to a catch-all ticket for documentation or code quality. Look in your ticket system for a low ticket number, with recent activity. If this doesn't already exist, and you really do need to make a new ticket, write it as generally as possible to enable this style of reuse.

[eropple]

> If it's in a repo, it's normal to need a PR to change it. And, it's normal for a PR to need a ticket.

In my experience, the former is true but the latter is extremely not.

Tickets are for tracking concerns for stakeholders. A documentation fix, to use the example at hand, is an ad-hoc improvement for customers/consumers and should have as little in the way of it as possible.

[docmechanic]

It is standard practice for technical writing teams to link a ticket to all pull requests. Writers, like developers, typically work on multiple pull requests in the same sprint.

If you're not familiar with Docs As Code, I highly recommend giving this a look for some of the current trends and ideas circulating among the technical writing community: https://www.writethedocs.org/guide/docs-as-code/

An example: would a developer publish code without knowing what ticket relates to that code? Nope. Same with current crop of technical writers.

[mr-ron]

Those ad-hoc doc updates are the exception vs the norm.

It is also common to have controls in github, where its required for a jira ticket to be attached to a PR.

In that situation. Its literally impossible to merge into the codebase without a ticket.

Again it comes down to 'who can create the ticket' and 'what is the required scope of the ticket'

[mikevin]

That's assuming a lot about the work environment. If your have a team full of professionals, trusted by stakeholders then you don't need any of that.

If my teammember decides documentation needs updating he should go ahead and update it. Tickets and PRs are for thing that need planning and reviewing. I trust my colleagues to know when that is the case and decide accordingly. If any of us messes up we talk about it and improve.

In reality this means that many, if not most, things still get tickets / PRs because it helps but the fact that it's not simple ceremony makes sure everyone knows their importance and saves time when they aren't needed.

[sanderjd]

> And, it's normal for a PR to need a ticket.

Why?

[icedchai]

Some orgs have strict change control processes. "Why is this change happening? What is it supposed to do?" At one place, I used to just submit my own ticket,a assign it to myself, then open a PR linked to it. Totally pointless. At some other companies, it's more open. "We trust you! Just get it done." There is more risk, but it's a better environment for some. Possibly not for all.

[mr-ron]

What is normal about this that Ive seen is work and tickets is often written into controls that are required for things like SOC compliance. And documentation often requires a pull request.

And again read what I said, that engineers can and could be empowered to make these tickets, which can be minimal at best.

Done right, its not a limitation at all, and instead adds accountability.

[knightofmars]

"...things like SOC compliance." This is an important point. If you work in a regulated industry or work with software used in a regulated industry you need a "paper trail". Having to document and follow a process is often frustrating to people who work or have worked in industries that don't require it. That said, a poorly implemented process in a regulated industry is even worse. As you're overloading teams with busy work and likely still failing to meet the requirements of the regulations you're following. Regulated software is not a place to "move fast and break things" that's what prototypes that never see the light of production are for. Build it without regulation to figure out how to do it and then build it again following the documentation process. It may sound odd but having a second chance to correct errors of assumption from the first time around is quite valuable, buying information when done right is a great tool.

[mr-ron]

SOC compliance is indeed a beast. I have my own theories on how valuable this benchmarks REALLY is, but if teams are in a financial org, it is super common to have controls that have the potential to really hamstring teams.

Which is doubly important to really understand the vision of agile / scrum, and not just follow the ceremonies by the book.

[eropple]

> Done right, its not a limitation at all

Context switches are limiters, IME. Smash somebody's stack and you've made them useless for half an hour.

[mr-ron]

This is why tickets can be used to protect the engineering team. You dont want people ad-hoc adding scope, or interrupting work for engineers.

You want engineers to have focus time, on a clear actionable item, that is set up for success, and will add value.

Allowing engineers to work on whatever they want, or change scope on what they want, without saying 'why', can end up creating a lot of wasted work.

[ozim]

Even not SOC compliance just liability of a company.

If stuff fails and company gets sued - they will have to prove that they "follow industry standards" because if they don't follow industry standards then all kinds of bad stuff can follow.

IF you get ransom-ware and have an insurance - see the exclusions - you have to have EDR software on each server otherwise insurance won't pay.

Not following industry standards in terms of code - the same no insurance company will pay if they catch you on just doing stuff.

So running a business all kind of BS and it is not optional and just slinging out code is not enough.

[whynotmaybe]

You find it normal that you need a Jira ticket to update documentation?

If while reading a document, you find a mistake, instead of changing it, the normal reflex is to create a Jira ticket?

[timmytokyo]

I find this whole back-and-forth fascinating, because it mirrors my experiences in the workplace. There are some people who really like process around everything an engineer does, and some people who really don't like it. They're almost two distinct personality types, and it's virtually impossible to get them to agree because it's like asking someone to change their personality.

I happen to be one of the types who dislikes heavy process-oriented project management, and reading mr-ron's responses is admittedly making my blood boil. But I bet he reads some of the responses to his remarks and probably has similar reactions.

Some people thrive with heavy process, and some people wither. Some people thrive with light-weight process, and some people wither. I don't know how to structure an organization to support both types of people in it, but it's not an easy problem to solve. That's why there are so many project management methodologies, with new ones popping up every few years and then inevitably disappearing in favor of something new and better.

[synu]

I think the solution is to do everything you can to keep the heavy process people away from anything important for as long as possible, before you get too big and they manage to embed themselves anyway, where they will commence to expand the bureaucracy to meet the needs of the expanding bureaucracy.

[zero_]

Reading this thread reminded about "Bullshit Jobs (https://en.wikipedia.org/wiki/Bullshit_Jobs)

[seadan83]

What a great comment! The whole, every change needs a ticket debate is interesting but without context. Some orgs require it and you can just create a ticket and move on. Fundamentally I don't view these tickets as useful, if asked "tell me the latest state of X", or "why was Y done", the tickets rarely help (and if they do, the proper places of commit history or the code itself skimp on these)

The tickets can often go on to be "for the devs we like and trust, they can cut tickets", but for the others we require they're prioritized. This creates a lot of chafing, that quick bug fix, is it worth context switching now to create a ticket, again later to explain it to the non-technical prioritizer of tickets, worth the argument of why a "business goal" should be deferred to prioritize this ticket, the tracking overhead to finally say you are selecting ticket X, and that final context switch to actually work on it? All that compared to just fixing it, switching branch and cutting a pull request a minute later

I found I liked tickets to identify product work, so maybe 5% of my commits actually reference tickets, the rest are supporting changes that enabled that 5% to be done cleanly or are just things that should be fixed or cleaned. Coming back to it, tickets have their uses: documentation, discussion, prioritizing. But tickets can quickly turn into "this is how we keep our engineers from cleaning up the code, etc", "this is how we do programming by remote and control exactly what is worked on." Worst, it is the self inflicted burning the midnight oil, "hey, you said this was going to take a week, estimation is a skill of a senior engineer - will this be done as promised, or is your ability to estimate not there yet? Wink, the sprint is over on Monday.."

[mr-ron]

Im not sure why you are describing my example of PRs needing tickets to be 'heavy process'.

Especially since Im pushing for engineers being able to create quick ad-hoc tickets within 30 seconds.

[doix]

FWIW, I agree with timmytokyo's assessment of 'heavy process'. I actually worked in a place where PR's need to be tied to tickets and updating documentation is the perfect example of where it sucks. Imagine you're trying to debug a bug, looking through the stack trace and trying to reverse engineer what the heck is going on. You find a block comment explaining what should be happening, but it's not been updated in years and not technically relevant to the final bug fix.

You've got two choices, either you sneak the comment block change into your PR, despite it being irrelevant and make the documentation update blocked by the bugfix/feature. Or you need to open Jira, make a ticket etc etc. I know you say it's 30 seconds, but it's not. It's at least two minutes, but it's not even the time that makes it annoying. It's the fact that you're doing something that you(the people timmytokyo describes) think is entirely pointless.

I ended up writing a janky git hook that would check if the branch name I was pushing had a jira-id in it, and if it didn't it would use the Jira API to make the ticket, grab the id and push the branch again with the id in the branch name. The fact that the entire thing can be automated, makes the entire thing pointless in my mind.

The thread gives me very strong vim vs emacs vibes :).

[timmytokyo]

It feels heavy to me, because you're asking for a process gate to be put in front of something that is so trivial. It feels utterly unnecessary and demotivating. If I see a minor problem in the documentation and decide to correct it, now I have to go through an extra step of creating a JIRA ticket describing the minor problem I'm trying to solve, doing the correction, updating the JIRA ticket status, and possibly monitoring the ticket for future issues. It's. all. so. bureaucratic. And sadly it will probably lead me to thinking the fix is not worth my time.

Instead of trying to convince everyone that they should feel the way you do, maybe try to understand why others feel the way they do.

[synu]

It’s not really 30 seconds though is it, if everyone is making all these tickets to do trivial things, they are getting update emails on them whenever their micromanager gets around to acknowledging them. It’s generating all the work for people to look at all these trivial tickets. You already have a source of truth on what changed - the PR. Forcing a fellow human to make a ticket that is just a link to a PR is Kafkaesque regardless of whether you “empower” your engineer to open and then immediately close her pointless tickets on her own or not.

[mikevin]

A ticket supposedly represents some worthwhile task that's worth specifying. If it takes just 30 seconds to create it can't possibly concern a task that's worth the cost of involving ceremony/process.

[sanderjd]

Because it is heavy process.

[beardedetim]

> If while reading a document, you find a mistake, instead of changing it, the normal reflex is to create a Jira ticket?

I would say the first reaction is to create the PR to make the fix. Then, while CI is running, I create the JIRA ticket and update the PR description to point. Best of both worlds!

[sanderjd]

Busywork is not a virtue.

[mr-ron]

It depends on the documentation. Is it within a repo? Does it require a pull request? Is it a quick edit, or is this a multi hour effort that is redoing the scope?

[RayFrankenstein]

Cute Agilist gaslighting about not needing a ticket because that’s “asking for permission” and it’s supposed to be implicitly bundled into feature work.

[Too]

”Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds”

This type of placeholder-documentation is literally the WORST type of tracking you can have. And a sign that everybody in your company forgot the reason why this type of traceability was implemented in the first place.

If I review a PR that links to a Jira ticket that says absolutely nothing except “update documentation”. What’s the whole point?!

What’s worse is when people see a link to a Jira as an excuse to write bad commit messages.

I would much rather read a commit message detailing out the background and rationale of the change, rather than a nonsense commit message linking to another nonsense kpi-chasing Jira ticket.

PRs are code reviewed anyway so it’s not like you have a bonanza of unknown changes being pushed left and right. Code reviews not only catches coding bugs but also accountability within the team, eg “why are you refactoring something that works, when our backlog has 100 other more important things to do.”

[ianbutler]

Is it? I've never needed a ticket to make off the cuff improvements. A PR and a review from other engs to make sure they agree, certainly, but a ticket for that seems like a certain degree of dev micromanagement/big brother/power trip for highly paid and skilled professionals.

[Rapzid]

At my previous gig we reduced the friction for doc contributions to just a PR but with no review requirement; if the contributor felt the need for feedback or review they would seek it, otherwise just merge the changes.

[sanderjd]

That's a stupid compliance requirement, unless documentation changes aren't themselves versioned (which they should be). You don't need to track the exact same thing in two separate places.

[lupire]

If it's so important to have a ticket, the patch submission pipeline should create one automatically.

[lifeplusplus]

In my past job, I volunteered and pushed to get the whole project, then I asked to be exempted from all scrum stuff, then got really close to PM and Designer, launched the whole thing without a single bug in 3 months and with more features than planned, and had 2 more months left.

The reason there were no bugs was because any question I had, I slacked messaged PM, and got replied in less than a minute. She was on the project full time too, and was technical so was able to test out things and apis, document correct relevant data like console log errors, browser version, json response, curl ... etc.

My takeaway was similar to yours but in more concrete terms:

- have experts available in team which can be consulted asap - give whole projects - start with minimal project - create small informal groups, POC for each area: sr eng for legacy code, designer to get artifacts, PM to clarify tickets and address new bugs, main dev to do the whole thing - have team informally occasionally input on tech decisions.

[rco8786]

> I t’s nice to see the simple truth called out.

It’s not as though it’s a secret or anything. It’s a common point of discussion. The simple matter is that big co’s naturally have more inputs into the same types of decisions and thus need more people involved.

[jeffbee]

I don't think it's about largeness, and the autonomy of "rockstars" is of dubious value. Google is the largest company where I've worked, and also the most productive. For code that an IC owns, they only need the sign-off of literally anyone else in the company to land changes, and all that is expected is those changes are generally consistent with team goals. For code an IC does not own, they only need the approval of one owner. Pretty straight-forward.

A medium-sized company where I worked had a "rockstar" who was really just an early employee with a high title and no idea what he was doing, so every week he committed a thousand lines of brand-new unreviewed tech debt. Much of the rest of the company was unwittingly dedicated to overcoming his tech debt. Said company currently trades at about 1/3rd below its IPO valuation.

The experience of these two companies led me to the belief that hiring practices and review culture are more important than project management culture. You can get a lot done with good talent, code and design review, and vaguely disorganized project leadership, and you can run in place achieving nothing with formal project management hamstrung by bozo engineers.

[carlisle_]

> and the autonomy of "rockstars" is of dubious value.

I agree, but with your example, I wouldn’t call somebody committing massive amounts of tech debt a “rock star”. I used the term fairly facetiously anyway, because I think we all know the 10x engineer is a myth.

[duxup]

“Jim is so productive!”

-by design Jim is the only one allowed to be productive-

:P

[sanderjd]

Yeah this is exactly it. But I think it's a good thing. It's a tradeoff between productivity and risk. It is productive but risky for "rockstars" to make big changes with very little consensus-seeking. Big changes are double edged, they have outsize impact, but it may be either positive or negative. So organizations rationally hedge that. The trick is to strike a good balance, giving up as little productivity as possible for the greatest reduction in risk. It's hard! Sometimes the right answer is just "empower one or a few people to do whatever they think best without ever seeking any buy in from anyone else", but not often. And "never let anyone do anything without a big slow sprawling committee giving permission" is essentially never the right answer. But there is lots of space in between these extremes!

[tgv]

Such is the nature of organisations. E.g., X is the boss of a group, the group becomes a department, X hires people to manage the groups in the department, and now all these people have to be informed as well, and of course they have an opinion, too. And they are rarely good managers. Then X leaves and politics kick in because everyone covets the position, and then someone's simple task becomes the focus of someone who wants to place your manager in a bad light. And it never stops, because there's no incentive to make it stop.

[lupire]

Your 10x rockstar is my cowboy coder 0.1xing the team.

[carlisle_]

The use of the term was supposed to be illustrative and mostly facetious, hence the quotes.