Archive
Nickels And Dimes
In mediocre 20th century orgs, some ambitious managers are always trying to get something out of their DICs for nothing so that their personal project performance metrics “look good” to the chieftains in the head shed. Nickle and diming “human resources” by:
- calling pre-work, lunchtime, or post-work meetings,
- texting for status on nights/weekends,
- adding work in the middle of a project without extending schedule or budget,
- expecting sustained, long term overtime without offering to pay for it,
- not acknowledging overtime hours,
- “stopping” by often to see “how you’re doing” without asking if they can help
does not go unnoticed. Well, it doesn’t go unnoticed by the supposed dumbos in the DICforce, but it does conveniently go unnoticed and unquestioned by the dudes in the head shed.
What other “nickel and dime practices” for getting something for nothing can you conjure up?
Empty Lifeline
Check out this “bent” pair of UML sequence diagrams:
The system on the right is pretty loosely coupled, no?
The Daily Question
In his latest book, Gary Hamel proposes that executives and managers ask an important question every day:
It would be a refreshing change from these daily questions:
- How can I get Wall St. off my back?
- How can I get the board to give me a bigger bonus?
- How can I stop my VPs from bickering with each other and kissing my ass?
- Can I blame my poor performance on the economy, fickle customers, and a natural disaster in China?
- How can I squeeze more productivity out of my DICs and trade nothing in return?
- What new management position can I create to extinguish this latest fire?
- How can I ensure that my legacy will be revered?
Volunteer Experience
Checkout this tidbit that I e-received from LinkedIn.com:
There are two ways to interpret the “why” of the importance of volunteer work to hiring managers:
- 4 out of 10 managers value compassionate and caring employees
- 4 out of 10 managers value employees who will work lots of unpaid overtime
Maybe its a 50-50 split between the two “whys“?
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?
Manager Types II
This post is an updated refinement of BD00′s class hierarchy for the manager types previously presented in the UCBH post. For your viewing displeasure, I’ve reproduced the “rev 0” version of the inheritance tree here:
The “rev 1” version, with all class operations elided because they’re not important for understanding the message I want to get across, is shown below. The absence of the “Tweener” in rev 0, which inherits the attributes and operations from both the “Bozo” and “Helper” classes, was a major mistake.
“Rev 1” is a much more accurate mental model of the manager kingdom because, as the probability density function below shows, the vast majority of manager “objects” are of the relatively boring, harmless, and ho-hum “Tweener” type.
If you look closely at the threshold locations in the scraggly drawn probability distribution, BD00 has postulated that even though the population is comprised mostly of “Tweeners“, there are more BMs than PHORs. Do you agree?
Luckily and happily, BD00 has never worked for, or with, a conscious BM. But he’s directly heard, and indirectly read, several stories from those poor souls who have (are you one of them?). Thus, BD00 is convinced that they do exist in nature.
All models are wrong. Some, however, are useful – George Box
Raising Ire
I’m a member of several C++ programming groups on LinkedIn.com. Because I’m passionate about programming and software engineering, I like to share links to what I think are interesting C++ articles to the groups.
Bam! Out of the blue, I get this BS “warning” from a hot shot moderator of one of the groups:
After challenging this self-important dude to point out some examples of “off topic” postings, to define excessive “posting frequency“, and to provide the name of my accuser, I received silence.
Out of curiosity, I contacted the group owner and asked WTF was going on. He checked into the situation and said that I wasn’t posting too frequently (of course, there IS no rule about posting “too frequently“) and that he enjoyed my posted links. Nevertheless, I quit the group since there are many other C++ groups to contribute to without being hassled by a power monger and control freak. Life is too short.
Via a simple analysis of the content in the “scary” warning message, I arrived at the conclusion that the dude was reading this bogus blog and got pissed off cuz he is either a BM or a BM wannabe – and the shoe fit. So, I sent a message to Mr. God and suggested:
“If my blog upsets you, then don’t read it.”
Of course, since he didn’t admit to it, I don’t know fer sure if Mr. little Hitler stumbled onto this blog and blew his stack . But, as you know, BD00 is prone to making stuff up and bouts of wild speculation. D’oh!
These Guys “Get It”
In the freely downloadable National Academies book, “Critical Code: Software Producibility for Defense“, the dudes who wrote the book “get it“. Check out this rather long snippet and place close attention on the bolded sentences. If you dare, pay closer attention to the snarky Bulldozer00 commentary highlighted in RED .
An additional challenge to the DoD is that the split between technical and management roles will result (has already resulted) in leaders who, on moving into management, face the prospect of losing technical excellence and currency over time. This means that their qualifications to lead in architectural decision making (and schedule making) may diminish unless they can couple project management with ongoing architectural leadership and technical engagement. The DoD does not (and legions of private enterprises don’t) have strong technical career paths that build on and advance software expertise with the exception of the service labs. Upward career progression trends leading closer to senior management-focused roles and further away from technical involvement tend to stress general management rather than technical management experience (well, duh! That’s the way status-centric command and control hierarchies are designed.). This is not necessarily the case in technology-intensive roles in industry (not necessarily, but still pervasively). Many (but nearly not enough) of the most senior leaders in the technology industry have technical backgrounds and continue to exercise technical roles and be engaged in technology strategy. Nonetheless, certain DoD software needs remain sufficiently complex and unique and are not covered by the commercial world, and therefore call for internal DoD software expertise. In the DoD, however, as software personnel take on more management responsibility, they have less opportunity and incentive to stay technically current (<- this “feature” is baked into command and control hierarchies where, of course, caste and who-reports-to-who is king – to hell with excellence and what sustains an enterprise’s health and profitability). At the same time, there is an increasing need for an acquisition workforce that has a strong understanding of the challenges in systems engineering and software-intensive systems development. It is particularly critical to have program managers who understand modern software development and systems (If that’s the case, then the DoD and most private enterprises are hosed. D’oh!).
Could it be that unelected, anointed “managers” in DoD and technology industry CLORGs and DYSCOs are still stuck in the 20th century FOSTMA mindset? You know, the UCB where they “feel” they are entitled to higher compensation and stature than the lower cast knowledge workers (architects, designers, programmers, testers, etc) just because they occupy a higher slot in an anachronistic, and no longer applicable, way of life – no matter what the cost to the whole org’s viability.
In command and control hierarchies, almost everybody is a wanna-be:
“I wanna rise up to the next level so I’ll: make more money, have more freedom, be perceived as more important, and rule over the hapless dudes in my former level“. Nah, that’s not true. BD00 has been drinkin’ too many dirty, really really dirty, martinis.
Rare Sighting
A friend and colleague sent me this terrific link: “The Wall Says It’s Time To Go“. He asked me for my highly esteemed, expert opinion on the manager described in the “You’re On Your Own” story. I told him that the manager’s behavior was a great example of the rarely-seen-in-nature, PHOR species. Here are a coupla snippets from which I formulated my unassailable opinion:
While his staff worked away, he sat with his feet resting on his desk reading the newspaper. The only time he got up was when an employee came in to ask for help. Then the manager dropped his paper and embraced whatever problem the employee was grappling with.
…a manager’s job is to be a mentor, and although the manager spends most of the day with his feet up, his role is more important than any work being done in the office. His job is to enable his employees to take whatever steps are necessary to ensure their continuing value to the company.
OK, so there’s no context for this example – we don’t know what the nature of the work is, or what products/services the enterprise creates and delivers. Nevertheless, in any setting, I’d prefer to have managers sit around doing mostly nothing until they’re needed instead of jetting around to one useless half-hour meeting after another feigning business and importance. But that’s me, and maybe only me. What about you?
Wax On, Wax Off
Hands on, hands off. I was trying to contemplate the reasons why some managers operate with “hands off” and here are three that I scribbled down at the gym…
Got any others?
Why am I here?
WTF?
Meh!
D'oh!
