What you need: Complexity Mindset

Organizations that are too rigid cannot adapt to changing economic conditions, demand, prices, interests, shocks, and crises. Problematically, an enterprise can grow quite large while preserving its rigidity in the medium-run, delaying the need to adapt until the industry as a whole has a crisis (airlines, automobiles, etc).

Thus, my first book focused heavily on the need to build and cultivate tension within an organization to ensure that continuous experimentation preserves adaptive complexity.

One example that humanity has struggled to grasp, is the adaptive complexity of a system that relies on individuals who need to be a mix of selfishness and altruism. Standard economics is largely built on the axiom of rational self-interest, that individuals have static preferences and will optimize marginal returns on margin investment. For instance, when I have $10 to spend, I will maximize the utility or value of my spending, based on information, rational self-interest, and prices.

Behavioral Economics, however, has shown us that the choices we make are often quasi-rational at best. Any parent who has gone grocery shopping with a young child knows that gut-feel, intuition, snap decisions, and a desire to get the complex decisions of a stressful shopping trip over with, leads to less-than-perfect spending decisions. Anecdotes aside, research has proven a growing list of fallacies and biases that are consistent across gender, race, culture, and intelligence–from anchoring our conclusions based on whatever information we receive first, to an optimism bias that our success is more likely than the average success rate.

As Hoff and Stiglitz review, there is strong evidence for treating individual actors within a system as encultured actors, partly depending on social context and expectations to determine the best decision.

We can each fit the standard model of classic economics during “slow-thinking”. Under observation, we act rationally self-interested as long as we have perfect information and sufficient time for deliberation. The rest of the time, we are swept up in our action-packed schedules, engaged in thousands of quasi-rational decisions. We copy what has been successful for others, act agreeable when the impact of a decision is unclear, and rely on our past experiences to maintain the habits that have worked so far. This “fast-thinking” is not static, however. The research is very clear that we can be manipulated in very subtle ways, toward selfishness, mistrust, polarity, and dishonesty. Likewise, with enough changes to social context, education, and time, the weak can be strong, the forgotten can be outspoken, the rigid can grow again.

So, who would you like to be?

While I will present the science behind complexity thinking in lean-agile organization development in future posts, the real question that I am left with is, “Who would I like to be; who should I hope to become?” Naturally, there is no perfect answer to this. Personal identity is a question of strategy, in its own way; you can only choose so many vocations, specialties, social contexts, and roles. To be enormously successful in one arena is a trade-off against other opportunities.

One thing, however, is entirely clear. To the extent that our quasi-rational behavior allows us to rely on several “identities” based on mental schema, role models, behavioral narrative, and social norms, isolation within any one institution and ideology is a dangerous prison. We are only free to determine our own path to the extent we know those paths exist. We can only adopt the best mental schema for an unknown decision by having as many modes of thinking as possible at our disposal. We can only carve out the best self-identity as the exposure to new options, cultures, and role models permit.

Frankly, if we are all very honest, we find it easiest – because is simple, familiar, and less scary – to remain stuck in the simplistic modes of thinking we developed as children. Good-baby/Bad-baby, Good-mommy/Bad-mommy, Good-worker/Bad-worker… and yet, when we view the world as a complex adaptive system, it is true of humanity that the health of the forest is so much more complex than can be observed tree by tree. Sometimes we need mother-soldiers, brother-florists, teacher-friends and so on. So my call to action is not to choose a single destiny and blindly pursue it; my imperative to you is see all the paths, invent a hundred identities, meet every kind of person, think through the lens of your worst enemies. Only by expanding your vocabulary, experience, and exposure to the full complexity of the world can you hope to say, in the end, “I chose who I have become.”


Hoff K, Stiglitz J. “Striving for balance in economics: Towards a theory of the social determination of behavior” Journal of Economic Behavior & Organization, 2016, vol: 126 pp: 25-57


Blog SEO: 5 Simple Techniques to Start Doing Now

1 – Easy-to-Read urls

Use urls that indicate the subject of each post, not numbers. Deep-linking (linking straight to a page) may be bad for security on some portals or throw off your conversion funnel analytics in commerce, but a blog should represent an interrelated series of ideas.

