61–70 of 319 posts
I once had a lead programmer (who was a great one) who insisted that a manager should not have access to the source code of our project. I have often worked with engineers who were nervous about who could check in code so I kind of understood. And this really was a great lead, technically strong and a good leader so I said, fine no code access for me. It was a terrible mistake for me. So much of my value as a manager…
Strong yes for 3 reasons 1. Reducing dev friction. When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. If build times went up, deployment infrastructure broke or someone’s PR broke dev they would roll it back immediately. If someone consistently blocks PRs the manager noticed the trend and would address it. 2. You get a much…
Strong yes for 3 reasons 1. Reducing dev friction. When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. If build times went up, deployment infrastructure broke or someone’s PR broke dev they would roll it back immediately. If someone consistently blocks PRs the manager noticed the trend and would address it. 2. You get a much…
This is so important, my managers who didn't code pretended things weren't too bad and took a "just deal with it" attitude whenever I proposed going for a QoL improvement.
> Do code reviews. Don't just skim PRs (sorry, reader!), but really dig into them: run the branch locally, test it, think critically about the design and the implementation, and provide feedback. Record a video of your review to highlight things that could be better. Please no! Most managers want to increase output and engineers are aware of that. It is exceptionally frustrating when your manager tells you during you…
Modulo the video, I did exactly this when I ran a team, only for what I thought were "important" or "gnarly" PRs. It works. I rarely had to spend more than an hour on a PR, because small, atomic PRs were all but mandatory on my team, with "atomic" taking precedence over "small". I would also review some of the PRs post-facto, after they are committed, as I was almost never a "formal"/blocking reviewer on them. Record…
When I've worked as an engineering manager I've found the advice to "stay out of the critical path of getting features into production" to be very helpful. It's difficult to commit to coding timelines as a manager, and it harms your team if you are the bottleneck to shipping something. But... keeping your hands in the mix elsewhere helps you stay informed and make better decisions. I found writing things like interna…
Strong yes for 3 reasons 1. Reducing dev friction. When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. If build times went up, deployment infrastructure broke or someone’s PR broke dev they would roll it back immediately. If someone consistently blocks PRs the manager noticed the trend and would address it. 2. You get a much…
Earlier quoted context omitted.
Managers who didn’t want to be managers are the worse ones. They don’t know how to play politics and compete for resources against other managers and make sure their team gets raises and promotions. The skillset you need for management are different from those you need as an IC
> They don’t know how to play politics and compete for resources against other managers and make sure their team gets raises and promotions. Clearly those are not the skills Steve Jobs valued.
https://research.upjohn.org/cgi/viewcontent.cgi?article=1343...
Earlier quoted context omitted.
Yeah, I've never seen one that checks all that.
I've bounced back and forth between IC and EM (intentionally) and I've seen some that get very very close then completely blow it with one of these. One in particular would put people through management training for a full day each week for months, give them a very senior director, all the "right things" but then cut their IC duties by maybe 10-15% at most and give them a team of 12 people to manage. And they wondere…
Middle management for software engineering has gone through a paradigm shift. The trend for businesses is flatter structures, manager roles with more responsibilities and this reality largely includes being as deep in the code as direct reports. Since 2023, most roles I reviewed or interviewed for were player/coach roles, often close to 50/50 split. In my last EM role, I was hired for exactly this. I found very few E…
One important distinction to make is the difference between a manager who started out as an IC on the project (esp. the case when they actually built the thing from the ground up) versus a manager brought in from the outside. I think the former is more likely to be hands-on and generally speaking the expert in the room. But, sometimes you need the latter. It can be challenging (even counterproductive) for the latter…