Form Follows Function on SPaMCast 446

It’s time for another appearance on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast.

This week’s episode, number 446, features Tom’s essay on questions, a powerful tool for coaches and facilitators. A Form Follows Function installment based on my post “Go-to People Considered Harmful” comes next and Kim Pries rounds out the podcast with a Software Sensei column on servant leadership.

Our conversation in this episode continues with the organizations as system concept and how concentrating institutional knowledge in go-to people creates a dependency management nightmare. Social systems run on relationships and when we allow knowledge and skill bottlenecks to form, we set our organization up for failure. Specialists with deep knowledge are great, but if they don’t spread that knowledge around, we risk avoidable disasters when they’re unavailable. Redundancy aids resilience.

You can find all my SPaMCast episodes using under the SPaMCast Appearances category on this blog. Enjoy!

Advertisement

Innovation, Intention, Planning and Execution

 

Convergence is an interesting thing. Greger Wiktrand and I have been trading posts back and forth on the subject of innovation for almost eighteen months now (forty posts in total). I’ve also been writing a lot on the concept of organizations as systems, (twenty-two posts over the last year, with some overlap with innovation). The need for architectural design (and make no mistake, social systems like organizations require as much architectural design over their lifetime as any software system) and the superiority, in my opinion, of intentional architecture versus accidental architecture are also themes of long standing on this site.

My last post, “Architecture Corner: Good at innovation – Seven Deadly Sins of IT”, linked to a YouTube video produced by and starring Greger and Casimir Artmann. It’s worth the watching, so I won’t give away the plot, but I will say that it demonstrates how these concepts interrelate.

Effectiveness requires reasoned intentional action. I’ve used this Tom Graves’ quote many times before, but it still applies: “things work better when they work together, on purpose”.

The word “purpose” is critical to that sentence. The difference between intentional rather than accidental activity is the difference between being goal-directed and flailing blindly (n.b. experimenting, done right, is the former, not the latter). An understanding of purpose can allow a goal to be reached, even when the initial route to that goal is closed off. Completing a required set of tasks lacks that flexibility. This appreciation of the utility of purpose-oriented direction over micro-management is an old one that the military periodically re-visits:

An understanding of the purpose aids the joint force in exercising disciplined initiative to facilitate the commander’s visualized end state. Moreover, the purpose itself not only drives why tasks must happen, but also how subordinate commanders choose to execute their assigned mission(s).

Purposes must be carefully crafted, nested, and organized not only to achieve unity of effort, but also the intended outcomes (selected tasks to execute, method of execution, and/or desired effects). They also must give subordinates the latitude to find better, innovative solutions to tactical and operational problems. Finally, the operational purpose must ultimately nest back to the strategic national interest in order to affect change in the human domain. Purposes for the subordinate operations must be well thought out, nested within the desired operational objectives, and be the correct purpose in order to achieve the desired operational end state. Therefore, it is incumbent upon commanders to develop purposes for subordinate operations first and subsequently build the tasks. The “why” trumps the “how” both in importance and in priority.

What to accomplish and why are more important than how to accomplish something. As the author of article above noted, communicating purpose “…enables subordinates to take advantage of emergent opportunities that arise by enabling shared understanding of the commander’s purpose and end state.” It should also force those providing direction to examine their rationale for what they’re asking for. “Why” is the most important question that can be asked. Activity that is not tailored to achieving a particular aim will be ineffective. This includes chasing the latest silver bullet. A recent article on International Business Times, “As a term of description, ‘digital’ is now an anachronism”, had this to say:

As a term of description, digital is an anachronism. It reflects an organisational mindset that views technological transformation itself as the aim. It’s a common mistake. At the height of the dotcom boom, suddenly everyone needed a website, but not everyone understood why.

Over the last few years, the drive to digitisation has intensified. Business models, brands, products and services, customer relationships and business processes are increasingly governed by digital elements such as data.

But much the same as building a website in 1999, it’s not a question of becoming “more digital”. It’s a question of what you want digital to do.

Confusing means and ends is both futile and expensive. No matter how many tools I buy, buying tools won’t make me a carpenter (though my bank balance will continue to shrink regardless of whether the purchase helped or not). Dropping tools and techniques into a culture that is not able or prepared to use them accomplishes nothing. Likewise, becoming more “digital” (or for that matter, more “agile”), will not help an organization if it’s heading in the wrong direction. Efficiency and effectiveness are two different things that may well not go hand in hand. Just as important to understand, efficiency must take a subordinate position to effectiveness. You cannot do the wrong thing efficiently enough to turn it into the right thing.

You need to understand what you want to do and what the constraints, if any, are. That understanding will allow you to figure out how you’re going to try to do it and determine why the tools and techniques will get you there or not. The alternative is delay (waiting for new instructions) caused by the bottleneck of over-centralized decision-making with a high probability of something getting lost in translation.

