I’ve seen a lot of friends and coworkers who are individual ICs in Senior and Staff roles balk at the idea that they're spending so much time managing and convincing other people instead of writing code. We got into these careers because we enjoyed spending time thinking through logical problems, designing systems, and writing code to solve those problems. And now we're spending time on client calls, trying to manage relationships between stakeholders, and figure out what is the appropriate set of requirements that will get other teams to do work.

My first answer was, humans are social creatures, and engineering systems especially are sociotechnical ones. (I mean sure all engineering is social too but because of the lack of accreditation/regulation and the fact that we're talking about shifting bytes of data around, it's way more social). But more recently I've come around to the idea that there are some forms of project management that are really harmful, both from a culture and also a career perspective.

I’ve come to the conclusion that engineering first cultures (both technically and socially) are the result of external pressures that align incentives where the cultural values mean that every extra unit of software/unit produced is more valuable than optimizing on the what. And this is generally the result of companies (and societies) that are rapidly expanding, have extra cash and see a huge marketplace where there’s lots of cash on the table if only they can make a system to capture it.

Everyone likes to point to Boeing as this perfect example of what happens when MBAs displace engineers. Once successful company, falls apart as it slowly becomes more profit oriented. And, yes absolutely. I too would love to operate at a company where engineering were valorized and engineering first cultures abounded. But also, finding the right alignment to work at a company where that exists is rare in both space and time. So you either have to find one of those cultures and situations or you have to orient your career to make those situations more likely… which is… once again. Sales.

It also doesn't help everyone I’ve seen writing about this is the type of person to face this problem head on in one way or another. Which I guess means that a lot of their advice about how to shape your career is somewhat impractical, both from an exemplar perspective (dunno how many of us are going to become CTOs, start our own businesses, etc.) and also from a desire perspective. If the goal is to have a job that takes up just the right amount of time and also provides some career growth, what does that mean?

I'm not sure this actually means anything to be honest, more than that the people who are writing things tend to be self-starters.

But the details of this stuff matters. There are some situations where project management (both of the tech lead and more mundane varieties) represents a real step up for your career, both in terms of responsibilities and if you're getting what they call "career growth". But also, extra interpersonal management can cause equal drag on your career the same way that doing rote software tasks can.

I think the question is rather straightforward, are you working with other people to come up with solutions and agreements around (hard) problems or are you spending your time trying to negotiate against your values.

Negatives

• Secret Performance Management (Accountability Check-Ins)
• Documenting decisions to preempt escalations and arguments
• Sizing Features not Problems to Solve

These are all pretty straightforward. If you have to do performance management in the guise of project management there's just no world where that's a career benefit. And I'm not talking about giving someone feedback on a pull request. I mean like, creating regular check-in cadences to keep someone on track, scheduling your timelines around their abilities, or having other people shift their work around to support.

Decision documentation is important, and it's important because humans are fleshy creatures who need constant reminders of the things they agreed to. That's ok. But what's not ok is needing a decision document to figure out who's to blame if a timeline gets missed or things go sideways, or creating decision documents for paper trails if things get escalated in the future. It's not that things should never get escalated, or understanding why is unimportant, but being in a culture where these things are necessities signals a significant trust breakdown that can't be hand-waved away.

Finally, are you spending more time project managing feature requests or solving problems? If you're estimating feature requests there are a number of reasons that's a losing battle. Firstly, the requester already has a number in mind, so at that point it's really about figuring out how to deliver something that approximates that. Secondly, you're going to spend a lot of time expectation managing why things are going sideways, instead of solving problems. Thirdly, the type of timing and tactical problems that come up in the course of this will not require thought to process, so you're not developing technical skills in the process of doing them.

Positives (that might seem negative)

• Writing concise (architectural) documentation
• Coordinating meetings between different teams
• (Some) Ticket organization

It would be easy to leave this discussion with some sense that I believe that documentation is bad. Far from it. But the purpose of documentation is always about point in time communication, not as an artifact. I.e. if you write something you should be trying to transmit information to another human being for a specific purpose, whether that's yourself in the future, a stakeholder or another engineer. And explaining why you want to do something, what else you considered, and your decision is a great way to quickly flex your technical chops, get other people on board, and also invite productive disagreement about alternative options.

Coordinating meetings. Often, at large technical organizations, the teams doing the work will have multiple things going on at the same time. (We're all shocked here, I know) This means occasionally you'll have to meet to check in to make sure that everyone feels confident that they can still hit the deadlines and discuss anything new that's popped up in the interim. These are good and positive meetings (and generally happen at much more infrequent cadences than the aforementioned accountability checkins).

Finally, ticket management. I actually think it's really important for developers to maintain their own tickets. The tickets are the things that connect the "what we're trying to do" to the "how we're going to do it". It is both a technical question to answer "is this important" as well as "how important" and "what are the risks". Being able to get detailed enough about the tickets that you can execute work, and also connect that work to the goal in mind is its own skill.

It's Nuanced, I Guess

The hard thing about all of this is that the benefit of software engineers are their ability to solve challenging business problems through code. But the lever to be able to solve those problems is the ability to communicate and collaborate with other engineers and stakeholders. Poor communication puts limits on how big the problems any given engineer can solve.

(Unless, once again we're talking about the aforementioned engineering first cultures, though even then you could argue building engineering first solutions with great documentation and UX is its own form of communication... but I digress)

Being able to differentiate what project management opportunities are beneficial versus toxic can help make workplaces less challenging and set you up for more success down the line.

Photo by airfocus on Unsplash