Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Selling swimsuits to a drowning man

by wjw (Priest)
on Jul 16, 2014 at 18:13 UTC ( [id://1093919]=note: print w/replies, xml ) Need Help??


in reply to Selling swimsuits to a drowning man

So, is “the blind leading the blind” an accepted business-practice these days?

In short: Yes. More importantly from my perspective is that it does not stem from salesmen; but instead business management and leadership. I realized this around the time a book came out(heavily touted by corporate management as something everyone at every level should read) which stated in the forward that:

"...leadership is finding a parade and getting in front of it."

I had been working for that well respected R&D company for four years at that point, and it is at that point that I lost all respect for that company. Unfortunately, that is the general attitude about career advancement these days and work performance measurement too. It is pervasive in what I have observed over the last ~15 years.

Generally, I try to keep my posts here pretty much on topic, but this is one issue which threatens to get me all up on my high horse. So, I am going to allow myself to rant just a bit.

Some of this is spurred by the excellent series posted by eyepopslikeamosquito, Nobody Expects the Agile Imposition (Part I): Meta Process and follow ons. I am still reading through that work, cogitating, and attempting to wrap my abused brain around what all that means to me. The point brought up here is a tiny micro-symptom of the business "Magic Pill" syndrome. So many pills to take over the years! Just look at the list of references and the volume of subject matter!

    A few of the pills we have/are taken/taking:
  • RUP
  • Lean Mfg.
  • World Class Mfg
  • Black/Green Belt
  • SPC
  • SCRUM>
  • AGILE
  • ...all the other training in leadership, productivity etc...
In a poor attempt to be fair, I learned some cool stuff from almost all of these methodologies/philosophies.(OK, enough of being fair). Each one of these was sold as The solution to today's and tomorrows problems. If not by the author and authors sponsors, then by the management team that 'bought in from the top down -100% committed!) There are good things to be learned from each and every one of those methodologies/philosophies. But they are NOT solutions. They never were, and they never will be. They are tools! However we treat them as a pill you hand out while singing hymns of praise to the guy who wrote the white paper introducing this revolutionary approach to solving business problems, and pushing folks to do things they know won't work every time, and often not even most of the time.

I alluded to this in a response to the previously mentioned articles. What I have concluded from my contemplation regarding that writing thus far, and within the context of my experience is:

  1. There is no pill/formula/methodology/philosophy that provides solutions to problems
  2. There is a tendency to believe that #1 is not true.
  3. We substitute complexity for a basic lack of principled work ethic
  4. We encourage the "Magic Pill" by quickly promoting those who introduce "Magic Pills" instead of expecting them to live with the medication they foist on the rest of us, thus exacerbating #3
  5. Our metrics for measuring performance are as short sighted as most business outlooks: about a fiscal quarter in length
  6. Our metrics create competition where there should be collaboration and cooperation. Way too much focus on the individual as compared to the team, and more importantly: The work at hand.
  7. We take our pills regularly even though we know them to be doing more damage than good. We do this because we are afraid of being left behind.
What we need to do is:
  1. Be open to ideas, and flexible enough to adopt the pieces that work for us, while acknowledging that other pieces might work much better for others, even within the same department within an organization
  2. Be open to telling leadership what works and what does not, firmly, professionally, and without rancor.
  3. Be respectful to ourselves and thus to others around us in the work place. Competition is good in its time and place. In my experience, it is bad news when it carries into the job at hand.
  4. Be patient and honest with ourselves, our roles and our abilities.

    Not one of those "Magic Pills" ever delivers in the long term. They don't build skills, develop relationships, enhance productivity, or deliver on any of the other promised benefits. People do....we deliver, a system does not. A system is a tool until we let ourselves become tools of some silly system. Cart before the horse? It takes time to learn to use a tool, the more complex the tool the longer the time it takes... The focus needs to remain on the job at hand, not the tool to do the job. If the tool requires so much effort that it detracts from the focus on the job at hand, then it is the wrong tool.

  5. Be willing to be left behind for a while.

    Don't have to be Luddite like, but being in front is not always an advantage, and there are advantages to being at the back of the pack for a while. (I am reminded of the little creatures in Canada and Alaska that swarm up, start running, right over cliffs to their demise,,,lemmings?). Yeah, sometimes it is better to feel left out than it is to be included in a game of follow the latest leader.

The disturbing thing about that salesmen who is selling swimsuits to the drowning isn't the salesmen. It is the drowning people who buy from him. His pitch fits right in at the individual level in a system of levels that encourage pill popping. Face it: He would not be selling if we weren't buying... and we buy because we know we have little chance of advancing without proving we popped the pill corporate prescribed this week. The frustrating thing is that even if we take the meds, there is little chance that we will get any real good out of it. After all, to be a level II SCRUM master, you don't even have to know how to program.... End Rant:

Update: s/SCUM/SCRUM/ LMAO @ myself! :-)

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