Pro Tip: This probably makes your urls so long that they are hard to properly Tweet. In Social Media, use Buffer, Hootsuite, or SproutSocial to shorten the url and auto-schedule the timing of your post.


2 – Link to Your Old Posts

Anytime you write a new post, think of how it relates to at least one previous post you’ve written, and link to the previous post within the new post. This means you need to know your blog contents. It is nice that a Blog can let you explore new topics on the tangents of your profession, but if you can’t create some sort of emergent cohesion, no reader and no bot or spider will do it for you.

Pro Tip – If you are a member of a team that manage a blog with a TON of posts, read a new post from months or years ago each day. React to it, link to it, write about it.


3 – Link to Your New Post

Anytime you add a new post, find an old post that is related and insert a link to it. The easiest way to do this, naturally, is to use the post you linked in #2. It will be better for your readers if there is a logical place to include it within the content of the previous post, but adding a “Recommended reading” section at the end of a post can help as well.

4 – Tags and Images

The easy thing here is to make sure you start naming any images so that they have meaning independent of the image. Using headers to organize the content of a post should be a no-brainer as well. If you’re bootstrapping and crunched for time – its never too late to start doing it better going forward with more discipline. If you’re a big business with a massive site, an SEO consultant who can dive into your code is a useful ally.  What may not realize is most SEO experts will give you a fair amount of information for free. Just ask!

5 – Have Fun!

Okay but seriously, the most important thing that will improve your SEO is to create content you care about. Take pride in the topic. Take the discussion with you into the real world. If the blog is an authentic “shadow” of who you are or who your organization strives to be, people will find it interesting. Find interest groups on Twitter and Snapchat and LinkedIn – then CARE. If you don’t care about your craft, no one will. If you don’t love blogging about your craft, no one will care about your blog.

The DevOps Secret that IT Won’t Tell You

DevOps. SAFe. Scrum. Kanban. Did you shiver? The experts have you scared you’re doing it wrong (you know, IT – all of IT). The certificate-teachers need you to need them so they can get paid. The coaches and consultants are taxing your #FOMO (Fear Of Missing Out) on ALL THE AGILE.

Get. Real.

It’s an impossible dream: The perfectly lean and agile software process would be just one person – a masterful engineer with great people skills and business acumen who can hang around a group of people to see what troubles them, create an intuitive software tool that relieves the pain, and collect cash from them while obtaining ultra-constructive feedback. In other words “dev” and “ops” as one person.

Ever seen that happen?

That said, every additional person involved in the flow of DevOps information is either a value-addition or a source of systemic waste. More often, everyone involved is a bit of both. As more bodies are thrown at a problem, it is likely any one of them can only spend 10-20% of their time actually adding value. The other 80% – and all overtime – is typically waste due to waiting on information from others, or over-documenting our value-add so others can consume it.

So it isn’t that IT won’t tell you the secret, if they know at all. It’s easy to crack jokes about how little other people accomplish despite working long hours, but less likely that anyone raises their hand and volunteers the truth about how much time is wasted.

– Waiting for clarification

– Waiting for updates to install

– Waiting for SVN code check-in

– Waiting for someone else to check their code, setup a VM, or answer what their code means

– Waiting for the next meeting

– Waiting for the inspiration to work on something meaningless to you

The great big DevOps secret is that no methodology will fix all that waiting. Over-specialization creates a world in which teams throw big piles of shit over the fence, each group speaking it’s own language that no other group understands. New philosophies won’t fix bad relationships, a toxic culture, and shit tools. It takes time, work, and fearless leadership.

Otherwise, Agile, Scrum, Kanban, and DevOps – or any other recipe for “when to meet” and “what to document” – are like 30-day fad diets; it’s a false hope and a gimmick and it doesn’t change the sedentary fast-food lifestyle that keeps you fat in the first place.

FREEDOM: How using Scrum un-impedes our full potential!

Scrum frees teams from the tyranny of the urgent:

A key goal of the Scrum transformation is breaking the parent-child relationship between “business” and “development”.  Technical planning, implementation, commitment, and delivery is in the hands of the team while the Product Owner provides a single priority-order backlog of consolidated items from stakeholders, users, and the developers, for the team to plan around.  Once a well-formed-team finds the right mix of XP and Lean practices (especially continuous integration and frequent releases) the pressure of “we have to do this now” is easy to manage.  If major items frequently pop up mid-week on a “release train” that deploys weekly:

  • The team leaves room in their commitment for these items
  • The Product Owner sets realistic expectations with stakeholders on which release will include the request

