[cellularmitosis]

Setting aside your own time for learning and your own agenda is so crucial. The sad reality is that most orgs which run on a ticket/sprint process will make room for nothing outside of tickets.

Looking back at my previous gig, the biggest mistake we consistently made (but were somehow impotent to correct), was assuming that all of the “we should”’s which came out of post-mortems or brainstorming sessions would somehow get done. In reality, if it doesn’t become a ticket, it won’t get done.

Here’s the rub: in many orgs, there is simply too much resistance to getting engineering-centric tickets injected into a product-owned ticket pipeline. They are either outright rejected, or deprioritized to the point of being a “soft no”.

If you are in this situation, my advice is to take a risk and simply stop asking for permission to do the self-development and engineering-centric tasks which you think are important. Set aside regular time for yourself (without asking for it), track your own private backlog, and just do it.

This was the biggest change in my ability to deliver impact: realizing that I wouldn’t be given permission to get these things accomplished, and would have to bear the risk myself and just do it.

Worst-case scenario, this won’t be tolerated and you’ll be fired. Good.

[kqr]

This is very insightful. The higher the level you want to perform on, the more responsibility you have to bear yourself. Asking for permission is really asking for someone else to take the risk, the blame, and therefore the responsibility. That only works up to a point, and you will have to get used to shouldering more and more responsibility on your own initiative to truly get anywhere.

[Stronico]

Asking someone else to take a risk is a very good insight.

[james_s_tayler]

Our org was very much like this. Just couldn't get engineering specific tickets done at any meaningful velocity in such a product driven pipeline. It has finally changed with the introduction of an Architecture Practice Group where we do long term strategic planning across the engineering organization and a dedicated platform team who work on implementing the outputs of the practice group.

Finally feels like we're actually getting somewhere!

[wool_gather]

I'm just coming around to this position after a long period of frustration, and this anecdote is encouraging; thanks!

[celticmusic]

> The sad reality is that most orgs which run on a ticket/sprint process will make room for nothing outside of tickets.

I actively try to stay away from this for this reason. I understand that these ticketing systems are used for coordination and communication, but there's a downside to going all in on them.