Layoffs

I’ve never been fired, but have been laid off three times over the course of four distinct careers. I’m also three-for-three for having landed in a much better place after having been laid off. So with three data points, maybe there is some truth to the street wisdom that a little adversity is a good thing.

“I judge you unfortunate because you have never lived through misfortune. You have passed through life without an opponent- no one can ever know what you are capable of, not even you.” – Seneca, On Providence, 4.3

I have also survived 17 layoffs. And I remember them all.

Paradoxically, many of the layoffs I survived were more painful than the layoffs in which I was included. I have clear memories of people I enjoyed working with that one day were simply gone from the place I was spending more than one third of my life. The resulting crash of morale at the workplace simply added to the sense of dread and “why bother” attitude. Their absence became a reminder that we were all living under someone else’s Sword of Damocles, that we would pay the price of poor decisions made by someone else. In some instances, the nauseatingly smug expression of schadenfreude by a few well-connected corporate parasites and toxic individuals cruising the corridors just added to the sting. It doesn’t seem this is easier to deal with by those that remain after a layoff in a distributed work environment.

To say I’ve “survived” all the layoffs that occurred throughout my multiple careers, whether I was culled or not, is more than a little melodramatic. I have truly survived much, much greater losses. Layoffs are not lethal events and living according to several key Stoic principles has helped me to persevere and gain strength from the brief storms of finding work.

“To bear trials with a calm mind robs misfortune of its strength and burden.” – Seneca, Hercules Oetaeus, 231232

Reflecting on work transition experiences, I wondered what is it about having been laid off that made the next place so much better.

I have always worked hard to add value to my employer’s business. If that value was either not appreciated or the business shifted away from needing the value I was capable and willing to provide, it was a clear sign that it’s time to move on. By making this a choice, I could leave with no hard feelings and no burned bridges. Psychologically, this is more intimidating but much healthier.

Seeing the positive side of being laid off can be a little more difficult, particularly if one has been blind to the signs that every company and manager broadcasts when a layoff is eminent and is surprised when they happen. For starters, layoffs erased all the baggage I was carrying that belonged to the employer and made it much easier to strike out in a direction that suited my interests, skills, talents, and goals. Each of the three layoffs launched new, more lucrative and rewarding careers.

“Today I escaped from the crush of circumstances, or better put, I threw them out, for the crush wasn’t from outside me but in my own assumptions.” – Marcus Aurelius, Meditations, 9.13

Switching employers, even careers, more frequently than previous generations is a good career development strategy. In the dot com era, it was the only effective way to find meaningful raises and career advancement. Why toil away for a decade under Management-by-Taylorism to scratch out incremental pay increases when a salary could be increased by 10%-20% just by switching employers? Twenty-five years on, staying with the same employer for more than five years actually looks odd to many recruiters I’ve been talking to.

A friend of mine has a personal policy to commit to an employer for 1,000 days. At that point, she decides if the workplace it meeting her goals and expectations. Doesn’t matter if it’s a shortcoming of her employer or if her goals and interests have changed – a mismatch is a mismatch so it’s time to leave. I think it’s a good policy, particularly in the Age of Information and Knowledge and distributed workforces.

A policy like this builds resilience in several ways.

1. It’s important to know what it takes to persevere with the crap work that goes with just about any job. Flitting from job to job doesn’t develop this. A 1,000 day commitment is enough to show that you made it past the “honeymoon” period every job has, have worked more than a few significant problems into solutions, and generally paid your dues and demonstrated – if only to yourself – you have the chops to do the work.
2. Deciding to leave a job and doing so multiple times throughout your life builds confidence in your abilities to create your future.
3. It adds a valuable layer to your talent stack, as Scott Adams has described it.

If it was generally known that employees had this policy, employers might expand their efforts to foster cultures that allow employees who are creative and collaborative to thrive and grow. Instead of what’s more common: Cube farms propped up by career leaches that brag about having worked at the company for 25 years when in fact all they’ve done is worked one mediocre year and repeated it 24 times.

I’m done with that. Forever.

“There are those too who suffer not from moral steadfastness but from inertia, and so lack the fickleness to live as they wish, and just live as they have begun.” – Seneca, On Tranquility of Mind


Photo by Benmar Schmidhuber on Unsplash

Show Your Work

A presentation I gave last week sparked the need to reach back into personal history and ask when I first programmed a computer. That would be high school. On an HP 9320 using HP Educational Basic and an optical card reader. The cards looked like this:

(Click to enlarge)

