[Stronico]

1. Setting aside a "20% day" to develop infrastructure - I went through a slow period about 15 years ago where I had the option of doing this without meaningful tradeoffs and I built some software that I still use to this day. It's tempting to call this a learning, or reading day but I've found that I lose focus if I have a full day to do that - if you decide that you will spend 8 consecutive hours building a personal infrastructure tool (what ever that winds up being) you will have something to show for it at the end of the day - and therefore you will do it again. Those sort of things build upon each other nicely. Tooling/infrastucture is a marathon.

2. Set aside 30-60 minutes a day for learning, however you define it - for me it's PluralSight and Anki - that is usually how I start my day. Having it on the calendar, without many options to choose from makes it very efficient. Learning should be in sprints.

3. Set aside some amount of money every month for tools and capital purchases - targeted savings accounts are perfect for this - having the money in an account targeted for this purpose instead of a general account prevents a lot of money anxiety and allows you to do a better cost-benefit analysis.

[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.