This is part of the power of Lean planning for making strategic product and release decisions – once the Minimum Viable Product is in the open market, data from the users can determine urgency of backlog items.  Frequently, this is a point where a pivot is desirable.  Through frequent releases, the users, stakeholders, and the team can relax and look at the big picture, free from the fear arbitrary deadlines and urgent scope “creep”.

Scrum frees teams from the fear of making mistakes:

While the extreme co-dependency that drives the tyranny of the urgent is overcome by putting an end to arbitrary deadlines and poor scope decisions, the fear of making mistakes is overcome through the key roles defined by Scrum.  Note, these are roles and this label is intentional – these are NOT by necessity positions or titles.  As I describe in Why Product Owners? a role is the confluence of empowerment, responsibility, and accountability for One Big Thing that rests on the shoulders of a single person.  Teams are free to voice ideas because the Scrum framework encourages collaborative implementation planning, cross-functional brainstorming, and constant discovery of best practices.  With XP Pair Programming, this becomes even easier as a single screen and keyboard gets two minds and four eyes that can converse on best practices, mitigate against knowledge silos, and build team relationships.  In the end, all of these adults acting brilliant and mature, huddled around a problem still have the Product Owner as the proxy to the users and stakeholders.  The team is free to determine one small solution at a time, just-in-time, and just-enough – then iterate or pivot.  When tough decisions need to be made, the Product Owner makes the call, relying on the expertise of the team, sets expectations, and maintains accountability.  Moreover, the user story – as the building block of incremental product delivery – isolates risk of mistakes to the smallest valuable user interaction and continuous integration ensures that when a new increment is not “potentially shippable” it can be easily taken out until additional iteration is completed.

Scrum frees organizations from business as usual:

When things go wrong in a large Waterfall project, multiple helpless Project Managers ask for updates but are unable to check boxes, development teams are powerless to drive the direction of the product, and stakeholders become progressively frustrated by the unfinished pit into which money is being thrown.  Then they cancel the project!  What is missing here?  JOY!  Menlo Innovation’s Richard Sheridan and author Joy, Inc. describes the importance of team joy in an interview with InfoQ:

There is in fact tangible business value to joy. But understand this: our focus is external to the organization. What we want more than anything else is that the work of our hearts, our hands, and our minds gets out into the world and delights people. That’s our definition of joy. We want somebody to stop us on the sidewalk and say, “That thing you built, I love it. Thank you. You made my life better.”

When I build a new Scrum team, guiding them with the help of my Scrum Master through the process of forming, storming, norming, this is the number one fear I must guide them through:  I say “Yes, the requirements will change.  Yes, what you build today will be modified tomorrow.  What matters is that you are a creator, people will actually use what emerges, and it will make a difference to them.”

The move from cancelled projects to meaningful user feedback has an incredible impact on an organization.  The drive to constantly improve, tighten feedback loops, and evolve through empirical process control will make disruption the norm and remove the fear of inevitable change and new ideas.

Scrum frees organizations from process rigidity:

There are three overarching goals driven by the roles, ceremonies, and artifacts in Scrum:

  1. Notice ineffective processes, workflows, or behaviors quickly and cease them.
  2. Notice effective processes, workflows, or behaviors communicate this knowledge
  3. Recommending new processes or practices that can be tested for the length of a sprint

At the organization level, the same process should occur.  While the empirical methodology monitoring “the process” – a mix of lean, XP, and other function-specific practices – is held constant, the practices that are monitored within “the process” are under constant review at the team and organization levels.

At this year’s ScrumAlliance Global Scrum Gathering in Phoenix, Arizona, I attended a terrific session  “Scrum at Scale – Free yourself from the myth of one-size-fits-all scaling led by Scrum Inc.’s Alexander Brown.  Look for an upcoming post on his argument that Scrum is by definition modular and object-oriented, such that organizations scaling Agile, Scrum, Lean, and XP can utilize empirical process control and a mix-and-match approach to the various frameworks most appropriate to the unique needs of each team.