Yeah you can click on the grey to get clues. You aren’t the first to have missed that unfort
587 karma · joined December 21, 2011
This comes off as just a rant against the boogyman fed which prints money and creates inflation.
"‘For the book's illustrations, Watterson and caricaturist John Kascht worked together for several years in unusually close collaboration. Both artists abandoned their past ways of working, inventing images together that neither could anticipate—a mysterious process in its own right.’"
- Management 3.0: Leading Agile Developers, Developing Agile Leaders (pushes a team-first approach that I think supports and reinforces the core concepts of agile )
If success isn’t defined and these paths are left to individuals, then it seems like you have a problem with project scope and product management.
The other month I logged in to view them as I do every so often and yahoo had purged the entire archive. Like 20MB worth of emails gone.
Apparently they have a policy if you do not log in in a year of time they will delete everything with no way to recover.
I can’t imagine the decision making to put this policy in nor could I ever imagine using yahoo email again for any purpose whatsoever.
Looking for People Manager / Tech Lead. Golang / Typescript / AWS experience preferred.
We aim to foster an Engineering culture that emphasizes full-stack development teams that are empowered to make as many decisions as possible in their technical direction and processes.
https://jobs.lever.co/theguarantors/b404a57e-99de-4b5f-987e-...
You just nailed the problem here. If the process is set up that an engineer cannot create / prioritize / close trivial tickets themselves, that is indeed true friction.
Is there already a ticket and are you working to update the app? Then update the documentation. No ticket necessary.
Are you redoing the whole set of docs to make the steps for new engineers to create their stack? Then please lets have a ticket to define the scope and audience.
Trust me that I do understand that there are many orgs that have arbitrary hurdles in place, like who can create / prioritize a ticket. My experience is, if engineers are empowered / encouraged to create and prioritize their own tickets, then its not a hurdle at all.
That said, I dont want an engineer spending days on a task that will not bring value, nor do I want work done that will fall through the cracks, or have duplicate work done.
Asking an engineer to create a ticket to create documentation is not the hurdle you think it is.
Especially since Im pushing for engineers being able to create quick ad-hoc tickets within 30 seconds.
Which is doubly important to really understand the vision of agile / scrum, and not just follow the ceremonies by the book.
Do you want an engineer every standup saying 'im working on documentation' without any accountability?
You are exactly right, that much of what Im pushing is the vision of what Agile / Scrum is supposed to facilitate, and what the benefits can look like if done correctly.
The danger of having a ticketless fix is, you end up with PRs that are not on anyone's plate to fix.
The nice thing about tickets is that it creates a clear line of succession for adding value. If done properly, you will not have anything fall through the cracks. The cost for this is, you need to create tickets.
Reduce the friction to as close to 0 to create a ticket, and you can net all the benefits of tickets without a lot of cost.
The situation Ill describe as a good place to work is, you have tickets that are created (by engineers / product / business whoever) that are evaluated ahead of time, and the team determines if it will add value to the business /end user, scoped appropriately, and set up for success with timeline and work.
As many decisions as possible should be made by the team doing the work, and they should be empowered to change their process as necessary.
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'
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.
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?
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.