Archive

Posts Tagged ‘management’

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.

P Equals R Minus C

Being a dufus, I’m constantly trying to use the power of abstraction (a.k.a selective ignorance) to syntegrate complex issues, problems, situations, and relationships up into ridiculously simple generalizations that are, of course, wrong. For example, take the classic business performance equation below.

In the sliver of dufus-land that aligns with reality, if revenues don’t consistently exceed costs, it’s just a matter of time before a new or established business goes kaput, no?

When a company starts up, by definition, it has only a handful of people who fulfill all of the roles in the right hand side of the above figure needed to prosper and develop. Over time, “approved” micro-specialization, infectious hubris, empire-building, and a whole lotta BS accompanies the obsession to”grow the enterprise“. These sanctioned behaviors usually (but not always) lead to an unsustainable and cost heavy behemoth that brings the party to an end – all under the eyes of the self-proclaimed brilliant dudes who run the show. Bummer.

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?

The Future Is Already Here…..

….for those people who are lucky enough to work in truly enlightened orgs that really walk the talk.

Check out this case study: “How Microsoft Netherlands Reinvented the Way of Work”. Yes, you read that right. It’s a division of that polarizing behemoth, Microsoft.

Just in case you don’t have the time, but you’d like the cliff-dozer00 notes version of the article’s highlights, here they are:

  • There are no assigned desks as well as no private offices for managers (not even the General Manager).
  • There are no physical “Departments”, each of the 900 employees of MS Netherlands can work anywhere in the office building by using a laptop, headset, webcam, or Windows based Smartphone and connecting to the network either wirelessly or by plugging in at a desk.
  • People are encouraged to work from home more often, whenever it is appropriate and are allowed to work whatever times they wish to work. The only requirement is that they “get the job done”.
  • If you wish to work until late at night on a project and take the morning to see your son’s school play, you can do that too – and you don’t have to ask your manager for the time off.

So, how can one judge whether these Theory Y policies have worked out? Managers love metrics (cuz metrics give them the illusion that they’re in control), so here are a few:

Of course, managers who who are dead set on clinging to their FOSTMA thinking UCBs (regardless of what they espouse) won’t believe the results; or they’ll play ostrich and ignore their existence – because it would take too much courage and “work” to effect a similar, massively positive change in their CCFs.

The Ideal Quadrant

Zappos.com operates on the simple principle that happy people make productive workers and productive workers make a successful enterprise. Thus, the policies and cultural accoutrements instituted at Zappos.com are thoughtfully and proactively designed to foster happiness without totally abdicating control. For Zappos.com, it’s not enough to have a “competitive” benefits and pay package – everyone (still in business) has to have one.

With that in mind, let’s explore the four quadrants in the simplistic table below. Right off the bat, we can ditch the two quadrants in the second row. After all, no org can remain viable for very long with an unproductive workforce – regardless of whether the emps are happy. No?

So that leaves us with the two quadrants in the first row. One would think that the holy grail for excellence-seeking orgs is the Productive-And-Happy (PAH) quadrant. However, a multitude of circumstantial evidence leads me to believe that most orgs are either consciously or unconsciously incompetent at catalyzing the development of a PAH workforce – regardless of what is espoused in the annual report. The legions of enterprises that fall into the CLORGs and DYSCOs category don’t even make an effort to develop “happy” employees. The SCOLs that run the show are too macho and they delude themselves into thinking that happiness doesn’t matter or it’s “not in their job description“. Should it be?

What comes first, productivity or happiness? Is one attribute a pre-requisite for attaining the other?

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?

My Accomplishments

May 16, 2011 7 comments

Here’s an idea. The next time you’re being formally evaluated for performance by a “superior” and he/she opines that your written accomplishments are vague, ask him/her for a copy of his/her latest accomplishments sheet – for guidance on how to do it right, of course.

Note: Thanks to Fish-dude for finding the matching Dilbert strip.

Unfathomable Vault

Via work breakdown structures, time cards, and other management tools, most orgs track the time its people spend on projects. Thus, over time, a significant database of historical cost and time data that can be reused to estimate the cost and schedule of future projects gets accumulated. Alas, BD00’s opinion is that most org controllers don’t leverage their treasure troves of information to get reasonable “rev 0” estimates of future efforts. Either :

  1. they don’t want to know the truth  – because they’ll cringe at how much time it really takes to execute an average project
  2. their tracking systems are so fragmented, un-integrated, and unnavigable that they can’t reuse the info – even if they wanted to
  3. both 1 and 2 above

It’s ironic how an average org’s controllers demand detailed planning and certainty from their teams but fail to demand the same standards for themselves, no? The next time you’re asked for a project estimate, try retorting with “what does the historical performance data in our unfathomable vault say about similar projects?“. Awe come on, you can do it – even though I can’t 🙂

Three Bottom Lines

“Management measures what’s easy, not what’s important.” – Unknown

“You can only measure 3% of what matters.” – W. E. Deming

I don’t recall where, but I remember seeing the idea of “three bottom lines” being proposed somewhere in an online article. The three bottom lines are “profits, people, and planet“.

As in quantum physics, the hurdle to overcome is “the measurement problem“. Unlike profits, which are simple to measure and track, how do you come up with standard, objective measures of an org’s effect on its people and on the planet?

Mangineers And Enginanagers

Expert Number 1 sez:

Engineers don’t make good technical project leaders because they lack business acumen. Thus, they’ll blow the budget and schedule.

Expert Number 2 sez:

Generic managers don’t make good technical project leaders because they don’t understand the work. Thus, they’ll blow the budget and schedule.

Non-expert BD00, who likes to make stuff up and fabricate his own truths, sez:

Yeah, that dilemma sux, but assuming that it can be done, it’s less costly in time and dollars to train an engineer in business skills than it is to train a generic manager in engineering skills.

Of course, if you assume that successful engineer-to-manager or manager-to-engineer cross training is unrealistic (and not many “mainstream” people would fault you for thinking that), then you won’t have to dirty your manicured nails or reach into your pocketbook to, as your fellow managers like to say, “get it done“. The result of this irresponsible, hands off approach is that you will continue to get what you deserve: all of your non-routine, technically challenging development (but not production) projects will blow the budget and schedule more than they normally would if you had put a mangineer or enginanager in charge. Whoo Hoo! Way to go Mr. and Mrs. FOSTMA. Stay the course.