Posted on

Slack

In one of my earlier blog posts, Tolerance for Failure, I noted that having an appropriate tolerance for failure from your team is necessary to promote a culture of innovation. Of course, there are many other things that an organization must have besides the willingness to allow employees to stretch.  One of the more significant items is the capacity for innovation.

Innovation comes in many sizes, as do organizations.  Having the capacity to allow innovation is not related to the size of the organization. Nor is it related to having a dedicated research department, process teams, etc. Small, incremental innovation has come from the freedom to effect change that is somewhat outside of the normal expectations of the work to be accomplished.  This freedom comes from having a bit of slack in the day to perform outside of the box.

Tom DeMarco says that Slack is the “degree of freedom required to effect change. Slack is the natural enemy of efficiency, and efficiency is the natural enemy of slack.” Unfortunately, a lot of organizations are systematically eradicating slack in the pursuit of efficiency. With the goal of being ever more efficient, we’ve converted personnel resources into a commodity to be managed. We’ve leaned down the organization to do more with less. We’ve implemented matrix organizations to gain further efficiencies from fungible employees. Each of these reduces or outright eliminates any slack that could have allowed for experimentation and innovation. 

I’ve found that engineering organizations are no different, especially for those with projects that have significant front-end effort requirements for design and testing prior to product sales.  Engineering accounting practices for these project-based organizations are moving towards absorption costing and the capitalization of engineering effort rather than treating engineering costs as overhead expenses, as was mainly done in the past. While this does make the financials look better, it puts a direct cost burden to the project on each hour of engineering effort for that project. As a result, effort that doesn’t directly and efficiently apply to the project is discouraged by the project managers as it adversely affects the project efficiency of each effort hour and raises the project cost.

How do these organizations then innovate?  For some, especially the smaller ones, they don’t.  Consider the 15 tile sliding tile game.

Perfectly efficient sliding tile game.

Plugging a 16th tile into the game increases efficiency by using the wasted space. But now with no open space, it is impossible to rearrange the tiles.  The organization of the tiles is stagnant.  Would the organization be better if it counted down from 16? Went down the column first instead of across the rows?  This organization may never know as they no longer have any slack for experimentation and innovation. Additionally, if the organization is smaller or in an industry with narrow profit margins, it likely doesn’t have resources dedicated to process or product innovation.  These organizations need slack to have the capacity for innovation.

The old saw about doing the same thing and expecting different results does apply to being more effective. Slack is a way to invest in change to have the necessary capacity for innovation.

Stay tuned….

Posted on

The Fog of Optimism

I tend to be an optimistic person, as are most of the people that I’m around. I just generally find optimistic people to be more pleasant and ready for the next adventure, whatever it may be. One of the things my father always said was to why worry about what you can’t control, and in most cases, I agree with his philosophy. However, there is at least one area I’ve experienced in my life and especially in my career where a little pessimism is a good thing.

Making estimates. We all make several estimates a day, sometimes without even being aware of them. Can I stop the car in time at this speed? How much pasta should I prepare? How long will it take my daughters to get ready to leave? (Answers: Stopping – Yes, but not without making my wife nervous; Pasta – Always over-estimated; Daughters – mostly under-estimated.)  I find that I am optimistic in my estimates and things usually take longer or involve more supplies than I originally envisioned. I want the task of painting the garage to go quickly, so I succumb to the Fog of Optimism for my estimate.

While I am very seldomly held accountable for these faulty estimates, the estimates that I make at work are a different story.  Moreover, on the job, there are additional pressures to make optimistic estimates. Perhaps the boss is concerned that Parkinson’s Law will kick in and the work will expand to fill the available budget and schedule. Or there could be a mindset that optimistically estimating the project and having a shortened schedule will result in a sense of urgency that will prevent people from procrastinating on the important details while they work on the more interesting but less impactful items. The Sales organization may have information that the competition is quoting a lower non-recurring engineering charge for the project, and we will be less competitive on the bid with a less optimistic estimate of the work. Whatever the reasons, there usually is powerful pressure to present an optimistic estimate in the workplace.

In my own experience, I’ve seen two significant and related causes of the Fog of Optimism. The first is ignoring history. If it took over 10,000 hours to do the work for past projects, why would we now think that it will only take 5,000 hours this time? The fog of optimism tends to make us forget how those 10,000 hours were consumed. And it is likely that the estimates for those previous jobs were also in the 5,000 hour range, and we are just not learning from our experiences.

