Posts Tagged ‘productivity’

Multiple, Independent Sources Of Information On The Same Topic

July 3, 2014 1 comment

I can’t rave enough about how great a subscription is for writing code. Take a look at this screenshot:

Five Books Open

As you can hopefully make out, I have five Firefox tabs open to the following C++11 programming books:

  1. The C++ Programming Language, 4th Edition – Bjarne Stroustrup
  2. The C++ Standard Library: A Tutorial and Reference (2nd Edition) – Nicolai M. Josuttis
  3. C++ Primer Plus (6th Edition) – Stephen Prata
  4. C++ Primer (5th Edition) – Stanley B. Lippman, Josée Lajoie, Barbara E. Moo
  5. C++ Concurrency in Action: Practical Multithreading – Anthony Williams

A subscription is a bit pricey, but if you can afford it, I highly recommend buying one. You’ll not only write better code faster, you’ll amplify your learning experience by an order of magnitude from having the capability to effortlessly switch between multiple, independent sources of information on the same topic. W00t!

The Drooping Progress Syndrome

September 21, 2013 Leave a comment

When a new product development project kicks off, nobody knows squat and there’s a lot of fumbling going on before real progress starts to accrue. As the hardware and software environment is stitched into place and initial requirements/designs get fleshed out, productivity slowly but surely rises. At some point, productivity (“velocity” in agile-ese) hits a maximum and then flattens into a zero slope, team-specific, cadence for the duration. Thus, one could be led to believe that a generic team productivity/progress curve would look something like this:

steady increaseIn “The Year Without Pants“, Scott Berkun destroys this illusion by articulating an astute, experiential, observation:

This means that at the end of any project, you’re left with a pile of things no one wants to do and are the hardest to do (or, worse, no one is quite sure how to do them). It should never be a surprise that progress seems to slow as the finish line approaches, even if everyone is working just as hard as they were before. – Scott Berkun

Scott may have forgotten one class of thing that BD00 has experienced over his long and un-illustrious career – things that need to get done but aren’t even in the work backlog when deployment time rolls in. You know, those tasks that suddenly “pop up” out of nowhere (BD00 inappropriately calls them “WTF!” tasks).

pop up task

Nevertheless, a more realistic productivity curve most likely looks like this:

decreasing productivity

If you’re continuously flummoxed by delayed deployments, then you may have just discovered why.

productivity cycle

An Estimation Example

October 17, 2010 Leave a comment

The figure below shows the derivation of an estimate of work in staff-hours to design/develop/test a Computer Software Configuration Item (CSCI) named YYYY. The estimate is based on the size of an  existing CSCI named XXXX and the productivity numbers assigned to the “Real Time” category of software from the productivity chart in Steve McConnell‘s “Software Estimation: Demystifying the Black Art“.

Of course, the simple equation used to compute effort and all of the variables in it can be challenged, but would it improve the accuracy of the range of estimates?

Add Managers And Hope

September 2, 2010 Leave a comment

The figure below shows the result of two attempts to increase the productivity of a hypothetical DICteam. In this totally concocted and fictional example, the nervous dudes in the penthouse (not shown in the figure) keep adding specialized managers to the team to fill voids that they perceive are keeping performance from improving. However, since the SCOLs never baseline the TEAM_VALUE_ADDED metric before each brilliant move, or track its increase or decrease with time, they have no idea whether they have achieved their goal. Because SCOLsters think they’re infallible, they just auto-assume that their brilliant moves work out as expected.

Of course, it often turns out that SCOLster decisions and actions do more harm than good. As the graph in the figure for this bogus example shows, not only did the team operating cost increase by the addition of two new manager salaries to the total, the team productivity decreased because of the additional communication and coordination delays inserted into the system. Add an additional “hidden” operating cost due to the high likelihood of jockeying and infighting between the three BMs (to gain favor from the penthouse dudes), and the system performance deteriorates further. Bummer.

So how can SCOLs increase team performance without throwing more useless overhead BM bodies at the problem? For starters, they can clearly communicate the gaps they “see” to the single team coordinator and help him/her rise to the challenge by providing mentorship and advice. They also can replace the BM with a competent, non-BM (fat chance). They can also (heaven forbid) invest in better tools, infrastructure, and training for the one coordinator and team of DICmates – instead of investing that money in more BM specialists. Got any more performance increasing alternatives to the standard “add managers and hope” tactic?

Esther Tweets

August 31, 2010 Leave a comment

I’m passionate about all aspects of software development, including, uh, project management (I really am). Since Esther Derby is an insightful and pragmatic thinker filled with valuable tips, techniques, and methods for successfully executing hairball software projects, I follow her on Twitter. Check out this trio of sequential tweets.

My answer to Esther’s last question is: “It would be great!“. Alas, most managers don’t, or aren’t allowed to, think in terms of systems. Systems thinking isn’t valued in siloed, CCH corpricracies, so managers have no incentive to learn or apply it’s principles and techniques for continuous improvement. In really badly run orgs, it’s too dangerous for one’s career to think or act horizontally in silo-city. It’s too bad, because orgs of people are richly interactive dynamic systems of systems that require constant shepherding to keep every person and every group and every unit aligned and connected.

