Archive
Confined Safety
In ho-hum, yawner borgs, a meticulously followed but mysteriously unwritten rule is that Domain Analysts (DA) and Software Developers (SD) remain safely within the confines of their area of expertise:
The borg’s job classification, compensation, and status-award sub-systems ensure that this “confined safety” rule is firmly in place; and silently enforced. No encroachment is allowed, lest social punishment be inflicted to “right the wrong“.
When turf transgressions in the form of hard-to-answer questions and “suggested” alternatives from an encroacher occur:
a rebuke from the (Jim) encroachee is sure to follow. If that tactic doesn’t flatten and widen the boundary curve back into place, then the big gun is rolled out: management. D’oh! Watchout!
In effective, world class orgs, there is no “confined safety” rule:
This non-horizontal, continuous, and smooth interface boundary between disciplines is not only an anomaly, but when it does miraculously manifest, it’s only temporary and local, no?
Hell, there are no rules here. We’re trying to accomplish something. – Thomas Alva Edison
Mostly True
“Adding people to a late project makes it later” – Frederick Brooks
If an underway project is perceived as a schedule buster (and it usually is if managers are thinking of hurling more bodies into the inferno) then this famous Brooksian quote is true. However, if the project’s tasks are reasonably well defined, loosely coupled, and parallelized to the extent they can be, then adding people to a late project may actually help it finish earlier – without severely degrading quality.
Alas, the bigger the project, the less likely it is to be structured well enough so that adding people to it will speed up its completion. Not only is it harder to plan and structure larger projects, the people who get anointed to run bigger projects are more likely to be non-technical managers who only know how to plan and execute in terms of the generic, cookie-cutter, earned-value sequence of: requirements->design->code->test->deliver (yawn). Knowledge and understanding of any aspect of the project at the lower, more concrete, project-specific, level of detail that’s crucial for success is most likely to be absent. Bummer.
It’s About The People, Stupid
Check out the chapter names in part III of a brand spanking new “Project Manager‘s Handbook“:
So much for valuing “people and interactions over tools and processes“, no? The closest the book comes to mentioning people is that the word “staff” is mentioned once and “resources” twice. And no, the first two parts don’t emphasize the importance of people either:
So, aspiring young project manager, it’s obviously all about you. All ya gotta do to be successful is mechanistically follow the infallible recipe; dot the i’s and cross the t’s. Fuggedabout developing trusting, helpful, two-way relationships with the people who will be executing your project work. It’s not important or even necessary. All you have to do is: develop the plan, “acquire the resources”, and push the “go” button. 1-2-3.
To be semi-fair, I haven’t (and don’t plan to) read the book. The author may indeed address the thorny issues associated with monitoring progress and product quality, guiding the effort, and ensuring the well being of the people so that they’re willing to do their best – but I doubt it.
Definition Of Done
When the definition of “done” for a software development project is solely based on allocated time and budget, it’s relatively easy to be perceived as successful. When the schedule and budget are exhausted: the work stops, the software is delivered/released/deployed, and victory is unequivocally declared. Whoo Hoo! As long as the software runs, regardless of its quality and usefulness, all is well – in the short run.
When the achievement of one or more difficult-to-measure, but meaningful, quality metrics is added as a third criterion to the easily measured time and budget metrics, the meaning of “done” becomes less vague and more realistic. That’s why it’s rarely done in practice.
Ya see, CLORGs and DYSCOs are full of themselves. By not measuring the things that matter for long term viability, they can stay infallibly full of themselves till the fit hits the shan.
Silo City
The title of this strategy+business article, “One Way to Lose Employees: Train Them”, is not shocking, no? If you believe it, then you’ll most likely believe a fictional, complementary article titled “One Way To Retain Employees: Don’t Train Them“.
Regarding the first, real article, the authors assert that mechanistic training is not enough to retain employees. It just makes them more marketable to competitors. If they’re not treated well and not allowed to grow, they’ll simply leave.
Regarding the second, reinforcing ghost article, the author summarizes his/her message as:
The researchers found that the deliberate withholding of funding and the lack of active encouragement to participate regularly in seminars, training sessions, and workshops kept workers from leaving because it left them thinking that their skills were becoming obsolete and feeling that they were unmarketable and “stuck” inside the borg. Additionally, the dearth of career mentoring and unhealthy boss–subordinate relationships instilled a culture of fear and an unsettling feeling of quiet desperation among employees. The lack of job rotations also decreased employees’ hopes of a bright future, the researchers found. A policy of no rotating assignments prevented employees from learning about different aspects of the company and from forming new social contacts across the organization.
Between the research findings summarized in the two articles, it’s a slam dunk. To keep employees from leaving, simply don’t train them and keep them sequestered within their one dimensional silos.
But wait! All is not lost. To retain employees while simultaneously training them to be more productive to the org, the authors of the real article recommend this multi-faceted approach:
The researchers found that regular participation in seminars, training sessions, and workshops sent an important signal to workers that the organization was investing in and valuing them. Additionally, career mentoring and healthy boss–subordinate relationships built loyalty among employees. Job rotations also increased employees’ hopes of a bright future, the researchers found. Rotations allowed employees to learn about different aspects of the company and form new social contacts across the organization.
Meet The FOCHers
FOCH == Frequency Of CHange
A Bum Rap
Middle managers often suffer from a bum rap. There’s pressure from above to meet schedule and cost, and there’s pressure from below to trade schedule and cost for quality. Since their bread is buttered from above, the likelihood of middle managers being able to deftly handle those conflicting demands equitably is low, very low. Ya can’t blame them for capitulating to the demands from above, right?
Fuzzy And Clear
The higher one ascends up the corpo ladder, the fuzzier one’s view becomes regarding how the enterprise works and what mania takes place down in the boiler rooms. On the other hand, who reports to whom becomes clearer and clearer and perversely more important than nurturing continuous improvement and innovation. These effects can be called “losing touch with reality” and “perverse inversion of importance“.
Effective But Destructive
In “I’m Feeling Lucky”: Google Employee No. 59 Tells All , Douglas Edwards tells one story about mercurial Google co-founder Larry Page:
How Larry reorganized the engineering department, for example. He didn’t like the fact that project managers were getting between him and engineers, so he called a meeting and told them very publicly that he didn’t need them–.
I’ll assert that in lots of companies, the reverse is true. In those that are DYSCOs and CLORGs, head cheeses don’t care to understand what goes on down in the boiler rooms and they desperately need project managers to tell them what’s going on. The funny part is that the project managers most likely don’t know either. D’oh!
There’s a second part to this post and the message is at the tail end of the full version of Mr. Edwards’s quote:
How Larry reorganized the engineering department, for example. He didn’t like the fact that project managers were getting between him and engineers, so he called a meeting and told them very publicly that he didn’t need them–and those people felt humiliated. I think Larry took a lesson from that, and I think he became more adept over time at managing. A young startup entrepreneur might share some of the characteristics of Larry. “If there’s a problem, reboot, fix it, move on.” That can be effective but can also be destructive. It can tear down relationships.
A Costly Mistake For Many
In “Learning Standard C++ as a New Language“, Bjarne Stroustrup gives a slightly different take on the waterfall method of software-intensive system development:
“… treating programming as merely the handmaiden of analysis and design doesn’t work either. The approach of postponing actual discussion of code until every high-level and engineering topic has been thoroughly presented has been a costly mistake for many. That approach drives people away from programming and leads many to seriously underestimate the intellectual challenge in the creation of production-quality code.“
If your company implicitly treats software engineers like “code monkeys” and great engineers strive to “rise” into coveted management positions ASAP because the unspoken ethos is that “coders” are interchangeable cogs, then your company most likely has made costly mistakes in the past and it will most likely do so again in the future.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 