What occurred to me was that in the early days – before persistent storage like cassette tapes, floppy disks, and hard drives – a software developer could actually hold a program in their hands. Much like a woodworker or a glass blower or a baker or a candlestick maker, we could actually show something to friends and family! Woe to the student who literally dropped their program in the hallway.

Then that went away. Keyboards soaked up our coding thoughts and stored them in places impossible to see. We could only tell people about what we had created, often using lots of hand waving and so much jargon that it undoubtedly must have seemed as if we were speaking a foreign language or retelling a fish-that-got-away story. “I had to parse a data file THIIIIIIIIIS BIG using nothing but Python as an ETL tool!”

Yawn.

This is at the heart of what burned me out on writing code as a profession. There was no longer anything satisfying about it. At least, not in the way one gets satisfaction from working with wood or clay or fabric or cooking ingredients. The first time I created a predictive inventory control algorithm was a lot of fun and satisfying. But there were only 4-5 people on the planet who could appreciate what I’d done and since it was proprietary, I couldn’t share it. And just how many JavaScript-based menu systems can you write before the challenge becomes a task and eventually a tedious chore.

Way bigger yawn.

I’ve since found my way back into coding. A little. Python, several JavaScript libraries, and SQL are where I spend most of my time. What I code is what serves me. Tools for my use only. Tools that free up my time or help me achieve greater things in other areas of my life.

I can compare this to woodworking. (Something I very much enjoy and from which I derive a great deal of satisfaction.) If I’m making something for someone else, I put in extra effort to make it beautiful and functional. To do that, I may need to make a number of tools to support the effort – saw fences, jigs, and clamps. These hand-made tools certainly don’t look very pretty. They may not even be distinguishable from scrap wood to anybody but myself. But they do a great job of helping me achieve greater things. Things I can actually show and touch. And if the power goes down in the neighborhood, they’ll still be there when the lights come back on.

Good Intentions, Bad Results

In The Logic of Failure, Dietrich Dörner makes the following observation:

In our political environment, it would seem, we are surrounded on all sides with good intentions. But the nurturing of good intentions is an utterly undemanding mental exercise, while drafting plans to realize those worthy goals is another matter. Moreover, it is far from clear whether “good intentions plus stupidity” or “evil intentions plus intelligence” have wrought more harm in the world. People with good intentions usually have few qualms about pursuing their goals. As a result, incompetence that would otherwise have remained harmless often becomes dangerous, especially as incompetent people with good intentions rarely suffer the qualms of conscience that sometimes inhibit the doings of competent people with bad intentions. The conviction that our intentions are unquestionably good may sanctify the most questionable means. (emphasis added, Kindle location 133)

That sounds about right. To this I would add that incompetent people with good intentions rarely suffer the consequences of imposing their good intentions on others.

The distinguishing feature of a competent individual with good intentions and an incompetent individual with good intentions is the ability to predict and understand the consequences of their actions. Not just the immediate consequences, but the long term consequences as well. The really competent individuals with good intentions will also have a grasp of the systemic effects of acting on their intentions. People with a systemic view of the situation are deliberate in their actions and less likely to act or react emotionally to circumstances. Doesn’t mean they will always get it right, but when they fall short they are also more likely to learn from the experience in useful ways.


Photo by Michael Dziedzic on Unsplash

There Will Never Be an Agile 2.0…

…for the simple reason there was never an “Agile 1.0.”

Claiming to have crafted “Agile 2.0” would be like publishing the “Declaration of Independence 2.0” or “The Laws of Thermodynamics 2.0.” The Agile Manifesto is foundational. It is a statement of first principles that underpin a mindset from which a mountain of tools, techniques, frameworks, and practices have been created.

As to methods, there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.Harrington Emerson

As a tool, its utility comes from providing a stable base from which we can clarify complicated problems. Much of the 2.0 stuff I’ve read adds complexity and complication to a simple set of values and principles. In this regard it reflects research that shows people are more likely to add to solutions rather than subtract.

It’s this notion of a stable base that flummoxes people seeking to assign versions to Agile. First principles are often unassuming, their beauty and brilliance is masked by their seemingly simple codification of how things best work. Neither are first principles about absolute truths. First principles can have first principles. The first principles by which I use a wood plane are different from the first principles used by the tool manufacturer when milling the steel for the blade. My first principles of use inherit and extend the manufacture’s first principles of milling steel.

The Agile Manifesto identified elements in software development that are non-reducible. To be clear, there are other first principle elements not included in the Agile Manifesto and the Agile Manifesto doesn’t apply to every conceivable context. Twenty years of experience of applying it’s four values and twelve principles to other areas of business have revealed this to be true. They are not, nor will they ever be, an absolute truth. As our understanding of why they work so well improves, so will the underlying principles. Frankly, I’m impressed they have held up this well this far into the Internet Age. And I certainly don’t expect them to withstand every challenge or be as durable as the Declaration of Independence of the Laws of Thermodynamics.