What Happened To Ross?

September 4, 2009 Leave a comment

In the ideal case, an effectively led company increases both revenues and profits as it grows. The acquisition of business opportunities grows the revenues, and the execution of the acquired business grows the profits. It is as simple as that (I think?).

ROS (Return On Sales) is a common measure of profitability. It’s the amount of profit (or loss) that remains when the cost to execute some acquired business is subtracted from the revenue generated by the business. ROS is expressed as a percentage of revenue and the change in ROS over time is one indicator of a company’s efficiency.

The figure below shows the financial performance of a hypothetical company over a 10 year time frame. In this example, revenues grew 100% each year and the ROS was skillfully maintained at 50% throughout the 10 year period of performance. Steady maintenance of the ROS is “skillful” because as a company grows, more cost-incurring bureaucrats and narrow-skilled specialists tend to get added to manage the growing revenue stream (or to build self-serving empires of importance that take more from the org than they contribute?).

Constant ROS

For comparison, the figure below shows the performance of a poorly led company over a 10 year operating period. In this case the company started out with a stellar 50% ROS, but it deteriorated by 10% each subsequent year. Bummer.

Deteriorating ROS

So, what happened to ROS? Who was asleep at the wheel? Uh, the executive leadership of course. Execution performance suffered for one or (more likely) many reasons. No, or ineffective, actions like:

  • failing to continuously train the workforce to keep them current and to teach them how to be more productive,
  • remaining stationary and inactive when development and production workers communicated ground-zero execution problems,
  • standing on the sidelines as newly added “important ” bureaucrats and managers piled on more and more rules, procedures, and process constraints (of dubious added-value) in order to maintain an illusion of control,
  • hiring more and more narrow and vertically skilled specialists that increased the bucket brigade delays between transforming raw inputs into value-added outputs,

may have been the cause for the poor performance. Then again, maybe not. What other and different reasons can you conjure up for explaining the poor execution performance of the company?

Productivity Lag II

In part I, we saw that the learning curve for each person is different (duhhh). I also defined the Critical Mass Time (CMT) to be the time lag between starting a new project and actually being able to “start contributing something useful”. The figure below recaps this idea.

productivity 1

Other factors, besides experience and expertise, that determine the CMT value are: the amount of, the quality of, and accessibilty of pre-existing information about the problem to be solved. If the information is sparse, fragmented, and/or inefficiently stored in other people’s fallible memories (tribal knowledge) because of the failure of management to lead, then the CMT will be larger than if  the critical-to-success information is coherent, integrated, and recorded somewhere that is easily navigable and accessible.

At the CMT point, productivity starts manifesting in the physical world as visible intermediate work outputs. Product specifications, designs, test definitions, equipment assembly, prototyping, model definitions, etc., begin to emerge and push the project forward. Like any activity that is predicated on fallible human thought, the creation process is iterative and chaotic. It is not smooth and organized as the final output may imply to an after-the-fact external observer (like most managers). It takes iterative, mistake-prone work and structure to temporarily harness the ever present increase in entropy.

The figure below shows the full time lag between project start and project completion. Again, the time lag ‘tween CMT and project “done” is highly person-specific.

One And Done

The figure below shows the end-to-end project start time to project done time for three different people that were given the same project task to perform. The difference between the total “schedule” performance of person 3 and person 2 is the case we want to zoom in on. How could it be that person 2 ramped up faster than person 3 but finished the project later? WTF?

Three And Done

Some reasons that may explain this anomaly are:

  • Person 3 had a hard time finding and absorbing high quality, pre-existing information about the project and task at hand.
  • Person 3 is slower at learning, but more talented at applying.
  • Person 2 lost some motivation for one or more reasons and slacked off somewhat
  • Person 3 rushed through the task and produced crappy output that may not be discovered until the project is further downstream; where the cause might not be connectable to the person’s output.

I’m sure that there are a gazillion other factors that may explain the anomaly. You can form your own list.

The main point of this article was to discuss what everyone knows, but often forgets: Numbers don’t always tell the truth. Superficially looking at hard and cold “schedule performance” numbers without digging in to examine their validity can be unfair to those who are quantitatively measured for personal performance evaluation by hierarchs. Lazy bozo managers who do this deserve what they get: the exodus of some of their best performers, an unmotivated workforce, a low quality product portfolio, and an unfair reward system. In essence, it’s one of the hallmark characteristics of the herd of mediocracies that cover the landscape of the business community.

Productivity Lag I

Each person naturally has a different learning curve. When an engineer is assigned a new task to perform on a new technical project, there will be a lag in productivity because, well,  it’s new to him/her. The person needs time to learn and understand the context surrounding the project and the details of the problem to be solved. Since each person is different, each person will have a different time-to-productivity, or Critical Mass Time (CMT). The graphic below shows a typical learning curve for a specific person. The slope increases with time because as new learning occurs, it feeds on itself and the acquisition of knowledge gets easier.

productivity 1