Work together purposefully so things work better.

Go-to People Considered Harmful

Okay, so the title’s a little derivative, but it’s both accurate and it fits in with the “organizations as systems” theme of recent posts. Just as dependency management is important for software systems, it’s likewise just as critical for social systems. Failures anywhere along the chain of execution can potentially bring the whole system to a halt if resilience isn’t considered in the design (and evolution) of the system.

Dependency issues in social systems can take a variety of forms. One that comes easily to mind is what is referred to as the “bus factor” – how badly the team is affected if a person is lost (e.g. hit by a bus). Roy Osherove’s post from today, “A Critical Chain of Bus Factors”, expands on this. Interlocking chains of dependencies can multiply the bus factor:

A chain of bus factors happens when you have bus factors depending on bus factors:

Your one developer who knows how to configure the pipeline can’t test the changes because the agent is down. The one guy in IT who has access to the agent needs to reboot it, but does not have access. The one person who has access to reboot it (in the Infra team) is sick, so now there are three people waiting, and there is nothing in this earth that can help that situation.

The “bus factor”, either individually or as a cascading chain, is only part of the problem, however. A column on CIO.com, “The hazards of go-to people”, identifies the potential negative impacts on the go-to person:

They may:

• Resent that they shoulder so much of the burden for the entire group.
• Feel underpaid.
• Burn out from the stress of being on the never-ending-crisis treadmill.
• Feel trapped and unable to progress in their careers since they are so important in the role that they are in.
• Become arrogant and condescending to their peers, drunk with the glory of being important.

The same column also lists potential problems for those who are not the go-to person:

When they realize that they are not one of the go-to people they might:

• Feel underappreciated and untrusted.
• Lose the desire to work hard since they don’t feel that their work will be recognized or rewarded.
• Miss out on the opportunities to work on exciting or important things, since they are not considered dedicated and capable.
• Feel underappreciated and untrusted.

A particularly nasty effect of relying on go-to people is that it’s self-reinforcing if not recognized and actively worked against. People get used to relying on the specialist (which is, admittedly, very effective right up until the bus arrives) and neglect learning to do for themselves. Osherove suggests several methods to mitigate these problems: pairing, teaching, rotating positions, etc. The key idea being, spreading the knowledge around.

Having individuals with deep knowledge can be a good thing if they’re a reservoir supplying others and not a pipeline constraining the flow. Intentional management of dependencies is just as important in social systems as in software systems.

The Hidden Cost of Cheap – UX and Internal Applications

Why would anyone worry about user experience for anything that’s not customer-facing?

This question was the premise of Maurice Roach’s post in the Zühlke blog, “Empathise with your users or you won’t solve their problems”:

Bring up the subject of user empathy with some engineers or product owners and you’ll probably hear comments that fall into one of the following categories:

• Why do we need to empathise when the requirements tell us all we need to know about the problem at hand?
• Is this really going to improve anything?
• Sounds like an expensive waste of time
• They’ll have to use whatever they’re given

These aren’t unexpected responses, it’s easy to put empathy into the “touchy feely”, “let’s all hug and get along” box of product management.

Roach’s answers:

Empathy does a number of things, but mainly it increases the likelihood that the delivery team will think of a user and their pain points when delivering a feature.

If an engineer, UX designer or product owner will has sat with a user, watched them interact with their current software or device they will have an understanding of their frustrations, concerns and impediments to success. The team will be focused on creating features with the things they have witnessed in mind, they’re thinking about how their software will affect a human being and no amount of requirement documentation will give them that emotional connection.

…

Empathy can also help to develop a shared trust in the application development process. The users see that the delivery team are interested in helping to solve their problems and the product delivery team see the real users behind the application.

All of these are valid reasons, but the list is incomplete. All of these answer the question from a software development point of view. To his credit, Roach pushes past the purely technical aspects into the world of the user. This expanded exploration of the context is, in my opinion, absolutely essential. What’s presented above is an IT-centric viewpoint that needed to be married with a business-centric viewpoint in order to get a fuller picture.

Nick Shackleton-Jones, in his post “The Future Is… Organisational Usability!”, outlined on the problem:

Here’s how your organisation works: you hire people who are increasingly used to a world where they can do pretty much anything via an app on their iPhone, and you subject them to a blizzard of process, policy, antiquated systems and outdated ways of working which pretty much stop them in their tracks, leaving them unproductive and demoralised. Frankly, it’s a miracle they manage to accomplish anything at all.

As he notes, enterprises are putting a lot of effort into digital initiatives aimed at making it easier for customers to engage with them. However:

