Writing About Managing

Management is mostly just charts like this, btw

I made the transition to software engineering management a few years ago after something like 15 years of doing some sort of software development work. I didn’t ask for the transition — A new VP was hired at my company, and they wanted a structure with more managers closer to the projects they were working. I was working in a team lead/architect capacity at the time, and so the transition was fairly obvious.

I’ve since managed several teams, at that company and now a new startup. I still program, even for my team, albeit less often. I’ve picked up some lessons on management during this time that I’ve learned from mistakes I’ve made and nearly made, and successes I’ve had, and nearly had. I figured I should write some of them down to share some of this with my future self who may have forgotten, and with anyone else that ends up stumbling across this blog. Hopefully we can all find this helpful.

It should also get me to start writing again, which I’ve obviously stopped doing for the past few years. My last company made it pretty clear when I was hired that they didn’t want to be mentioned, or to have me mention anything I was working on, for fear that it would be like they were recommending what I was saying. I’ve never mentioned them, but it’s hard to not write about the stuff you do 8 hours a day. So I just slowly stopped writing, because it was hard and I didn’t want to.

That being said, I’m in a new position now, and I have found a vigor for writing blog posts again. I have a series of topics around engineering management that I wrote titles for, which means that I at least have an idea that I want to talk about, so I think they’ll get written down eventually. It’ll all be my perspective on problem solving and how to manage a team, which I give no guarantee of correctness on. Hopefully this is fun.

Add a Comment

Your email address will not be published. Required fields are marked *