CS Management: What Do Senior Software Engineers Do?

Tech management is like any other management, but has some clear idiosyncrasies tied to the heavy emphasis on computers.

Projects and Cycles

One of the clearest distinctions between tech projects and most others comes from how technology magnifies labor:

  • Conceptually, an amateur can produce a certain amount per day, and an expert will produce a bit more.
  • On the other hand, a computer assigned to the task can often produce exponentially more than a human, but takes more time to prepare through robotics design and software development.
  • Therefore, a project will be difficult to track near the beginning (and likely won’t produce at all), but will vastly outperform a human equivalent later on.

While Agile methodology was formed for the purpose of getting a team to synchronize plans as software was versioned, it can mean that weak leadership will make goalposts constantly move around on the project from absolutely any feedback on the team.

Communication

Computers, by their nature, are highly ordered. While this can be very convenient (and scalable), it represents an inhumanity that’s the exact opposite of what nature provides.

Thus, while well-designed systems can satisfy 90% of everyone’s needs (or 95% with clever design, or 99% in the case of AI implementations), there must be a redundant fallback that isn’t a computer.

Without any fallback, the system will slowly devolve into yet another FAANG system, with minimal customer service and new tech startups that will attempt to fill the gap with more technology.

Ombudsman

Every well-designed system integrated heavily with technology needs a third-party ombudsman to mediate conflicts which may arise between people inside the organization and outside it. They have to be outside normal channels, and should receive far more authority than any tiered technician or middle manager.

Without an ombudsman, the gaps in expertise will likely be filled by technical idiots that fix problems that may not need fixing, or that won’t resolve the actual problem the user is having.

There are several options that prevent abuse of an ombudsman system, and should be communicated before the fix is applied:

  1. Place a hard limit on what the ombudsman is allowed to do (e.g., a $20 limit per fix).
  2. Require the user to pay for the problem to be fixed.
  3. After fixing it, track whose fault it was, and bill it to either the organization or the user, depending on the situation.