So when I read someone’s declaration of “Agile 2.0,” the first thing I want to know is if their proposal precedes the first principles established by the Agile Manifesto or are they trying to do something else. So far, it’s always been the something else. There may be some interesting thoughts related to an alternate framework or perhaps a change to common practices, but I’ve yet to see anything revolutionary or even evolutionary.

A second thing I look for: Is the author working to falsify any of the principles and have they done a good job of presenting their argument. Again, this hasn’t happened. Mostly I read a lot of complaints about wording or ambiguity or history or stuff that is little more than efforts to tag the foundation with a personal style of graffiti.

I’ve yet to see Agile’s next evolutionary phase. I hope someday I will.


Image by 은주 송 from Pixabay

Cargo Cults in Management

 

I first read about cargo cults in Richard Feynman’s book, “Surely You’re Joking, Mr. Feynman.”

I think the educational and psychological studies I mentioned are examples of what I would like to call cargo cult science. In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they’ve arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas–he’s the controller–and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land. (p. 310-311)

I was a newly minted biochemist and Feynman’s unique perspective had a significant impact on my critical thinking skills. It established a “cargo cult” sensor in my brain. As my career developed and branched out into other areas of interest, the ubiquity of cargo cult thinking became apparent.

In the work place, “cargo cult” thinking may not necessarily be a bad thing. As a tool, it can be used as an “as if” frame for working out the solution to complex problems or gaining insight into black boxes. By assembling all the known and visible elements and arranging them to match the form as best as possible its easier to see what’s missing.

If an executive’s minions are behaving in a way that reflects his or her approach to management, is that a good thing? Here is where business leaders get into trouble. Are the executive’s minions imitating or implementing?

Less common, executives attempt to adopt practices that are successful at the knowledge worker level. About a decade ago I had worked to implement an Agile software development process with a small and highly capable development team. It was a daunting task: completely re-architect and develop a poorly coded application while supporting the old application. (In 30 years, this was the first and only time I recommended a complete redesign and rewrite of a major application.) Of course, we started each morning with a “daily scrum” meeting – sometimes called a “daily stand-up” – before the team set off to immerse themselves in code. These are very quick (15 minutes or less) meetings where everyone literally stands up for the duration of the meeting. The idea is that by standing, attendees are less likely to drone on about trivial matters or issues that do not require the entire team’s input. Complicated issues are quickly identified and scheduled for more detailed meetings, if necessary.

Six months into the project it was very clear our approach was working and insofar as the coding effort was concerned, we would be successful. The senior executive to this effort seemed impressed and decided to switch to a “stand-up” meeting format for the executive team meetings. They were “stand-up” meetings in name only. Rather than a once a week meeting that virtually always extended way beyond the originally scheduled 60 minutes, I now had to attend daily meetings that went on for 45-60 minutes during which nobody stood.

There were other issues with implementing the executive team scrum meetings. The senior executive did a poor job of modeling the behavior he sought and there was very little control over the clock. Developers are smart people and they notice things like this even though they are not directly participating. Among those being managed, it does little to inspire confidence in the management staff.

Nonetheless, I like the idea of applying Agile methodologies to management meetings. After action reports, as used by the military, would also help. There is also a place for storyboards and retrospectives. But implementing these and other elements would require a significant learning effort on the part of the management team. Not because the methods are difficult to understand, but because the MBA mindset of many management teams would have to loosen up a bit for the requisite unlearning to become possible.

Rethinking the idea of “management” in the context of Agile principles and practices blends quite nicely with many of the things I’ve learned around the idea of “Management as a Service.”

References

Feynman, R. P. (1985). “Surely you’re joking, Mr. Feynman!”: Adventures of a curious character. New York, NY: Bantam Books.


Image by Free-Photos from Pixabay

Expert 2.0

A common characteristic among exceptionally creative and innovative people is that they read outside their central field of expertise. Many of the solutions they find have their origins in the answers other people have found to problems in unrelated fields. Breakthrough ideas can happen when you adopt practices that are common in other fields. This is a foundational heuristic to open software development. Raymond (1999) observes:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this “Linus’s Law.” (P. 41)

So named for Linus Torvalds, best known as the founder of the Linux operating system. In the case of the Linux operating system, no one developer can can have absolute expert knowledge of every line of code and how it interacts (or not) with every other line of code. But collectively a large pool of contributing developers can have absolute expert knowledge of the system. The odds are good that one of these contributors has the expertise to identify an issue in cases where all the other contributors may not understand that particular part of the system well enough to recognize it as the source of the agony.