The second is that we don’t want to have our competence questioned. Of course, we aren’t going to make those same budget blowing mistakes again, are we? Having pessimism for our future performance can be a pretty uncomfortable position. Julie Norem, a psychology professor at Wellesley College said of pessimism: “The biggest negative impact potentially comes from other peoples’ reactions. If you’re doing it out loud, other people tend not to like it. They tend to have questions about your competence.” The perceived implication that we may not be the right person or team for the job can certainly bias the estimate towards the optimistic, especially as we are likely to weigh the immediate impact of the estimate over the long-term responsibility of the results.

Steve McConnell, in his book Software Estimation – Demystifying the Black Art, details the various methods for making better estimates.  He quotes Fred Brooks in saying “It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.” By following a more formal estimation method, the influence of both pessimism and optimism can be reduced. Maybe the point I should be taking from my Dad’s philosophy is to focus more on the control part. But until then, having a little pessimism rather than optimism can be helpful to improve the accuracy of the estimates.

Stay tuned….

Posted on

What is a System Engineer?

Have you ever had trouble explaining to people what your job was?  If so, you might be a System Engineer.

Granted, most people outside of a few disciplines have never heard of a System Engineer, so it is not surprising that they don’t know what one does.  The problem is, there really isn’t an easily distilled set of responsibilities that can be captured in a few words or a couple of sentences for Systems Engineering.  A Civil Engineer at a party can always explain that they “design bridges” (or “targets”, as one of my Aerospace Engineering roommates in college would say.) And in just a few words, even an Underwater Basket Weaving major has a pretty good idea what the Civil Engineer does.  The same goes for Electrical Engineers (computers), Software Engineers (smartphone apps), Mechanical Engineers (lawn mowers), and even Biomedical Engineers (the Six Million Dollar Man).  While my listing is somewhat farcical, it illustrates that most people can relate to what those engineering disciplines create, even if it is at a superficial level.

This is not the case for System Engineers. If you Google “System Engineering”, you get IT System Engineers (not what I’m talking about) and a bunch of circular definitions that use the term System to define System Engineering. (By the way, a circular definition is a definition that is circular. Helpful, no?)

Wikipedia says “Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design and manage complex systems over their life cycles. At its core, systems engineering utilizes systems thinking principles to organize this body of knowledge. The individual outcome of such efforts, an engineered system, can be defined as a combination of components that work in synergy to collectively perform a useful function.” Well, OK, but if I’m at a party and someone uses the term “synergy”, that is my que to extract myself to go get another libation.  And it still uses “complex systems”,  “systems thinking principles”, and “engineered system” in the definition – does anyone know what these are?

At the heart of it, System Engineers take customer needs and translate them into solutions. This typically involves:

  • Architecting solutions from component products to meet a higher-level goal or requirement.
  • Develop, derive, and manage requirements for technical solutions that meet the goals and objectives of a product or project.
  • Provide direction for product development to better meet business needs such as cost reduction, time to market, reuse, and/or customer satisfaction.
  • Understand and apply standards, norms, and regulations to project deliverables and equipment.
  • Apply RAMS (Reliability, Availability, Maintainability, and Safety) requirements to project deliverables and equipment.
  • Perform advance proof-of-concept studies for project risk reduction.
  • Participate in Verification and Validation activities.

Having been a system engineer for part of my career, I usually just said that “we figure out what something should do and then tell the other engineers what is needed to make the things do what they should.” So, basically, we’re the megalomaniacs of the engineering world, depending upon the practitioners of other engineering disciplines to figure out the details.  I’m convinced that Heinz Doofenshmirtz probably was a System Engineer at some point in his career, prior to his campaign to assert his systems thinking principles across the entire Tri-State Area. And why not, having that kind of power can be corrupting, if only it wasn’t so hard to explain at parties.

Stay tuned….

Posted on

Tolerance for Failure

What kind of boss are you?  Do you promote an environment with an acceptable tolerance for risk or are your actions and policies creating a workspace where failure and risk cannot be allowed?

I’ve had both kinds of bosses in my career.  Fortunately, my first boss understood that risk tolerance was necessary to allow his new engineers to excel. One of his first directives to each new hire was “if you don’t burn something up once in a while, you aren’t trying hard enough.” This set a level of expectation that we were to stretch a bit and take calculated risks, within reason, of course! While he didn’t define the period of “a while”, we understood that the occasional goof was expected and not the end of the world.  What a wonderful environment to get the most out of each individual.

