I don't see how bringing in an "engineering productivity worker" can have anything but a very low probability of success.
It probably means one or more of the following:
- Management thinks that engineering productivity is lacking.
- A lack of communication between management and engineers.
- Poor management.
- Poor engineering.
The root problem is almost always management and a "consultant" brought in to a situation like this can typically not affect any real management change.
It's the same sort of trap that a Scrum Master is in in a "non-Agile" organization and why "Agile" has failed.
I think you have misunderstood what an engineering productivity worker is. It's anybody who works on tools, frameworks, systems, processes, practices, etc. that help make developers lives better.
That's also what senior engineers do. And it's certainly how I develop code - my primary approach is building tools to lever up productivity and bring the level of abstraction closer to the domain.
More generally, process improvement and practices have normally been introduced on the suggestion of engineers in reaction to problems, in consultation with management, in companies I've worked at.
That sort of sounds like anything between what a regular developer would do, a build engineer, and a VP Eng.
There's a big difference between someone joining the team with the role being helping the team build better internal tools to someone who is joining to change the way the team works. I was thinking about the latter and it seems your definition includes both?
Sort of, yeah. See https://testing.googleblog.com/2017/04/code-health-googles-i... as one of the examples of a type of Engineering Productivity work that I do at Google (although as you have basically pointed out, there are reasons we avoided that word for the work that I do, although I still think it falls under the broader umbrella).
It seems like the thing that you're worried about (I mean, correct me if I'm wrong, this is just the sense I get from your post) is people hiring a sketchy consultant to come in and have everybody follow some process whether or not it has anything to do with their work or making things actually better. I'm definitely also opposed to stuff like that and I've made a few jokes or snide comments about it here and there on the blog, in http://www.codesimplicity.com/book/, and on my Twitter feed.
Kind of. It's mostly a people thing, not a strictly technical thing. A lot depends on the company culture. In my company in theory the IT department is there to help everyone with their IT needs. In practice interacting with that group is painful because they are not necessarily aligned or motivated by the same things other people are. I can imagine that having an "engineering productivity" group can suffer from similar problems but if the culture is right then it can be a win/win.
It probably means one or more of the following:
- Management thinks that engineering productivity is lacking.
- A lack of communication between management and engineers.
- Poor management.
- Poor engineering.
The root problem is almost always management and a "consultant" brought in to a situation like this can typically not affect any real management change.
It's the same sort of trap that a Scrum Master is in in a "non-Agile" organization and why "Agile" has failed.