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.

I'm watching Ted Lasso and it's uncanny how well this describes the titular character

> 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 .... 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.

I was promoted to senior engineer this year at my organization…

And what you’ve said is 100% true.

Yeah, what you just described as a senior engineer has been my experience as a tech lead. It's really organization dependent

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.

I'm a senior developer who doesn't want to be a tech lead. Kind of unsure about where any kind of progression lies.

OP here, I can completely relate. I am changing jobs too for a similar role, hopefully :)

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.

Wait, senior developer is paid the same as developer?

True, especially in small company / startup ...

> 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?

A project manager trying to run agile is the perfect justification for micromanagement.

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.

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.

Get a PMP certificate and start approaching companies

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.

What do you do now?

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".

What did you switch to?

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.

https://toggl.com/blog/mars-software-development Very much related

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.

> After scrum

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.)

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.

3.-

I am most productive before the stand up. The stand up really burns my energy.

3

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.

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.

> You can't lead developers if you have no clue about developing. Sorry.

Out of curiousity would you say the same about product managers?