Are 10% of developer really "ghost engineers" who pretend to work? Are engineers in big tech just lazy? Do Stanford MBAs just need to be stopped?*Chapters*0:...
Release management for our devs is tagging repos (automated), making a few PRs (mostly automated), and informing other dev teams of the release. Product owners update their docs, support updates theirs, and project manager coordinates everything.
My involvement in the release is limited to actual dev tasks, as in tracking down logs if there’s a bug or something during deployment. Total time for a release deploy (my end) is about an hour, two if things go poorly. We release 5-10 repos in a typical release, so it’s not small.
We don’t have the same team doing every release, we take turns. So I’ll do a release about once a month (usually a release release then one or two hotfix releases), and we do a major release every month (we’re doing #12 next week). Most of the release process is on our QA team, not devs.
If you have “developers” who aren’t developing, you’ve hired the wrong people IMO. Here are some support roles we have:
architecture - currently two people; they give initial estimates to product team
QA - they do development, but only on tests (role = “QA engineer”)
scrum master - no development, just tracking (releases, features, etc); they’re the ones product and support talk to about capacity
project manager - cross team communication with scrum masters and product team
As a lead dev (we have one per team), I step in to keep projects on track, provide estimates, and help prioritize tech debt. If I’m available (I usually am), I’ll take feature work, and I produce code at about half capacity vs our regular devs (i.e. non-junior). Our releases are usually on-time (within a week or two on a 2-3 month estimate), so I think our setup works pretty well.
When I worked at a smaller company (one dev team, no project manager or scrum master), we didn’t hit targets as well, and I did even less “admin” work (my boss was the CEO and he handled everything… poorly). We had a QA team, but the devs wrote the tests instead of the QAs, which we started on after handing the release to QA for verification (took 1-2 weeks due to long term tests).
So on both ends of that spectrum, I did a lot of development as a lead. I do less now than my last role, but I still spent about half or more of my time writing code.
We have devOPs for that.
Release management for our devs is tagging repos (automated), making a few PRs (mostly automated), and informing other dev teams of the release. Product owners update their docs, support updates theirs, and project manager coordinates everything.
My involvement in the release is limited to actual dev tasks, as in tracking down logs if there’s a bug or something during deployment. Total time for a release deploy (my end) is about an hour, two if things go poorly. We release 5-10 repos in a typical release, so it’s not small.
We don’t have the same team doing every release, we take turns. So I’ll do a release about once a month (usually a release release then one or two hotfix releases), and we do a major release every month (we’re doing #12 next week). Most of the release process is on our QA team, not devs.
If you have “developers” who aren’t developing, you’ve hired the wrong people IMO. Here are some support roles we have:
As a lead dev (we have one per team), I step in to keep projects on track, provide estimates, and help prioritize tech debt. If I’m available (I usually am), I’ll take feature work, and I produce code at about half capacity vs our regular devs (i.e. non-junior). Our releases are usually on-time (within a week or two on a 2-3 month estimate), so I think our setup works pretty well.
When I worked at a smaller company (one dev team, no project manager or scrum master), we didn’t hit targets as well, and I did even less “admin” work (my boss was the CEO and he handled everything… poorly). We had a QA team, but the devs wrote the tests instead of the QAs, which we started on after handing the release to QA for verification (took 1-2 weeks due to long term tests).
So on both ends of that spectrum, I did a lot of development as a lead. I do less now than my last role, but I still spent about half or more of my time writing code.