I contrast this to one of my later bosses.  His style was to pit each of us against our peers to  “inspire” us to greatness, all the while complaining that we didn’t work well together as a team.  One of his favorite tactics was to tell each of us a slightly different version of his goals to keep us at odds. His tolerance for risk was essentially zero, which made even our successes seem like failures.  Nothing was ever good enough or met his demanding expectations.  After a few months of favorable results from this approach, the team’s effectiveness eventually stalled and further gains were stymied. Risks like contrary opinions and suggesting alternate approaches were discouraged in favor of the safer blind adherence to the boss. As a result, a “Yes Man” mentality emerged, which was further cultivated by this boss.  Ultimately he failed but not without first causing stress to the organization and to his people. Worse, we also failed to grow during his tenure in part due to his low level of risk tolerance.

Note that when discussing tolerance for failure I’m not talking about Risk Appetite, which is more of an organizational definition of risk tolerance. Very few organizations can tolerate “bet the company” risks.  Since it is his company, Elon Musk can do this. The rest of us with risk adverse bosses and boards have incentive to be good stewards of the company, its employees, and the customers, and manage our risks accordingly. But there needs to be  some level of risk tolerance in order to improve. A company where everything is safe can all too easily stagnate and may eventually become irrelevant in the marketplace. Your team is the same – when you allow your people to stretch in little ways, their performance and value can improve as a result.  And the way you encourage them to take on small risks and your tolerance of their stumbles as they learn can make all the difference.

As a topic, risk and risk management is one of the most important areas for project and organizational management. Having an appropriate tolerance for failure from your team is necessary to promote a culture of innovation on multiple levels.

Stay tuned….

Posted on

Measuring Productivity

When I was just a young engineer and managing a small electronics and software development team, my boss asked a question that I couldn’t answer then or for many years afterwards. And I imagine that you may also have the same trouble I did.

It isn’t that his question was wrong or illogical – it wasn’t. It was just that there was no good way to get to an answer that would satisfy his question. And any answer, especially for my boss, who was not a software expert and had little or no experience with software engineering or its practices, was likely to not be received well with the level of qualifying statements I needed to add to the response.

But he was a manager, and the question interested him from that point of view. And it was a simple question so he expected a simple answer.

So for the question. My boss came to me and said that he had been reading that software coders in Freedonia (with apologies to the Marx Brothers) are much more efficient than coders in the US. In fact, they can produce 400 Lines of Code (LOC) per day. How many LOC do your engineers produce? How do you measure their productivity?

Well, first of all, we didn’t measure LOC. And even if we did, my engineers were creating different types of software, and at the same time doing Systems Engineering work, Software Quality work, etc., so it is meaningless to try to compare a LOC metric to the Freedonia coders, especially when the metric is not properly defined.

Today we have all sorts of measures and metrics for software development that were not widely known or used back then, and some of them hint at productivity. Most, however, when used properly, really show us how well the team is working, and by extension, areas where process improvement may have its largest return. There is Velocity, Burn Down, Customer Satisfaction measures, etc. The list goes on and on. And these measures are most useful to tell us where to focus our attention on things that may positively or negatively affect productivity, rather than to directly compare against another team or industry. However, when measures are compared to others doing similar work, any significant difference in the value of the measure should elicit the question “What are they doing that we aren’t”, and hopefully it isn’t just that they measure it differently!

For me, the answer wasn’t any of these. What I thought was important was to see how well we were performing against our estimates, since our estimates were used in the bid for the work. If we weren’t profitable then generally our productivity was questioned, and since it is hard to manage what you don’t measure, gets us back to the original question. Our answer was to use Earned Value to give us a comparison to our work plan, and as a side benefit it provided useful real-time feedback on how work was progressing on that plan. So the definition of productivity was related to our variance to the plan.

I’ll get into Earned Value in another blog post, and there are many good resources on the web for EV. I know you may be thinking just inflate your initial estimates and productivity will improve. However, since we wouldn’t get any more work by pricing ourselves out of the market, there was always intense pressure to improve and to be optimistic in our estimates. The fog of optimism will be another future blog post. Earned Value worked for us, and not just for software engineering, but all engineering disciplines where standard work is not applicable.

Stay tuned…