Blurring job boundaries

Zhiyi Zhang wrote in a comment posted on 6/10:

“I realized that I can’t do a good job if I keep wearing multiple hats…
It’s quite possible that management pushes to that extreme in the name of agile, knowingly and unknowingly.”

This is a good point.

In my view, there’s a difference between blurring job boundaries, and taking on multiple roles.

Suppose we have a company, BigCo, were there are software designers, UI designers, UI programmers, middle ware developers, and database coders. Software designers create designs the application layer. UI designers create the UI design. UI programmers only code the UI, middleware developers only work ont he middleware and database programmers only concern themselves with the database. Each does tasks within a that narrow band. There are lots of hand-offs, and groups have to coordinate with each other (but they’re not always effective, and people end up waiting for another group to complete their work).

Blurring the job boundaries would mean that a sw designer also codes, a developer also writes database queries, etc. People may have specialties, but they also have skills in the other areas. Each team has the skills it needs to build a functional slice of software.

When I talk about blurring job boundaries, I’m talking about moving on spectrum where specialist is one one end, and generalist is on the other. But the spectrum focuses (at least in this discussion) on creating working software.

It’s harder (and less effective) to juggle multiple organizational roles — from project manager to developer to operations support tech.