…if we are going to be successful in future we need to make it much easier for our people to do their jobs: because they are going to be spending less time with us, and because we want engagement and retention, and because if we require high levels of capability (to work our complex systems) then our resourcing costs will go through the roof. We have to simplify ‘getting stuff done’. To put it another way: in an ideal world, any job in your organisation should be do-able by a 12-yr old.

While I disagree that “any job in your organisation should be do-able by a 12-yr old”, Shackleton-Jones point is well-taken that it is in the interests of the business to make it easier for people to do their jobs. All aspects of the system, whether organizational, procedural or technological, should be facilitating, not hindering, the mission. Self-inflicted, unnecessary impediments are morale-killers and degrade both effectiveness and efficiency. All three of these directly impact customer-experience.

While this linkage between employee user experience and customer experience makes usability important for line of business systems (both technological and social), it has value for peripheral systems as well. Time people spend on ancillary tasks (filling out time sheets, requesting supplies, etc.) is time not spent on their primary duties. You may not be able to eliminate those tasks, but you can minimize their expense by making them quick and easy to complete. The further someone’s knowledge/skill/experience level gets from “do-able by a 12-yr old”, the bigger the savings by paying attention to this.

Rather than asking if you can afford to pay attention to user experience, you might want to ask whether you can afford not to.

Fixing IT – Too Big to Succeed?

Continuing our discussion that I mentioned in my last post, Greger Wikstrand tweeted the following:

BTW @GeneHughson, I think you'll enjoy our video on #serendipity youtu.be/BHVju9JbWDQ with me and @woodyzuill

—
Greger Wikstrand PhD (@GregerWikstrand) November 11, 2015

I encourage you to watch the video, it’s short (7:39) and makes some important points, which I’ll touch on below.

Serendipity, when it occurs, is a beautiful thing. Serendipity can occur when heads-down order taking is replaced with collaboration. Awareness of business concerns on the part of IT staff enhances their ability to work together with end users to create effective solutions. Awareness, however, is insufficient.

Woody Zuill‘s early remarks about the bureaucracy that gets in the way of that serendipity struck a nerve. Awareness of how to address a need does little good if the nature of the organization either prevents the need from being addressed. Equally bad is when a modest need must be bloated beyond recognition in order to become “significant” enough for IT intervention. Neither situation works well for the end users, IT, or the business as a whole.

So what’s needed to remedy this?

In “Project lead time”, John Cook asserted that project lead team was related to company size:

A plausible guess is that project lead time would be proportional to the logarithm of the company size. If a company with n employees has a hierarchy with every manager having m subordinates, the number of management layers would be around logm(n). If every project has to be approved by every layer of management, lead time should be logarithmic in the company size. This implies huge companies only take a little longer to start projects than medium-sized companies, and that doesn’t match my experience.

While I agree in principle, I suspect that the dominant factor is not raw size, but the number of management layers Cook refers to. In my experience, equally sized organizations can be more or less nimble depending on the number of approvals and the reporting structure of the approvers. Centralized, shared resources tend to move slower than those that are federated and dedicated. Ownership increases both customer satisfaction and their sense of responsibility for outcomes. Thus, embedding IT staff in business units as integral members of the team seems a better choice than attempting to “align” a shifting set of workers temporarily assigned to a particular project.

The nature of project work, when combined with a traditional shared resource organization, stands as a stumbling block to effective, customer-centric IT. IT’s customers (whether internal, external, or both) are interested in products, not projects. For them, the product isn’t “done” until they’re no longer using it. While I won’t go so far as to say #NoProjects, I share many of the same opinions. Using projects and project management to evolve a product is one thing, I’ve found project-centric IT to be detrimental to all involved.

Having previously led embedded teams (which worked as pseudo-contractors: employed by IT, with the goals and gold coming from the business unit), I can provide at least anecdotal support to the idea that bringing IT and its customers closer pays dividends. Where IT plays general contractor, providing some services and sub-contracting other under the direction of those paying the bills, IT can put its expertise to use meeting needs by adding value rather than just acting as order-takers. This not only allows for the small wins that Woody Zuill mentioned, but also for integrating those small wins into the overall operation of the business units, reducing the number of disconnected data islands.

Obviously there are some constraints around this strategy. Business units need to be able to support their IT costs out of their own budget (which sounds more like a feature than a bug). Likewise, some aspects of IT are more global than local. The answer there, is matching the scope of the IT provider unit with the scope of the customer unit’s responsibility. Federating and embedding allows decisions to be made closer to the point of impact by those with the best visibility into the costs and benefits. Centralization forces everything upwards and away from those points.

Operating as a monolithic parallel organization that needs to be “aligned” to the rest of the organization sounds like a system that’s neither effective nor efficient, certainly not both. When the subject is the distance between the decision and its outcome, bigger isn’t better.