Archive
Idea Approvability
The scientifically backed and indisputable graph below shows the “approvability” percentage of an idea as a function of the perceived (by the person(s) who have the power to approve the idea) distance of the idea’s implications from the status quo. For reference, traces for two example orgs are shown. How would you plot your org’s behavior on the graph?
The Only Means
Setting an example is not the main means of influencing another, it is the only means. – Albert Einstein
I stumbled upon the above Einstein quote while browsing Chetan Dhruve’s twitter page. One can set a good/bad example by:
- their day-to-day behavior,
- the quality of their work output, or
- (preferably) both of the above.
Since managers in DYSCOs and CLORGs are “above” work (shhhh – you’re not allowed to know and think that), they can only set an example by behavior. DICsters, however, can set an example using both approaches. Alas, it’s a real challenge to produce high quality work and behave as a role model when you’re continuously saddled with un-articulated goals that change on a whim, unreasonable schedules, and cleverly ego-centric managers. Nevertheless, it can still be done in spite of being immersed in a toxic environment. How do you do it?
Telltale Signs Of A Failed Software Project
Like everyone else who’s worked on a slew of team-based software development projects, uber C++ blogger Danny Kalev has his own thoughts on why projects fail. In “Telltale Signs of a Failed Software Project, Part I“, Danny ominously describes “The Emperor’s New Clothes Syndrome” as follows:
The first ominous sign is the emperor’s new clothes syndrome — as a new recruit, you try to study the project. You’re reading the specifications, perusing those lovely Data Flow Diagrams (DFDs) or UML charts and you still can’t get the hang of it. “What on earth were they thinking? It simply doesn’t add up!” you’re muttering silently. At some point you realize that it’s not you — it’s the project itself. What you’ve been reading is simply a collection of smoke and mirror effects meant to appease the high management. Little by little you get the picture: your colleagues know that it’s not working but they won’t admit it in public. If you dare exposing the truth you’ll be denounced as an ignorant, misfit traitor. You have two choices: quit silently, or join the rest, pretending all is well.
Hmm, I think Mr. Kalev may have missed the point that his second-to-last sentence; “exposing the truth and being denounced as an ignorant, misfit traitor“, is also a choice – albeit one that is auto-discarded by all sane persons. Ya see, if you’re not perceived to be a cross-eyed Columbo, a court-jester, or an innocent (but naive) child when you state your concern, you’re sure to get hosed down by the powers that be.
Have you ever tried to call-it-like-ya-see-it in front of the papal infallibles? If so, which halloween costume did you don? Columbo, Court-Jester, Innocent Child, or “other“? Surely, you’ve done it at least once, right? If not, why not? If so, then what kinda blowback did you receive – and did it force you into “quiet desperation” mode? Come onnnnnnnnn, don’t be shy – share your story with BD00 and the two other regular readers of this blog.
G-Spot
In chapter 3 of “In The Plex“, Steven Levy describes the culture within Google. Check out these “behaviors“…
The highlight of the TGIFs is always the no-holds-barred Q and A. Using an internal program called Dory, employees rate questions submitted online, with the more popular ones rising to the top. Brin and Page respond to even seemingly hostile questions with equanimity, answering them in all seriousness with no offense taken. In a typical session, someone asked why the newly hired chief financial officer had gotten such a big contract. Sergey patiently explained that the marketplace had set salaries high for someone filling that role and Google couldn’t fill it with a quality person if it underpaid.
Even more time is saved by Google’s ubiquitous “tech stops” spread about the buildings: these are, in essence, tiny computer shops, indicated by neon markers. When a piece of equipment fails or there is a sudden need for a new mouse or phone charger, all a Googler needs to do is walk no more than a few hundred feet to one of those locations, and almost instantly he or she will be made whole.
What are some of the behaviors, or (maybe more importantly) lack thereof, that your company exhibits that characterize its culture? Fuggedaboud what is espoused. What is actually “visible and feelable” that sets your company apart from the mooo-herd?
If you were an employee who saw evidence every single day that your company valued your presence, would you not be more loyal? The Montessori kids who started Google thought about those questions and asked, Why? Why? Why? If Google ever hits really hard times, it will be telling to see whether the sushi quality falls and the power chargers disappear from the conference rooms.
Complicated != Complex
For the non-geeks reading this post, the “!=” symbol is the C++ programming language token for “not equal“.
It seems like a lot of people think that classifying something as “complex” is the same as calling it “complicated“, and vice-versa. That conclusion can be, and often is, true, but it can also be false. I associate “complicated” with “not-understandable” – except to a select few experts. I think of “complex” to be the equivalent of something like “intricately elegant” and understandable to far more people than just experts.
Let’s take an example to illuminate my viewpoint. Assume that the black box system below functions delightfully. It’s reliable, responsive, easy to learn, and does what its users want without frustrating them in the slightest.
Now, in terms of complicated and complex, consider what the system may look like under the covers:
Of course, most users don’t give a shite what goes on under the covers, but the designing org and its people better well know what does – unless they luckily don’t have any competition to deal with, and hence, have their customers in a vice grip.
You see, at some point in time, the users will want improvements to the system as their needs evolve. If the original team of builders of implementation #1 are the only people who know the (so-called) design well enough to change it without breaking any existing capabilities, then the development org is hosed if those people leave. In effect, the org is held hostage by a small cadre of people. D’oh!
In the complex-complex implementation on the far right, even if the original builders leave the development org, the (relatively) elegant and well thought out design structure facilitates easy on-boarding of replacement builders. As an added bonus, the effort needed to add features and enhancements to the product is way less costly and risky than the other jaggedly complicated implementations.
So, given the portfolio of products in your org, how would you assess them in terms of the complexity and complicated attributes? If, and it’s probably a big IF, you could publicly communicate your assessment without fear of marginalization, or worse, how many people in your org do you think would publicly agree with your assessment? Uh, how abut privately? Would the number of public “agreers” match the number of private “agreers“?
Don’t Be Evil
If you don’t know that Google’s informal corporate motto is “Don’t Be Evil“, then either you were born yesterday or you shouldn’t be reading this ridiculously inane blog – or both.
While reading Stephen Levy‘s well written, informative, and entertaining book, “In The Plex“, Mr. Levy tells the story of how the controversial and tough-to-live-up-to Google war cry came into existence. Here, he describes the first triggering event:
Mr. Levy goes on to say:
Note that 15 employees were assembled from across a broad swath of the company. Do you notice something amiss? Uh, how about the fact that the two founders, Sergey Brin and Larry Page weren’t involved?
As the group debated the motto, here’s what one group member said:
Note that everyone had a chance to weigh in, and thus, “Don’t Be Evil” was internalized by the whole org. It wasn’t handed down from on high by a politburo or junta or God-like individual that “obviously knows what’s best for all the children in the borg“.
Did, or do, you have the chance to provide feedback on your corpo values or philosophy? Are they authentic like Google’s and Zappos.com’s, or are they a copy-and-paste job from a 1970’s vintage management book? If they’re a copy-and-paste job, have you suggested revisiting them? If so, how was your suggestion received?
Structure And Behavior
One of the principles of systems thinking is that structure facilitates or inhibits specific behaviors. For example, if we didn’t have hands (or, in some cases, neither hands or feet), we wouldn’t be able to write – the structure wouldn’t allow it. If we didn’t have vocal chords, we wouldn’t be able to speak – the structure wouldn’t allow it. If a car’s engine didn’t connect to the drive shaft, it wouldn’t be able to “transport” – the structure wouldn’t allow it. If a system didn’t have redundant elements, it wouldn’t be able to automatically recover from failures – the structure wouldn’t allow it.
The same holds true for organizational structures that group people together for a purpose. The org structure can be an enabler or inhibitor of the behaviors required to fulfill the purpose for which the group has been assembled. A mismatch between purpose and structure usually leads to failure at some unknown time in the future.
The table below lists several org structures concocted by BD00, including the ubiquitously pervasive and manager-revered “hierarchy“, along with the obscure, Fuller/Beer “octahedron“. What are the strengths and weaknesses of each structure?
Expertise And Position
In Seeing Your Company as a System, Andrea Gabor cites Weick and Sutcliffe’s book, “Managing the Unexpected: Resilient Performance in an Age of Uncertainty“:
Mindful organizations, they (Weick and Sutcliffe) explain, are characterized by a broadly defined “deference to expertise” in a setting where “expertise is not necessarily matched with hierarchical position.” Mindful organizations are also capable of seeing weak signals of systemic failure and responding with vigor. To support this capability, such organizations strive for open communication, recognizing that if people refuse to speak up out of fear, this capability will be undermined.
In unmindful orgs (“unmindful” is the politically correct way of referring to CLORGs and DYSCOs), most people in the borg are conditioned to auto-think that expertise equates to hierarchical position. Thus, the infallibles in the upper layers, while espousing otherwise, don’t strive for open communication and they ignore both weak and strong negative feedback signals from the DICs in the lower, less “expert” layers. To add insult to injury, since the DICsters down in the boiler room are conditioned to auto-think the same expertise-position relationship, they don’t “speak up” out of fear of looking, or being told that they are, stupid. Bummer.
Process, Passion, And Quality
Naive managers (usually those who get drunk on large quantities of 6-sigma, CMMI, ISO-90XX, EVM, and/or PMP kool aid) tend to think of the correlation between process and quality like this:
This cause-effect diagram can be read as “more process imposition leads to more quality; less quality leads to more process imposition“. What’s missing in this simplistic diagram? Could it be something that represents the human element?
In the blarticle, “Process kills developer passion“, James Turner writes about the human element of “passion“:
…passionate programmers write great code, but process kills passion. Disaffected programmers write poor code, and poor code makes management add more process in an attempt to “make” their programmers write good code. That just makes morale worse, and so on.
If you believe Mr. Turner, then the cause-effect diagram for process and passion is a self-reinforcing loop that may snuff out passion over time:
So, what about the relationship between passion and quality? I think that many would agree that it is thus:
When we integrate the two models above, we get….
Moving from left to right, and then from right to left we read that:
an increase in process triggers a decrease in passion, which triggers a decrease in quality, which triggers a further decrease in passion, which triggers an increase in process imposition. Round and round we go.
If we assume that “passion” is an integral player in the system, but hide it in the above diagram to simulate a common managerial blindspot, the end to end process-quality cause-effect diagram emerges as:
If we compare this derived result to the first naive manager mental model which doesn’t include the messy “passion” element, what’s the difference?
What’s On Your List?
In Russell Ackoff‘s “Idealized Design” method, he suggests that designers assume that the system they’re trying to improve/re-design exploded last night and it no longer exists. D’oh! He does this in order to put a jackhammer to the layers of unquestioned, un-noticed, outdated, and hard-wired assumptions that reside in every designer’s mind.
So, if you were part of an emergency task force charged with re-designing your no-longer-existing org, what candidate list of ideas would you concoct? To help jumpstart your underused, but innately powerful creative talents, here’s an outrageous example list that I stole from a raging lunatic:
- Provide two computer monitors for every employee and religiously refresh workstations every three years.
- Provide two projectors and multiple whiteboards in each conference room. Ensure a plentiful supply of working markers. No exclusive executive conference rooms – all rooms equally accessible to all, with negotiated overrides.
- Physically co-locate all product and project teams for the duration. Disallow a rotating door where projectees can come and go as they please or management pleases – with rare exceptions of course.
- Put round tables in every conference room.
- Distribute executive and middle manager offices throughout the org. No bunching in a cloistered, elitist corner, space, or glistening building with HR/Marketing/PR/finance/contracts or other overhead functions.
- Require every manager in the org with direct reports to periodically ask each direct report: “How can I help you do your job better?” at frequent one-on-one meetings. If a manager has too many direct reports – then fix it somehow.
- Require every manager who has managers reporting to him/her to ask each of his/her subordinate managers: “Can you give me an example of how you helped one or more of your direct reports to grow and develop this year?“.
- Require periodic, skip-level manager-subordinate meetings where the manager triggers the conversation and then just listens.
- If “schedule is king” all the time, then write it into your prioritized core values list – just above “engineering excellence and elegant products“. If your core values list contains conflicting values, then prioritize it.
- Carefully and continuously monitor group (not individual) interaction protocols and behaviors. Diligently prevent protocol bloat and convert tightly coupled, synchronous client-server relationships into loosely couple, asynchronous, peer-to-peer exchanges.
- Explicitly budget X days of user-chosen training to every person in the org and enforce the policy’s execution.
- To reinforce why the org exists and de-emphasize who is “more important” than who, publish a product and/or service-centric org chart with products/services across the top and groups, including all managers, down the side. Preferably, the managers should be on the bottom propping up the org. (See figure below).
- Abandon the “employee-in-a-box” classification and reward system. Pay each person enough so that pay isn’t an issue, and publicly publish all salaries as a self-regulating mechanism.
- Create policy making and problem solving councils up and down the org. Members must consist of three levels of titles and include both affectees in addition to effectors.
- Give leadees a say regarding who their leaders are. Publicly publish all reviews of leaders by leadees.
- Require periodic job rotations to reduce the org’s truck number.
- Frequently survey the entire org for ideas and problem hot spots. Visibly act on at least concern within a relatively short amount of time after each survey.
- Provide every employee with an org credit card and budget a fixed amount of money where no approvals are required for purchases. Fix the purchasing system to make it ridiculously easy for expenses to be submitted.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 