Lessons learned as a software developer turned project manager
karimjedda.com
karimjedda.com
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.
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.
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.
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.
And what you’ve said is 100% true.
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.
A lot of companies mistake tech lead for "senior dev" or "dev manager" or some chimera of both.
An organization that has a team lead constantly in meetings is horribly mismanaged; and is looking for a talking head to boost someones' ego.
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.
If I decide to slow things down as I get older I may go back to just straight coding. I love it.
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.
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 believe you can find that "contradiction in terms" at thousands of organizations these days. Probably more than are "running agile" without a "project manager".
Their estimates have to be based on what teams predict and velocity and so on and on.
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.
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.
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.
- 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.
But PM/PMM roles can vary a fair bit.
One would have to articulate a lot to make a point about a project manager being directly associated with sales/revenue etc. -- the top line. "Oh yeah, the project manager can increase customer satisfaction and then contribute to upselling, especially in companies focused on farming and not much on hunting customers!" -- I agree, but it's rare now.
Typically, a project manager has authority over resource allocation and resource planning, but must defer to the stakeholders for everything else (most importantly, for actual design/implementation decisions). A product manager has authority over the complete lifecycle of his product, including design, implementation and resource allocation.
- Reads Jira (or whatever) and moves things around (yes, they may also add things sometimes, but I'm drawing a general distinction).
- Gantt charts.
- Tracks project status, communicates it upward.
- May also do some communicating expectations downward.
- Translates blunt assessments of the project's progress into managerese.
- May have some responsibility for keeping development processes going, especially ones that involve lots of communication (think: Agile shit, or just project status meetings generally)
- Helps unblock process-related shit.
Product manager:
- Writes to Jira a lot.
- Does market research, or works closely with those who do.
- Guides the direction of the product (e.g. which feature do we tackle next, do we pivot).
- Works closely with key stakeholders (clients, product owners, domain experts) to determine that direction.
- Sells that direction to management and such.
- May have some significant sway on final decisions for e.g. design.
- May do quite a bit of business-model analysis.
I think the role of project manager is dying for a good reason. Developers can organize themselves and it is more important to have that leading person motivating the dev teams with interesting problems while respecting them -> my approach. The rest is shared between product mamager, senior developers maybe some shared delivery lead resources or the engineering manager.
The best project manager I had was a film producer moonlighting as a pm between films. The film producing experience, tight deadlines, tight budgets, scheduling, lots of cross functional teams, bringing them together at the right time etc really carried over well.
There seems to be diminishing returns for salary increases with responsibility increases.
First reason, product managers at a company start getting pulled into a lot of client management stuff. They have less time to spend on the product itself and the resulting vacuum is often filled by the lead dev. The lead dev demonstrates they can fill the vacuum, so starts getting asked to fill other vacuums relating to management and hiring.
Second reason, management doesn’t have a clear image of what a “developer” role should look like in their company. E.g. at tiny startups a dev might be entirely responsible for a product and even help answer customer emails. (I’ve done that and I actually think it’s fine, as long as you and the rest of the company know that’s the deal.) At the extreme opposite end, a dev might have little autonomy and be practically writing the Python syntax version of tightly specified business logic. But most companies operate in the fuzzy middle and I think many struggle to define their concepts of dev / QA / product. In those companies, it’s easy for a dev to become someone who is officially “a developer” but with a bunch of semi-official hats.
I might have to add a third reason to my theory, now that you’ve reminded me about cost cutting.
combined with
In those companies, it’s easy for a dev to become someone who is officially “a developer” but with a bunch of semi-official hats.
results in a similar story with Devops and it's younger brother, SRE. My job role officially changed from "Devops Engineer" to "Site Reliability Engineer" when I switched jobs two years ago and I'm lacking in finding ways of differentiating the two.
It's seemingly become the default response now on Devops communities when someone makes a thread saying "I want to get into Devops, what do you do?" that the job role means 'whatever the company wants it to mean', which is how we end up with Devops practitioners and teams getting turned into kitchen sinks for dealing with anything and everything the feature development groups aren't tasked with because of a severely unchallenged assumption that the dev team brings in revenue, while the operations people consume it.
An assumption that's never said outright-mind you, but the organization and delegation of work between the two domains of functional teams, IMO says it pretty loudly.
Early on, the tech lead will be primarily an engineer and hiring manager: there's not enough people to really need a process yet, and so the tech lead lays the technical foundation while building up the team with the right people.
As the team grows, the tech lead will reduce their engineer responsibilities and start focusing on project management in order to deal with the complexities that come from a larger team.
Once the team is at a steady state, both in terms of people and process, the tech lead can focus on people management, primarily by training people to take over the other responsibilities.
I'm not saying there won't be periods where a tech lead is being stretched too far as the team transitions between these phases, but if the stretching persists for too long then something has gone wrong.
Last couple jobs had Engineering Managers to do (1) and generally manage the team. The problem is that EMs don't really know anything about anything. Maybe at one point they were a developer and knew stuff. But since they're not in the code every day they don't know the reality of the code base and their general programming skills decay. Effectively they become a relayer of messages between the dev team and the business with lots of information being lost along the way. I much preferred the previous way.
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'll also point out that this stereotype is widely accepted by engineers, so even if you are a former engineer and do have the technical chops, many engineering teams out there will treat you like a secretary anyway and disregard your technical judgment. I'm a project manager but have been coding for longer than a lot of engineers I work with have been alive. I've seen the spectrum of engineers from great collaborators who treat you as a [technical and professional] equal, to arrogant assholes who treat you like you're their note-taker/janitor/servant.
For a concrete example, I remember a project manager arguing with a senior developer about what a particular wireless specification required, the project manager had a Bernie Sanders moment when she had to remind him, "I wrote the damn spec!"
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.
In general, I would consider this trend healthy. Managing your time and your priorities, communicating with stakeholders, etc. are all skills that all engineers should develop over time, even if just for their own personal work. At the team level, shared processes and priorities should be guided by a tech lead/engineering manager who has the incentives to keep process overhead to a minimum. Ideally, once a process has been put into place there should be very little for a dedicated project manager to do on a day-to-day basis.
Where project management skills shine most is when the work involves multiple teams and the "lowest common manager" is either too high up the org chart to be involved in the details or doesn't exist (because the coordination is between separate companies). This usually manifests as "customer success" or "technical program management" roles, though they could just as easily be called "project management".
After scrum, do you:
1. Immediately get to work
2. Spend time going through recent communications
3. Walk away from the keyboard to 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.
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.)
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.
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 am most productive before the stand up. The stand up really burns my energy.
Truer words were never spoken.
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.
Out of curiousity would you say the same about product managers?
You don’t have to know how code works to know something about how it works. Ideally, you should be able to give directions to your QA person on how to get started interactively testing new features, etc.
Leading developers requires tech knowledge, leading product managers requires strong product knowledge as well as an understanding of what’s possible and what might not be possible, which one develops over time learning an app.
Might not align well with the above statements, but I recommend the following books for product folks:
INSPIRED: How to Create Tech Products Customers Love https://g.co/kgs/CxFues
EMPOWERED: Ordinary People, Extraordinary Products https://g.co/kgs/2DhX7s
Product Roadmaps Relaunched: How to Set Direction While Embracing Uncertainty https://g.co/kgs/EthDBf
Product can contribute strong to the visible software while leaving the tech and implementation decisions to technical teams…
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.
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.
I was in a technical role for 5 years before I started managing a team and I still lack perspective sometimes. I don't always see the big picture. I don't always understand the LOE on my asks. I try to be clear with my team that this is one of my limitations and to please call me out on it if I'm missing the mark, etc.