> You can't lead developers if you have no clue about developing. Sorry.
I’ve been both a developer and a development manager (and a few other things), and once upon a time I would have agreed wholeheartedly with this.
Then about 10 years ago I started working with the best PM I have ever known. He is absolutely not technical.
He is, however, a great listener, opionated about protecting people from burnout and dumb processes, honest to a fault, and able to speak candidly and openly to techs, devs, execs, and everything in between, switching language as he goes.
On one project we worked on, I had an advisory role and he ran the development sprints. He was amazing at understanding what the devs needed and managing the manager’s unrealistic expectations of how quickly things could be done.
He also put his foot down and insisted that everything flow through him, to be integrated into schedules based on, well, balancing everything else with business priorities.
It took a some time for the devs to trust him, and it took a lot of soft skill work on his part to gain that trust, but before long they realized their weeks were pretty evenly balanced.
The first big win was no more high priority interrupts from the manager, who had to work through him. That helped a lot.
He knows nothing about development, in the sense of having no idea how to do it.
He does know people and knows how understand what they need.
I also have similar experience with people in leadership roles.
My theory is that technical leads have a narrower distribution of quality, while not technical leads vary wildly, from crazy good to nuclear winter bad.
> He also put his foot down and insisted that everything flow through him, to be integrated into schedules based on, well, balancing everything else with business priorities.
This is a mixed bag, it can be truly helpful or a political control structure. All the other personality traits are probably what makes it work.
"Senior developer " is the worst role you can have. You are the architect, manager of your devs, heat shield, meetings attender, and you still full time coding job. You get 2% annual raises for your trouble because you are salary capped.
I jumped ship to a tech lead job. Now I do what I always wanted which is to direct a team (dotted line) by scaffolding out the project using diagrams and shallow coding. Very few soul sucking status meetings. .Dream job and a nice 25% salary boost.
> "Senior developer " is the worst role .... I jumped ship to a tech lead job
At a lot of companies the description you gave for "senior developer" would be described as a tech lead. In many other companies neither example you gave would line up to their terminology. And every possibility in between.
There's not much uniformity in titles and descriptions of roles.
You're describing the role of the tech lead or lead dev, not senior developer... at least not anywhere I've worked or known people who worked. Senior developers is the sweet spot where you get to do a nice bit of architecting and still mainly write code. It's as high as you can usually go in the tech tree without having to deal with the 'manager' stuff you mention.
Really sounds like that last job was just garbage and you moved on to someplace better. Had nothing to do with the position other than it wasn't the lead position you wanted.
Senior developer is such a loaded term that I find it futile to draw any conclusions based on the job title alone. Depending on the shop it can mean anything from "literally not a novice" to "coordinates the architecture between several teams".
In fact I'd encourage to do the opposite, describe the job activities and then map them to whatever mental model you have about dev career ladder.
Grass is always greener. If you’re a team lead, you’re constantly in meetings and never using your creativity skills. If you’re just a coder, you have no say in the architecture. Optimal situation is just be a 1-person lifestyle startup
This really limits my desire to advance as a dev + keeps me leaving companies (as I never want to be the keeper of the expertise). I do not want to deal with meetings.
I think a project manager trying to run agile is almost a contradiction in terms.
Agile is usually a team practise which outsiders like a PM don't get a say in. The Product Owner feeds work in and stakeholders get to argue about the order of each item and that's all.
A retrospective allows the team to adjust their way of working to fit better to their situation and it is them that decide not some PM.
Standups are aimed at killing long status meetings and if they're not then something is wrong. The Ceremonies have a purpose and the overall purpose is to use the development resource that is available to do the things that most need to be done and not waste it on anything else.
To bring this back to the article - how can a project manager decide what is or isn't efficient for some team? How can they estimate anything when they are far from the details - no matter how much programming they did in the past?
> I think a project manager trying to run agile is almost a contradiction in terms.
I believe you can find that "contradiction in terms" at thousands of organizations these days. Probably more than are "running agile" without a "project manager".
You described the point of view of an agile practitioner, leaning towards scrum. Could you contrast it with project manager's role? What's a project manager - a role eliminated by scrum - expected to do?
This resonated with me in so many ways. I frequently use the “garden” analogy and I think developing software efficiently in small teams is absolutely crucial. Society wastes so much time, effort and goodwill on unqualified software project (mis)management.
I have lost two important (to me) jobs because I refused to adopt stupid, inefficient processes handed down by non-technical “managers” who thought they knew how to manage developers better than I did, despite my 30 years of experience.
Reading this almost made me cry. If I could upvote this a thousand times then I would.
This was a great read indeed. I was sort of surprised at the direct attack on 'agile', especially when the author's recommendations at the end could practically have come straight out of agilemanifesto.org.
Seems like the Agile Industrial Complex has twisted the meaning of 'agile' in developers' minds completely out of what the manifesto's authors meant by now.
Seems to be the same story over and over. I am also a senior dev who was was taken in as tech lead which on day one turned in to scrum master but told to keep it light and develop at the same time. Then the team grew and the role became team lead, responsible for organising and team, time lines, deliverabes and recruitment, but I am not a project manager, we don't hire project managers, still need to code as well (fat chance). You get to hate it and start to envy the junior and mid level Devs.
This is exactly my experience. Senior management spent 2 years convinced that 1) we didn't need project managers, and 2) tech leads weren't just glorified project managers besides all of the evidence to the contrary. The messaging was 'we're working out the kinks - it shouldn't take that much time is our processes are being implemented correctly'. I bought in for about 3 months before it became pretty clear that coordinating stakeholders and balancing business and technical requirements was a full-time job. The role became a mess that burned out anyone in it
This was the reason I decided to write this article, I was in a similar position and had to improvise somehow. I didn't find many resources for people transitioning from developer to product/project manager roles.
I think one pragmatic way to approach it is to find an opportunity within your organization to try it out without having too big of an impact at first. This way you can learn what works for your business.
I really believe that product management is not a 100% transferable skill like programming would be, it's more dependent on who and what you are dealing with, hence the lack of general resources adapted to devs. There might be some general guidelines here and there, but in my many interviews this year, I found out that product management at company A can be totally different than at company B.
I'd gladly read some resources if somebody answers your question better than me though!
I'm not sure if there's a great overall guide for this since different employers will expect different things. But you'll make progress if you show interest in not just building, but refining the product as a developer, plus telling your manager that you're interested in product manager/designer/etc. If you can provide examples or observations about the product and its lifecycle, it can help take those conversations to something tangible
I don't have any resources but I can share a personal anecdote, as I've recently been offered a position as a product manager after having worked as a developer for a few years. A couple of product people I used to work with at another company reached out to me about the job based on how they've seen me handle my work. Here are some of the traits they noted as to why they thought I'd make a good fit:
- Rigorous questioning of product goals
- Ability to write clear and well-organized documentation
- Ability to effectively communicate technical concepts to non-technical persons
- Consistently following up with stakeholders
- General curiosity
I guess I've always had a tendency of viewing my role as a developer more holistically than others (i.e., not just being interested in coding, but ensuring that what I'm building is truly a good product from a business perspective, and helping to demystify the development process when speaking with non-developers).
But it would have been tough to break into this role without having proven myself to others who are already in my professional network, which is probably why the general advice is to try to move into the role somewhere you're already employed.
If your org has a software consultancy sales arm, you can make this shift by becoming a solutions architect. You'll get to work with sales and product to create solutions for prospective clients. A good product person will jump at the opportunity of a dedicated architect to help them with the tech portion of pitch decks.
I didn't read the text, but I'm glad to see people switching to project management. I've been one myself for 16 years, until I found that it was a dying career or, at least, a career obfuscated by alternatives like "product owner", "customer success" or just by the fact teams are getting more and more self-managed. I've seen a consistent reduction of job openings for project managers. Some specific niche oriented job boards don't even have "project manager" as option to select in the opening creation form. So four years ago I left my last project management job to never look back nor forward, as there wasn't much to look at anyway.
Some companies seem to be glomming project management into the list of job responsibilities for the dev lead on the team. Oftentimes this results in a role where the dev lead is 1/4 project management (or scrum master), 1/4 engineer, 1/4 people manager, and 1/4 hiring manager. Say what you will about it, but I think the trend will continue as organizations try to cut costs with the coming economic downturn.
Many times non-technical project managers were useless. Just overpaid glorified secretaries trying to take meeting notes, often losing valuable information in translation.
It made sense to rebrand to other job titles so as not to attract the same wrong people full of certifications which were irrelevant to software dev.
In the end I can see it being named project management again, but only after the wrong crowd is weeded out.
I agree that project management is dying as a field, I think it is a natural reaction to the top-down command and control style of project management popular in the early 2000s in favor of more agile, self-orienting teams.
I do see a new flavor of project management coming back branded as technical program management, which is more a flexible position responsible for the large cross-functional projects while filling the gaps of a dev team via process development, facilitator, and/or scrum master. Usually, this role is only necessary for large orgs with multiple teams or highly regulated industries that require a lot of coordination.
3. Burn through my 15 minutes morning paid break to go make some breakfast or coffee and decompress.
The scrum is rarely a productive meeting, it is more of an outlet for the extroverts of the team to talk.
As an introvert, this tires me.
Often the people in question don't even take breaks themselves. I wish they would take their break to have that small talk so I could keep my break for a better time.
This seems generalized to all teams I've worked in across several companies.
I tend to wake up really early and get straight to work, so by the time scrum comes around, I've already gotten 3-4 hours in, but haven't yet eaten or showered, so that's what I do next.
We put our standup after lunch if that's what you mean, because some developers are in the US and it's morning for them. It lets most of us get a quite peaceful morning of work in - somehow it spawns less meetings.
Afterwards there are usually meetings about issues raised in the standup or just others or just back to what we were doing.
Standups shouldn't be stressful and if they are it's a bad sign of the way the team is working. We should be able to say what's going on without feeling we'll get jumped on for it.
Working in a IT project/consulting company it varies a lot depending on team members and client.
The agile manifesto is just about trying to add value through work, iterating on smaller chunks of work, iterating on your ways of working, semi-regularly spending some time with the team reviewing how things are working out, and adapt accordingly.
Scrum on the other hand is a framework of meetings, roles, rule, and a common language that help heavily process oriented companies/people dip their toes in. A first step if you will, then you iterate to make it your own. Unfortunately, some people "swallow the manual" and take it far too inflexibly. Or deity forbid some business transformation consultancy sells your upper-management the Scaled Agile Framework and its time to polish off the old CV.
So depending on where the particular project lies on a scale of understanding between those two: any and all of the above. Standup is not meant to be stressful, it's just meant to be a forum to raise issues, but some people insist on pulling teeth.
i would argue it was never supposed to have scaled. businesses do need to scale engineering teams though, so its natural they tried to scale something that works at a team level.
> You can't lead developers if you have no clue about developing. Sorry.
Yessss. So many companies dont understand that. Every time I was a part of project that struggled it was due to terrible middle managers that did not understand anything and could not decide.
They often try to dispatch ALL their work to someone beside status meetings and forwarding emails.
Useless leeches. If you are this kind of Project Manager do everyone a favor and leave.
Team will most likely not even notice you are not there.
> You can't lead developers if you have no clue about developing. Sorry.
Laissez-Faire Leadership.
I've been on several massive teams where the project managers had no idea about the tech stack, but worked so well with the dev teams that they relied on the devs to give them input on tasks and proper expectations and allowed them the ability to have a stake in the game, not just sitting there taking directions from people who know nothing about their tech stack.
I think its disingenuous to say you can't lead developers without having an intimate knowledge of the tech stack they're using. I've worked on small teams and massive teams and in only a few cases ran into non-technical managers who thought they could strong arm developers into hasty releases and poorly coded prototypes. Most of the managers I've worked with who were not technical, went out of their way to build a more affable relationship with developers since they knew we were the key to the project's success.
I've had good software engineering managers who couldn't code anything beyond simple shell scripts.
It's possible to be a great developer manager without having been a developer yourself, but it's much harder and much less common.
In my experience, the managers who excel despite not having an engineering background usually get promoted through the ranks quickly, so you may not see them much anyway. Being able to effectively manage people without completely understanding their work is a valuable (and rare) skill.
[+] [-] PeterWhittaker|3 years ago|reply
I’ve been both a developer and a development manager (and a few other things), and once upon a time I would have agreed wholeheartedly with this.
Then about 10 years ago I started working with the best PM I have ever known. He is absolutely not technical.
He is, however, a great listener, opionated about protecting people from burnout and dumb processes, honest to a fault, and able to speak candidly and openly to techs, devs, execs, and everything in between, switching language as he goes.
On one project we worked on, I had an advisory role and he ran the development sprints. He was amazing at understanding what the devs needed and managing the manager’s unrealistic expectations of how quickly things could be done.
He also put his foot down and insisted that everything flow through him, to be integrated into schedules based on, well, balancing everything else with business priorities.
It took a some time for the devs to trust him, and it took a lot of soft skill work on his part to gain that trust, but before long they realized their weeks were pretty evenly balanced.
The first big win was no more high priority interrupts from the manager, who had to work through him. That helped a lot.
He knows nothing about development, in the sense of having no idea how to do it.
He does know people and knows how understand what they need.
FWIW, YMMV. He’s a rare breed.
[+] [-] gbrindisi|3 years ago|reply
My theory is that technical leads have a narrower distribution of quality, while not technical leads vary wildly, from crazy good to nuclear winter bad.
[+] [-] dnissley|3 years ago|reply
[+] [-] rileymat2|3 years ago|reply
This is a mixed bag, it can be truly helpful or a political control structure. All the other personality traits are probably what makes it work.
[+] [-] mmargerum|3 years ago|reply
I jumped ship to a tech lead job. Now I do what I always wanted which is to direct a team (dotted line) by scaffolding out the project using diagrams and shallow coding. Very few soul sucking status meetings. .Dream job and a nice 25% salary boost.
[+] [-] jghn|3 years ago|reply
At a lot of companies the description you gave for "senior developer" would be described as a tech lead. In many other companies neither example you gave would line up to their terminology. And every possibility in between.
There's not much uniformity in titles and descriptions of roles.
[+] [-] eikenberry|3 years ago|reply
Really sounds like that last job was just garbage and you moved on to someplace better. Had nothing to do with the position other than it wasn't the lead position you wanted.
[+] [-] DawsonBruce|3 years ago|reply
And what you’ve said is 100% true.
[+] [-] mind-blight|3 years ago|reply
[+] [-] angarg12|3 years ago|reply
In fact I'd encourage to do the opposite, describe the job activities and then map them to whatever mental model you have about dev career ladder.
[+] [-] mouzogu|3 years ago|reply
[+] [-] ilovefood|3 years ago|reply
[+] [-] altdataseller|3 years ago|reply
[+] [-] throwawaysleep|3 years ago|reply
[+] [-] andi999|3 years ago|reply
[+] [-] Cloudef|3 years ago|reply
[+] [-] t43562|3 years ago|reply
Agile is usually a team practise which outsiders like a PM don't get a say in. The Product Owner feeds work in and stakeholders get to argue about the order of each item and that's all.
A retrospective allows the team to adjust their way of working to fit better to their situation and it is them that decide not some PM.
Standups are aimed at killing long status meetings and if they're not then something is wrong. The Ceremonies have a purpose and the overall purpose is to use the development resource that is available to do the things that most need to be done and not waste it on anything else.
To bring this back to the article - how can a project manager decide what is or isn't efficient for some team? How can they estimate anything when they are far from the details - no matter how much programming they did in the past?
[+] [-] jrochkind1|3 years ago|reply
I believe you can find that "contradiction in terms" at thousands of organizations these days. Probably more than are "running agile" without a "project manager".
[+] [-] azangru|3 years ago|reply
[+] [-] goodpoint|3 years ago|reply
[+] [-] doctor_eval|3 years ago|reply
I have lost two important (to me) jobs because I refused to adopt stupid, inefficient processes handed down by non-technical “managers” who thought they knew how to manage developers better than I did, despite my 30 years of experience.
Reading this almost made me cry. If I could upvote this a thousand times then I would.
[+] [-] mpyne|3 years ago|reply
Seems like the Agile Industrial Complex has twisted the meaning of 'agile' in developers' minds completely out of what the manifesto's authors meant by now.
[+] [-] grahamm|3 years ago|reply
[+] [-] mind-blight|3 years ago|reply
[+] [-] canaus|3 years ago|reply
I've realized I'm more interesting in creating solutions and ways to make them better than coding them, but the path to get from A to B seems muddied.
[+] [-] ilovefood|3 years ago|reply
[+] [-] Minor49er|3 years ago|reply
[+] [-] bavila|3 years ago|reply
- Rigorous questioning of product goals
- Ability to write clear and well-organized documentation
- Ability to effectively communicate technical concepts to non-technical persons
- Consistently following up with stakeholders
- General curiosity
I guess I've always had a tendency of viewing my role as a developer more holistically than others (i.e., not just being interested in coding, but ensuring that what I'm building is truly a good product from a business perspective, and helping to demystify the development process when speaking with non-developers).
But it would have been tough to break into this role without having proven myself to others who are already in my professional network, which is probably why the general advice is to try to move into the role somewhere you're already employed.
[+] [-] onelesd|3 years ago|reply
[+] [-] ipaddr|3 years ago|reply
[+] [-] rodolphoarruda|3 years ago|reply
[+] [-] tmountain|3 years ago|reply
[+] [-] snidane|3 years ago|reply
It made sense to rebrand to other job titles so as not to attract the same wrong people full of certifications which were irrelevant to software dev.
In the end I can see it being named project management again, but only after the wrong crowd is weeded out.
[+] [-] plebuhn|3 years ago|reply
I do see a new flavor of project management coming back branded as technical program management, which is more a flexible position responsible for the large cross-functional projects while filling the gaps of a dev team via process development, facilitator, and/or scrum master. Usually, this role is only necessary for large orgs with multiple teams or highly regulated industries that require a lot of coordination.
[+] [-] MisterBastahrd|3 years ago|reply
After scrum, do you:
1. Immediately get to work
2. Spend time going through recent communications
3. Walk away from the keyboard to decompress
?
[+] [-] Karawebnetwork|3 years ago|reply
The scrum is rarely a productive meeting, it is more of an outlet for the extroverts of the team to talk.
As an introvert, this tires me.
Often the people in question don't even take breaks themselves. I wish they would take their break to have that small talk so I could keep my break for a better time.
This seems generalized to all teams I've worked in across several companies.
[+] [-] Cloudef|3 years ago|reply
[+] [-] nonameiguess|3 years ago|reply
[+] [-] t43562|3 years ago|reply
Afterwards there are usually meetings about issues raised in the standup or just others or just back to what we were doing.
Standups shouldn't be stressful and if they are it's a bad sign of the way the team is working. We should be able to say what's going on without feeling we'll get jumped on for it.
[+] [-] marcosdumay|3 years ago|reply
You mean the daily standup?
Scrum is a full process. There's no "after", no "before". It's a steady state.
(Anyway, I need to decompress almost all meetings I have, of any kind.)
[+] [-] JustSomePackets|3 years ago|reply
The agile manifesto is just about trying to add value through work, iterating on smaller chunks of work, iterating on your ways of working, semi-regularly spending some time with the team reviewing how things are working out, and adapt accordingly.
Scrum on the other hand is a framework of meetings, roles, rule, and a common language that help heavily process oriented companies/people dip their toes in. A first step if you will, then you iterate to make it your own. Unfortunately, some people "swallow the manual" and take it far too inflexibly. Or deity forbid some business transformation consultancy sells your upper-management the Scaled Agile Framework and its time to polish off the old CV.
So depending on where the particular project lies on a scale of understanding between those two: any and all of the above. Standup is not meant to be stressful, it's just meant to be a forum to raise issues, but some people insist on pulling teeth.
[+] [-] corpMaverick|3 years ago|reply
I am most productive before the stand up. The stand up really burns my energy.
[+] [-] dogcomplex|3 years ago|reply
[+] [-] g051051|3 years ago|reply
Truer words were never spoken.
[+] [-] dionian|3 years ago|reply
[+] [-] pojzon|3 years ago|reply
Yessss. So many companies dont understand that. Every time I was a part of project that struggled it was due to terrible middle managers that did not understand anything and could not decide.
They often try to dispatch ALL their work to someone beside status meetings and forwarding emails.
Useless leeches. If you are this kind of Project Manager do everyone a favor and leave.
Team will most likely not even notice you are not there.
[+] [-] at-fates-hands|3 years ago|reply
Laissez-Faire Leadership.
I've been on several massive teams where the project managers had no idea about the tech stack, but worked so well with the dev teams that they relied on the devs to give them input on tasks and proper expectations and allowed them the ability to have a stake in the game, not just sitting there taking directions from people who know nothing about their tech stack.
I think its disingenuous to say you can't lead developers without having an intimate knowledge of the tech stack they're using. I've worked on small teams and massive teams and in only a few cases ran into non-technical managers who thought they could strong arm developers into hasty releases and poorly coded prototypes. Most of the managers I've worked with who were not technical, went out of their way to build a more affable relationship with developers since they knew we were the key to the project's success.
[+] [-] PragmaticPulp|3 years ago|reply
It's possible to be a great developer manager without having been a developer yourself, but it's much harder and much less common.
In my experience, the managers who excel despite not having an engineering background usually get promoted through the ranks quickly, so you may not see them much anyway. Being able to effectively manage people without completely understanding their work is a valuable (and rare) skill.
[+] [-] saos|3 years ago|reply
Out of curiousity would you say the same about product managers?
[+] [-] unknown|3 years ago|reply
[deleted]