This idea easily scales to include knowledge domains beyond software development. That is, solutions being found by people working outside the problem space or by people working within the problem space in possession of expertise and interests outside the problem space.

Imagine, around 1440, a gentleman from Verona named Luigi D’vino who makes fine wines for a living. And imagine a gentleman from Munich named Hans Münze who punches out coins for a living. Then imagine a guy who is familiar with the agricultural screw presses used by winemakers, has experience with blacksmithing, and knowledge of coin related metallurgy. Imagine this third gentleman figures out a way to combine these elements to invent “movable type.” This last guy actually existed in the form of Johannes Gutenberg.

 

Assuming D’vino and Münze were each experts in their problem space, they very likely found incremental innovations to their respective crafts. But Guttenberg’s interests ranged farther and as a consequence was able to envision an innovation that was truly revolutionary.

But if you, specifically, wish to make these types of connections and innovations, there has to be a there there for the “magic” to happen. Quality “thinking outside the box” doesn’t happen without a lot of prior preparation. You will need to know something about what’s outside the box. And note, there aren’t any limitations on what this “what” may be. The only requirement is that it has to be outside the current problem space. Even so, any such knowledge doesn’t guarantee that it will be useful. It only enhances the possibility for innovative thinking.

There is more that can be done to tune and develop innovative thinking skills. What Bock suggests touches on several fundamental principles to transfer of learning, the “magic” of innovative thinking, as defined by Haskell (2001, pp. 45-46).

  • Learners need to acquire a large primary knowledge base or high level of expertise in the area that transfer is required.
  • Some level of knowledge base in subjects outside the primary area is necessary for significant transfer.
  • An understanding of the history of the transfer area(s) is vital.

To summarize, in your field of interest you must be an expert of both technique and history (lest your “innovation” turn out to be just another re-invented wheel), and you must have a sufficiently deep knowledge base in the associated area of interested from which elements will be derived that contribute to the innovation.

References

Haskell, R. E. (2001). Transfer of learning: Cognition, instruction, and reasoning. San Diego, CA: Academic Press.

Raymond, E. S. (1999) The cathedral and the bazaar: Musings on Linux and open source by an accidental revolutionary. Sebastopol, CA: O’Reilly & Associates, Inc.

 

Image by István Kis from Pixabay

Concave, Convex, and Nonlinear Fragility

Nassim Nicholas Taleb’s book, “Antifragile,” is a wealth of information. I’ve returned to it often since first reading it several years ago. My latest revisit has been to better understand his ideas about representing the nonlinear and asymmetric aspects of fragile/antifragile in terms of “concave” and “convex.” My first read of this left me a bit confused, but I got the gist of it and moved on. Taleb is a very smart guy so I need to understand this.

The first thing I needed to sort out on this revisit was Taleb’s use of language. The fragile/antifragile comparison is variously described in his book as:

  • Concave/Convex
  • Slumped solicitor/Humped solicitor
  • Curves inward/Curves outward
  • Frown/Smile
  • Negative convexity effects/Positive convexity effects
  • Pain more than gain/Gain more than pain
  • Doesn’t “like” volatility (presumable)/”Likes” volatility

Tracking his descriptions is made a little more challenging by reversals in reference when writing of both together (concave and convex then convex and concave) and mis-matches between the text and illustrations. For example:

Nonlinearity comes in two kinds: concave (curves inward), as in the case of the king and the stone, or its opposite, convex (curves outward). And of course, mixed, with concave and convex sections. (note the order: concave / convex) Figures 10 and 11 show the following simplifications of nonlinearity: the convex and the concave resemble a smile and a frown, respectively. (note the order: convex / concave)

Figure 10 shows:

So, “convex, curves outward” is illustrated as an upward curve and “concave, curves inward” is illustrated as a downward curve. Outward is upward and inward is downward. It reads like a yoga pose instruction or a play-by-play call for a game of a Twister.

After this presentation, Taleb simplifies the ideas:

I use the term “convexity effect” for both, in order to simplify the vocabulary, saying “positive convexity effects” and “negative convexity effects.”

This was helpful. The big gain is when Taleb gets to the math and graphs what he’s talking about. Maybe the presentation to this point is helpful to non-math thinkers, but for me it was more obfuscating than illuminating. My adaptation of the graphs presented by Taleb:

With this picture, it’s easier for me to understand the non-linear relationship between a variable’s volatility and fragility vs antifragility. The rest of the chapter is easier to understand with this picture of the relationships in mind.