Tonka Truck
I like to think I’m a decent programmer with many lessons learned. Staff Engineer, 10YoE, Go, Java+Spring, DevOps, and Security (OWASP ASVS/Top10).
Shift security so far left, my product owner talks a little AppSec.
- 0 Posts
- 1 Comment
Joined 1 year ago
Cake day: June 7th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
(Context about me: I’ve only worked at companies with larger engineering department and mainly in a lead engineer role)
It depends on how miscellaneous it is and how long it’s going to take to achieve.
If it’s small enough, a member of the team will just do it, no ticket (or even make a ticket after the fact, if it was a little bigger than ‘small’). Is it potentially uncaptured work, yes. Which is where the emphasis on this is small. Like a update to a dockerfile where we’re incrementing to the next major update for the base image of an application that we don’t touch that often. 99/100 there’s nothing that goes wrong and it’s 5 minutes of effort including the Merge into main.
Which if something goes wrong, we revert, make sure all’s good and then probably make a ticket. Which leads us into …
If it’s not a small task, that’s where my team figures if it has any sort of business impact. If so, we can talk to our product owner on why this task matters and the priority of it. Maybe it melds into an existing epic as a ‘rider’ feature. Which, to your point about:
Perfection, is the enemy of getting things done. However, if the task starts to get large enough then maybe it warrants its own epic. I personally think that any form of “method of getting work done” (i.e. Scrum Agile) should have an exception process for it’s normal ways of handling things. The exceptions are there to be used on occasion, but not abused. Where that line in the sand is … that takes a team with good feedback loops on how we feel about our process (i.e. retros). Then you adjust that line in the sand with the push and pull of work life.
However, I did mention business impact, because my team also keeps a separate ‘log’ of tasks that are tech-debt only. My Leadership and team value taking ~10% of our capacity and put it towards tech debt items each sprint. So that’s usually where we end up putting things where we, engineers, want to get things done without having to wait for prioritization by our product owner whether or not it has that “direct business impact”.
Regardless if this was helpful, best of luck.