The CMT is a physically underive-able function of the experience and expertise (two independent qualities) of a person. It is also a function of the area of overlap between those two attributes and the novelty/depth of the problem to be solved. As the figure below shows, the person-specific CMT is at its minimum when there is 100% overlap. Note that if there is no overlap, the CMT is essentially infinity. This sad state can happen, for example, if a Radio Frequency circuit designer is assigned the task of designing and writing product software, or a plumber is assigned to perform brain surgery, or an enterprise IT software engineer is assigned the task of writing embedded signal processing software. It’s easy to find other examples of total mismatch.

productivity lag

Assuming that the experience and expertise of each person in a group of people overlaps somewhat with the project task that needs to be performed (no cases where CMT = infinity), the graphic below shows how CMT differences within the group can vary radically. Obviously, if you were a manager, you’d like to have Person 1 working the problem.

productivity 4

So what happens when an executive manager or marketer commits the company to a scheduled project completion date without knowing the learning curves of his/her people, or the difficulty of the problem to be solved? As the figure below shows, blown schedules occur. Before (and after) the schedule is missed, increasing pressure-to-complete is continuously exerted by management, mistrust grows, and the employee-management relationship suffers. Of course, since management is (at least) one level removed from the action and they don’t have to perform the task themselves, they are blameless. Because of the FAE, the employee, of course, is fully at fault and a “performance improvement” plan may be in order. If an employee ruffles feathers and dares to publicly point out the mismatch, accusations of “not being a team player“, “malcontent“, and/or “bad attitude” are the thanks he/she gets. If the employee persists, the ostracism may be followed by a stronger message to STFU – a required trip to “people-skills school“.


This pattern of dysfunctional behavior occurs so often in hierarchical corpos across the land that it is taken for granted and it is “undiscussable“. It is also one of the reasons why people do everything they can to get out of the pig sty and climb the corpo ladder to succes. The further away from the action you move, the higher the chance that  you’ll be sanctioned by the big boys(gals) to convert from a pressure-receiver into a pressure-exerter. As an added bonus, you’ll make more money because of your “increased responsibilities” (sic).


June 19, 2009 2 comments

Over the years, I’ve read quite a few books and articles on managing the soft side of an organization. In many of these info sources, I’ve seen the term FAE = Fundamental Attribution Error mentioned. The FAE represents the tendency of a manager to instinctively and unthinkingly blame a person’s character and/or work ethic for under-performance. The real cause, which cannot possibly be true in a corpo manager’s conditioned mind, is likely that his/her inability to create, nurture, and continuously sustain a helpful, supportive, learning work environment is killing productivity and creating under-performers.

Of course, the FAE cannot account for all under-performance in an absolute sense. There are self-made underperformers (like BD00) in every org, regardless of the quality of the surrounding work environment.


Heaps And Systems

A “heap” is a collection of individual “parts”. A “system” is an intentionally  designed set of interconnected parts with a purpose.  The purpose of a system transcends AND includes the purpose of each of the individual parts. As an example, think of an automobile. If we disassemble one, we end up with a heap of individual parts. When these parts are assembled and interconnected in accordance with the purpose of human transportation as the goal, we may get a system. Structural design and interconnection are not enough.  The system must be energized and steered so that purposeful behavior can be manifested. For a car, the energy is fuel and the steerer is a human being. For an organization of mutli-disciplined groups of people, the energy is motivation and the steerer is a leader. Without motivation and a leader, an organization of human groups is just an unproductive heap that consumes natural resources and doesn’t produce any value added output to share with the world.

The figure below shows two companies that are each comprised of 4 potentially diverse and productive groups of people. Company A is unconnected and leaderless. Thus, it just consumes resources from the external environment and produces nothing of value to share with the world. Company B is both connected and well led. What kind of company do you work for?

Heap And System Companies

Look at company C in the illustration below. In this company, the leader has propelled his/her company to the head of the pack by creating the internal environment for, and nurturing the system’s internal groups and interfaces for peak performance. All of the internal connections and relationships between the groups are comprised of low latency and high bandwidth collaboration. Both high quality outputs and speed of execution distinguish company C from the rest of the herd.

Peak Org Performance

In a high performing system, the danger of over-optimization looms in the form of inflexibility. A system optimized for a single purpose tends to harden and become resistant to change overt time – corposclerosis sets in. The trick for the leader is to create and sustain a delicate balance between optimization and flexibility that adapts with the rapidly changing external environment.

In an attempt to over-optimize performance, some leaders unknowingly morph into “managers”. They start inserting subordinate management layers of questionable value between themselves and the productive subsystems of the company. They start creating and accumulating titles that distance themselves from the productive groups. These and other symbols of status divide and alienate instead of integrate and endear. Instead of guiding, steering, and nurturing, they start commanding, controlling, and constraining.  Productivity plummets and quality of workmanship deteriorates.

Layer Upon Layer

Because of increasing rules and procedures mandated by management, the internal interfaces between the formerly productive groups start transitioning into high latency and low bandwidth communication channels.  In the worst case, like an overheated engine, the interfaces rupture and the system abruptly disintegrates; leaving an unconnected and purposeless heap of parts in its wake. Bummer.

Busted Company

%d bloggers like this: