> Maybe I just need to be honest with my managers/co-workers and say that I can't focus on my project and I need some quick wins to get back to being productive

> Maybe I just need to be honest with my managers/co-workers and say that I can't focus on my project and I need some quick wins to get back to being productive. You're right; I wouldn't necessarily use those exact words, but back when I was at a large telecom, my entire job was made up of projects that I created while being briefly burned-out on something else (usually on time outside of the 40-hour work-week). The additional upshot is that it often led to great improvements in whatever I was stuck on, because I'd pick a project that had a related design complication/issue where that issue was easier to solve/reason about[0]. My usual approach would be to say "I'm stuck on a few things with this project, but I have some ideas -- I just need to try them out on something simpler, so here's what I'd like to do" and follow with a well reasoned argument that serves more than my own sanity as its benefits. Most of the people I've worked for don't require much in the way of an explanation[1] but a few have been difficult -- but I solved that by changing positions since this only happened to me at the global telecom I worked at (it was also a small factor in my accepting a position at another company[2]). [0] For various reasons -- sometimes it was written in a language that I wasn't familiar enough to understand the more advanced usages of it, sometimes it was just really complex code that I fully understood the design/code behind each of the pieces, just not "as a single thing". [1] With no real correlation between "dev" and "non-dev" managers. I've had non-dev managers that are very receptive because they trust me, and they recognize they don't have the knowledge to challenge my conclusions, and I've had non-dev managers that think manufacturing widgets and writing code are perfect metaphors. I've had dev managers that hear the first part of the argument and say "do what you need to do" and dev managers (usually less experienced) who believe there's no difference between a small CRUD app and a globally distributed, multi-threaded access auditing, requesting and provisioning system. [2] I hesitate to mention it -- the gentleman involved was a fine manager, he just didn't work with any of the technologies that my expertise was in at the time. Over the last decade, I ended up studying the things he had expertise in, and I'd be willing to bet this factor would have gone away, entirely, had I already had this expertise.