{"id":1128,"date":"2020-09-08T07:01:33","date_gmt":"2020-09-08T07:01:33","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1128"},"modified":"2020-09-08T07:01:34","modified_gmt":"2020-09-08T07:01:34","slug":"dont-be-a-sheep","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2020\/09\/08\/dont-be-a-sheep\/","title":{"rendered":"Don\u2019t be a sheep"},"content":{"rendered":"\n
\"\"
Image by Susanne Jutzeler from Pixabay\n<\/figcaption><\/figure>\n\n\n\n

During a meeting this week, I had to think of a famous quote by Margaret Mead: \u201cNever doubt that a small group of thoughtful committed citizens can change the world; indeed, it\u2019s the only thing that ever has.\u201d The two senior leaders to whom I was talking complained about their R&D organization doing everything right on paper from an Agile, data-driven perspective, but still ending up with building humongous, inflated features that were released after many months of development.<\/p>\n\n\n\n

This is of course a classic example of feature creep many companies \nfall into. When exploring how the situation developed, the discussion \nmade clear that a very small number of influential people in the R&D\n organization had managed to convince the others that the initial plan \nof releasing a minimal viable feature wasn\u2019t possible as it would cause \nangry customers.<\/p>\n\n\n\n

I don\u2019t want to focus on feature creep but rather on the ways a vocal\n minority in an organization, or even society at large, can have an \nimpact that far exceeds the size of the group. In general, I\u2019m a big \nproponent of a small group of individuals taking charge to initiate \nchange within an organization. Even if the senior leaders pride \nthemselves on leading major changes in their organization, almost always\n some individuals had been pushing for and championing the change for \nquite some time before it was picked up by senior management.<\/p>\n\n\n\n

The challenge with \u201cthe vocal minority,\u201d as I often refer to it, is \nthat their success often depends more on the ability to use rhetoric and\n debating techniques than on the actual, technical nature of the change \nthat is being advocated. The consequence is that individuals may \npassionately argue for changes that are detrimental to the organization \nand its members. To evaluate the relevance and validity of the proposed \nchanges, I typically apply four questions or tactics. advertorial \n<\/p>\n\n\n\n

The first test to which I subject a change proposal is to evaluate it\n against the fundamental principles I consider to be true. One of these \nis that faster feedback cycles are better than slower ones. This means \nthat arguing for inflating a feature and consequently delaying its \nrelease, as well as the associated feedback goes against the argument \nfor including more in the feature. My general rule of thumb is that work\n items should be kept to a size that allows one team to complete it in \none sprint.<\/p>\n\n\n\n

The second question I ask is whether the proponent of the change has \nconsidered a sufficiently broad scope of impact. It\u2019s very easy when \nproposing a change to focus exclusively on the topic at hand and how to \naddress it, without considering the broader scope. For instance, \nreleasing larger features may offer more relevant functionality to a \nwider subset of customers, but it may also decrease the (perceived) \nquality of the system as it\u2019s harder to test a large chunk of \nfunctionality than it is to test a small slice.<\/p>\n\n\n\n

The third test is to explore second-order effects. In a famous story,\n Mao Zedong ordered all sparrows in China to be killed as they ate \nseeds. The second-order effect was an explosion of the locust \npopulation, causing a famine resulting in the death of millions of \npeople. In software engineering, a well-known case is incentivizing \nsoftware engineers to use code from a shared code library to increase \nsoftware reuse. This has caused all kinds of interesting effects, \nincluding engineers first checking in their code into the shared code \nlibrary and then \u201creusing it\u201d to get their bonus. Although it often is \nvery difficult to predict second-order effects, it\u2019s generally possible \nto generate relevant hypotheses that either can be tested or for which \nat least circumstantial evidence can be collected.<\/p>\n\n\n\n

The final mechanism I use is to explore if it\u2019s possible to run \nsmall-scale experiments that provide additional evidence concerning the \nproposed change. The challenge with the first three tests\/questions is \nthat these are based on argumentation and reasoning and not necessarily \nfounded in empirical reality. It\u2019s critical to complement the beliefs \nthat underlie the reasoning with tangible, empirical data to increase \nthe confidence that the change will have the intended outcome and avoids\n unwanted side effects.<\/p>\n\n\n\n

Concluding, in my experience, virtually all change in organizations is initiated by a \u201cvocal minority.\u201d This minority often relies on rhetoric and debating techniques to gain influence, rather than the quality of their proposal. This requires all of us to critically reflect over change suggestions. I\u2019ve described four techniques that I use to evaluate these proposals. Rather than submitting to some form of herd mentality, it\u2019s the responsibility of each and every one of us to maintain independent and critical thought, independent of peer pressure. Don\u2019t be a sheep!<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at <\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>) or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em>\n\t\t\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\tCategories <\/p>\n","protected":false},"excerpt":{"rendered":"

During a meeting this week, I had to think of a famous quote by Margaret Mead: \u201cNever doubt that a small group of thoughtful committed citizens can change the world; indeed, it\u2019s the only thing that ever has.\u201d The two senior leaders to whom I was talking complained about their R&D organization doing everything right … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1128"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1128"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1128\/revisions"}],"predecessor-version":[{"id":1130,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1128\/revisions\/1130"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1128"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1128"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1128"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}