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.
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?
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.
That's what this boils down to. Being told you have a problem and then force-fed a solution down your throat never feels nice.
Another thing I've noticed, at least at the few places I've worked at is, the bottleneck for the company is practically never engineering productivity. Engineers exist to amplify the efforts of other people, nobody ever sells the output of the engineering department directly.
Even when they are directly selling software to the public, there's a release cycle and backwards compatibility to care about before the number of features in each release becomes important. There is also a lot more to a software product than the code going into it.
Savvy, politically-aware engineers notice this and carefully structure the pace they're working at. They could easily plow through dozens of tickets or stories if it's called for, it's just that nobody ever expects them to work that hard. Smart management gives the engineers political cover so they're not kicked around like beach balls between upper management PHBs with too much time on their hands.
This approach has worked well for me in the past. In one of my past roles, I was writing tools to try to improve "quality."
One of the main problems we had was the bugs written were hard to reproduce, or had some kind of invalid configuration or incompatible build.
It took me a while to figure out that everyone is using host files to point to environments, and different mixes and matches of servers, which were causing lots of problems (but not real bugs). This was taking developer's time (testers couldn't debug the problem), tester's time (waiting for resolution, blocked), and made us think real bugs were not real bugs.
In the end the solution was to centralize hosts file management through a tool, where there would be approved configs that could be chosen, and they would be set automatically. Thing caught like wildfire. Super simple technical solution, and that gave me the street cred to make more complex proposals (like a CI system).
Be on the lookout for the small gains, and use them to build your cred. Also, if you get your foot in the door technically (like everyone running a tool they know they want), it's easier to add more things to it and keep the momentum going.
I do have to point out that there is one type of person missing from the author's "people who will push back", and that is people who have a vested interest in keeping the code base terrible, or designed the way it currently is. Reasons include "we're trying to log all this time against a re-write", "that code is too fragile and risky to change", and anything else the developer might think are idealistically correct, and nothing else will do.
If I have to do something more than once or twice, the first thing I think about is whether it is automatable.
One of the reasons I have always tried to stay close to the Unix view of the world is the access to simple tools that can be pipelined to provide powerful toolsets. I am a firm believer in the value of scripting things whether through shell scripting, awk, sed/vi, PERL (in the earlier days), Python etc.
The first thing I used to do when I get a Windows environment was to install cygwin or something similar that gave me access to Unix like toolsets. You may ask "Why not Powershell?" but I have been using Windows before the Powershell days and sometimes old habits are hard to break. The unix tools are almost near universal nowadays whether using Windows, Linux or MacOS/OSX.
Once you have acces to these tools simple repetitive/mundane tasks can be easily automated to increase productivity.
On the line width, are you referring to the desktop site or the mobile one?
I do have another post about measuring productivity: http://www.codesimplicity.com/post/measuring-developer-produ...