I think having the background in development makes things much easier, as you’ll actually understand what’s going on. My current scrum master has no idea what we’re talking about and can’t speak to anything we’re doing, which is a problem.

My biggest piece of advice in a role like that is to show up to meetings prepared. Starting a meeting with an empty sheet often ends with an empty sheet. Spending the time to put together some kind of framework to organize thoughts, even as a jumping off point, pays dividends. Build systems for the team and eventually things hum along pretty smoothly.

I ended up switching back into a dev role. While the team was considered successful, and the team members seemed happy, I was miserable. I’m a bit of a perfectionist, which is a burden I’m used to placing on myself, but wasn’t something I felt comfortable pushing on other people, because I know the weight of it. This led me to not give feedback I should have given, or letting work go that was “good enough,” but really should have been better. The work wasn’t up to my standards, and I was accountable for it, even though it wasn’t work I personally did. This slowly drove me mad, even though all external feedback was glowing. This is just a long way to say, know yourself, but also that it may simply take time to adapt and grow into the role. It’s a big mental shift, at least it was for me. Going back has also been a bit rough.

I did find it to be useful to be on that side of the house for a while. It gave me a little more empathy for people in those roles. I was pretty hard on them in the past and have eased up a lot.

Product owner

Project manager

Product manager

Are all wildly different job roles.

Do you want to track and ensure deliver across multiple projects = project management

Do you want to be close support to dev teams and organize backlogs etc. = product owner

Do you want a business role talking to customers and deciding _what to build_ and why (product strategy) and much less focusing on the how to build it part.