Replies are listed 'Best First'.
Re^2: Selling swimsuits to a drowning man
by eyepopslikeamosquito (Archbishop) on Jul 17, 2014 at 12:19 UTC

    After all, to be a level II SCRUM master, you don't even have to know how to program
    Indeed. I've noticed that folks who strongly pursue the Scrum Master role as a career either cannot program at all or are mediocre programmers. Which I'm fine with, BTW, because I like to see talented programmers writing code, not running stand-up meetings. The Scrum Master role is essentially a management/co-ordination/facilitation role requiring organizational and people skills, not technical ability. It can be a tough gig too, based on this excerpt from a Ken Schwaber talk:

    You will have, if you use Scrum, someone on each team whose name is, it's called the ScrumMaster, also known as "The Prick". And this person's job is to make sure that you don't cut quality. D'oh. And they have no authority but they, what they can do is if we've defined that an increment has a certain level of quality for it to be demonstrated to our product management, their job is to make sure that quality's there. And if the quality isn't, not to let you demonstrate it, but instead to say to the product manager, "Hmph, we lost our heads, we're not done, it's gonna take us another month to finish this".

    This person is probably the least loved person in the world because they stand right at the nexus between product management believing that any amount of stuff can be done and our willingness to help them cut quality to support that belief.

    The burnout rate on these people is usually, like, 13 to 14 months. Throw 'em away. We often get them from hopeless, professional areas like QA. People in QA are used to doing incredible things with no authority, no respect, and no hope of success, so that's where we take these people.

    -- Ken Schwaber, Google tech talk on Scrum, Sep 5, 2006 (46:34)

    The Scrum Master role reminds me of the Political commissar, commonly attached to military units during WWII. The political commissar role was not created to do any actual fighting, rather to teach ideology and exercise social and political control over the soldiers, to guard against anti-revolutionary thought and action.

    On the subject of non-programmers making big bucks in the software industry, I'm reminded of this little piece from Joel Spolsky:

    The whole fraud is only possible because performance metrics in knowledge organizations are completely trivial to game. The best part is that most management consultants, the stunningly good-looking, bright, earnest chipmunks with 4.0s in Russian Lit from Harvard who work for these companies, have absolutely no way of knowing this, so they can go through this whole exercise without even knowing that they're doing it! They get all the way through the 2-year associate program on their way to MBA school without even realizing that they haven't done a goddamn thing about productivity, all they've done is caused a fairly pointless transfer of wealth from ExxonMobilConoco to BainMcKinseyGartner's senior partners. And it's a lot of fun! First class flights to Houston and Oslo! Helping the world be more productive! Rock on, young stunningly-good-looking Management Consultant.

      It suddenly occurred to me as I read this where a good portion of my discomfort with these methodologies comes from: The Military and my upbringing. Not that the two were all that similar in any other way than both consisted of consistent roles with well defined expectations and a consistent language describing and defining those roles and expectations.

      There are, to my way of thinking, some very good functional reasons for the rigidity of those role descriptions and definitions. The main one is that everyone knows their basic functions. They are simple:

      • Functional Skill Set - ex. Grunt, programmer, eldest sibling.

        In the service, everyone was a Grunt first. You had to know how to kill(shoot, toss things that go boom, set up stationary things that go boom when the other team was properly aligned as a target, avoid the other teams things that go boom, keep oneself reasonably serviceable in nasty environments, etc...) Everyone had the same basic skills and there were metrics, and if you didn't measure up, you were out(which is a big favor to everyone including the ousted; better ousted than dead).

        An individual on a development team should have the basic skills to program 'something'. Otherwise, they should not be on a development team. The basic metric is you can write some sort of functional code or you can't. If you can't, what the hell are you doing in software development?

        In the family, the eldest helps build the basic skill sets of the younger and protects them from ignorance. Up until their own ignorance/stupidity(in my case) gets in the way of that, which is when mom/dad step in and make sure the problem isn't being handed down the line. Some pretty simple metrics their too, though I am sure it varies from family to family.

      • Role - While the basic skill sets are common and expected, the role one plays on the team may vary.

        In the service it is rank and rank type(Officer/Enlisted). The skill sets may differ(supply vs motor transport), but even so, those support roles are still aimed at the basic skill sets which enable the core mission.

        In a development team, there may be a SCRUM master or a technical lead or a developer. Each has a role which is aimed at the basic mission which is writing serviceable software.

        In the family, well... I won't go there, as the roles in many families vary in many ways and often interchange, which is really cool. Never-the-less, the functioning families I have encountered have designated roles, and each knows what their current role is. Each role maintains the members of the family as well as the family unit itself.

      • Mission - Everyone knows the mission, their role in it, and how the basic skill sets apply, which roles are direct and which are in support. I will leave this point alone...

      The bothersome thing with all these methodologies is that they keep changing things up. What they all really boil down to (at least in my neolithic mind) are a constant re-shuffling of the basics above. That continual shuffling around undermines the basis of how I function. I need to have a clear understanding of what my role is and what the role of those around me is. I expect to be expected to understand and contribute at some level in the basic skill sets regardless of my role. I think part of the reason that this article hits the nail squarely on the head ( Joel Spolsky ) is that it becomes easy to 'game' a system when the system is in constant flux. When it comes to metrics in a changing system, about the only measurable thing is the change itself. Thus, the metrics become frustrating because the standard keeps changing, or at least the way it is talked about and understood.

      Every role needs to be based on the functional skill sets which get the job done. It may be organizational, or technical - manager or architect for example. That role is still based on applying the skill sets to the task at hand. I question whether one can do that without having a functional understanding of those functional skill sets. And that is another part of the reasons those hucksters sell what they do, the way they do... everyone wants the newest paddle for the canoe and they are so busy looking at paddles, they don't see the canoe drifting away...

      Ok. Enough... I will stop. (Past?)Time to get off my high horse... :-)

      ...the majority is always wrong, and always the last to know about it...

      Insanity: Doing the same thing over and over again and expecting different results...

      A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

      At this point, I’m mostly a “hybrid Business Analyst / Project Manager who has done a helluva lot of coding over the past 30 years.”   Which means that I have sat in that role, and I agree that it is tough.   However, the first thing that I say to a team (when it isn’t remote, as it most commonly is ...), is:   “please, sit down.”   And I take a seat next to my coffee.   The shocked looks are quickly replaced by smiles of relief.

      The next thing that I is to very briefly describe my own history, not in flowery terms, and to say, “Therefore, I know what I am doing – and, so do you.”   Raised eyebrows, smiles, “I’m from Missouri” glances.

      But this normally isn’t what team members are told:   they’re expected to be “rock stars” and tend to try to act the part ... not because they necessarily want to, but because they assume that all of the pressure, and all of the blame, rests upon their shoulders.   And, bluntly, they expect project failure.   No one ever told them (or, told the owners higher-up) that the project consists of building a software mechanism and that the work must be done in that way if it is to have any hope of success.   They are used to dealing with higher-ups who try to bribe them to do good work and to spank them if they don’t.

      I feel for – feel very badly for – the earnest folks who swallow these “methodologies” so willingly and then try to digest it.   Computer software-building is ruthlessly unforgiving of a misinformed approach, and it is much harder than it looks, for reasons that are not initially apparent.   (I guess you’ll have to buy a Kindle, but ... read that book.)

      - - - - -

      Right after graduating from undergraduate, I worked for the school and therefore had the opportunity to essentially get an MBA for free, from an excellent school.   I declined.   I knew that I knew nothing about business yet, let alone business administration, and that school wasn’t going to teach me that.   At least, not yet.   I never did go back and get one.

Re^2: Selling swimsuits to a drowning man
by sundialsvc4 (Abbot) on Jul 16, 2014 at 18:38 UTC
    After all, to be a level II SCUM master ...
    That wasn’t a typo, now was it?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1093919]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2024-03-28 11:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found