DesOps Process – Putting the Human Back into the Value-Creation Process in the Enterprise

After the pause and exploration into the DesOps / DesignOps area of roughly a year and half, I am back, with with some reflections with the focus on “Process”.

Unlike the early years, back in 2013-14, when I had started with design automation to make the life of the designers easy; gradually started writing about connecting different stages of SDLC to Design for optimising the PM-Design-Developer handovers, coined the DesOps as the next step to with a design centric DevOps philosophy in 2017-18, and wrote about the DesOpsDesignOps as a next-wave in design — now it has taken a centre-stage in various design related debates and posts. Also many organisations are now more than curious in trying out the new philosophies shared by various design thought-leaders and experiment with the newly opened roles.

Thanks to all of those who remained in touch, and shared their unique stories of experiences and challenges in various organisations they serve at various roles including design. These helped me immensely to evaluate concepts against scenarios and do the litmus-testing around the real life use-cases.

Starting with this 2nd series, with the topic, that was initiated from an old time friend and well-know member of the design community, who asked me about the perspectives around the design leadership role in DesOps.

 

Traditional View of Human as (is) a Resource!

During beginning of industrial revolution, the enterprises brought various processes to the organisation and the product creation and delivery journey in order to achieve optimisation and improve efficiency.

When we talk about “Just in time” and other similar processes are purely functional models, where time or resource is at the centre. These processes gradually got matured and got transferred to the modern day and thereby today’s organisation inherited many processes from these that dealt with product creation, delivery, marketing and managing resources.

In the industrial revolution era, humans associated were seen as resources by the organisations. They were similar to other resources required for the product or service life cycle to operate and run. No surprise that we have Human Resource (HR) departments in the organisations.

Most of the processes put into practices were associated with how to procure resources and optimally use them as part of the whole life cycle. The organisational policies formed were around these philosophies. For example, the rules in hiring, managing working hours construct, creation of the vertical-roles and responsibilities came into existence through such policy creation.

These helped the organisation run the operations required to successfully manage the value creation and delivery roles. Because of these many roles gradually came into existence as part of organisational structure, which were mostly modelled on such processes and the responsibilities. During these processes were built around either process optimisation or automation perspective or efficiency perspective.

So what was excluded from these, is the “human” himself. The functional centric processes prescribed the actions and boundaries around different roles, without considering the role being associated with a human-being and there by needing the “empathy” angle. That’s why there are many policies and organisation-cultures are shaped by these processes are in most of the cases are not able to support the some of the modern-day philosophies like “Open Organisation”, where empathy plays a greater role to shape the culture as well as the processes.

The organisations like RedHat and others who deal with open source communities had to break the bounding box beyond each role and break the vertical org-structure at least at the bottom of the pyramid otherwise it would not have been possible to operate in the open source community, where the contributors or the team may spread across the globe unlike the traditional industrial revolution concept of an enterprise.

Many of the contributors to some of the key and flagship open source products available online were contributed by house-wives or working-mother who use to commit code in their spare time. These team members traditionally do not fit into any ‘fixed role’ or the “working-time” construct.

In today’s post pandemic world when most of us are working from home for our organisations, the old traditional human resource concept of any role and the policies and process around it start falling apart. Many organisation have now started exploring the workaround the new policies which were not holding water during these troubling time through these new working models.

Through DesOps, while we try to build the organisation design led, and highlight the importance of a “design-driven development-led human-centric value creation, delivery and management process“, we bring the human back into the process. We provide them the centre stage and use empathy to understand the existing pain points and process gaps to bridge them and design the tailor made activity sets and tailor made play books to work around the existing challenges and through out this improve the process.

As every organisation is different, so is their unique needs for operation, a DesOps leader helps in applying Design to make the organisation “Design-Driven” which leads to the optimal design outcome and delivery.

Who is a DesOps/DesignOps Leader?

The typical responsibilities of DesOps/DesignOps leader would involve the following –

  • Growing the cultural aspect – evolving design teams – aligning to the “design maturity” model.
  • Identify the pain-points in the team culture to reduce the impact of any bias design ideation and communications that gets impacted and thereby impacts the design outcome.
  • Bridging the skill gap – ensuring the hiring process is able to recognise the right blend of skill-set for the design role.
  • Improving the touch-points and the process connects the different roles in the organisation as the part of product design-cum-development life cycle.
  • Define and suggest alignments to applying design thinking at all levels of the lifecycle.
  • Identifying the gaps in the day today design operation and optimise them.
  • Define tailor made play-books for different decision making that the different roles and the team can use to take decisions.
  • Optimising the tools/eco-system to bridge between designer and stakeholders as well as the engineering organisation.
  • Bring automation to the design-development lifecycle through deploying Open Design System through Symantic design-system model in order to align to take the next step for the DevOps model. (yes I name it correct — DesOps is about taking DevOps to the next level)
  • Educate and evangelise how the “design” is the common thread between all the associated disciplines so as to build the “design-led” culture in the organisation
  • Build and manage a DesignOPs Center of Excellence (COE)

So the “North-star” leader in DesOpsDesignOps should be blend of understanding all the six spaces/ dimensions –

  1. The vision and stakeholder space – Product management/ Service management space
  2. Understanding into organisation culture and the process involved with Human Resource.
  3. Understand the Design process and models, methodology and tool sets
  4. Need to understand the Project /program management models used for delivery
  5. Need to have good understanding of the technology space involved along with the tools/eco-systems and design system.
  6. Should be a practitioner of Design Thinking as a way of life to apply in the context of all of the above five.

From a career growth perspective a “traditional” design-leader with his ability with the backbone of human-empathy, can migrate into this orchestrator role, by gathering understanding around the other involved disciplines/spaces and especially it can start with growing into either product or programme management.

Center-of-Excellence (COE) for DesOpsDesignOps

In many of the attempts by many thought leaders while articulating about the DesignOps or DesOps, many frequently talk about the role involved – the DesOps-leader aka DesignOps leader . But without the team of right composition, DesOps leader will not be able to execute on the ground.

DesOps leader in the organisation, is more an orchestrator than a solo-executioner, as it is not practical. He needs to have the vision of DesOps philosophies along with sense of responsibilities and attributes, but yet he has to have the right combination of skilled as well as positions team around him to ensure the DesOps model is available.

The closest analogy is a Product Manager‘s role. It is a role that orchestrates among the different disciplines and departments in order to ensure the product/service or the value creation and delivery life-cycle is smooth and efficient.  And remember, the DesOps philosophies are modelled due to the similar necessities of ensuring the right design outcome as the part of the value creation lifecycle.

That’s why a Center-of-Excellence (COE) of DesOpsDesignOps in the Organization makes a lot of sense rather than just bringing up a design-leader as a solo DesOps/DesignOps director.

The DesOps COE in the organisation connects with the various spaces, or departments. In the ontology of touch points, in the first volume of my book “The DesOps Enterprise”, I had explained how throughout the journey various, touch-points can be explored as part of roles, models, ecosystems, tool sets etc.

For a DesOps leader when connects with the different stakeholders who are part of the value creation process (as well as the ones who work to shaping up of the right culture), he connects with these various touch-points.

The DesOps acts as the rudder to the organisation to providing the direction in bringing up to the right maturity level in making the organisation design-led.

Let’s continue the journey of DesOps from the process aspects in the subsequent posts.

Keep in touch!

 

 

 

(c) Samir Dash, 2020. All rights reserved. This content including the images are licensed under a Creative Commons Attribution 4.0 International license

[ First published on LinkedIn (August 19, 2020) at https://www.linkedin.com/pulse/putting-human-back-value-creation-process-enterprise-samir-dash/]

[Video] DesOps 101 (#7): Step One is to Find Touchpoints.

Talk at DesignOps Global Conference 2019 , Manchester, England, 30-31st May 2019

Topic: [TBD – On  DesOps /DesignOps ]
Date: 30/31 May 2019
Venue:  Manchester, England

Super excited to be part of DesignOps Global Conference (www.designops-conference.com) to share ideas with some great minds on hashtagdesignops hashtagdesops hashtagdesign and the future of hashtagdesign from the lens of hashtagopenorg culture and hashtagdesignthinking being applied as the way of life to improve and optimize the operations in the organizations to deliver the “wow” experience, through best utilizing the hashtagprocess and hashtagecosystems and hashtagtechnology in context. Thanks, Peter Fossick. Looking forward to a series of engaging sessions for every hashtagdesigner / hashtagleader.

 

About the Conference:

The DesignOps Global Conference is for design leaders, developers, practitioners, product managers, service innovators and business leaders that are defining the way we design and develop new products and services. Join us Manchester for the DesignOps Global Conference 2019 Agile and Beyond – New Frontiers in Design
30 + 31 May, 2019

The themes for this year’s DesignOps Global Conference are:

  • DAY 1
    • Theme 1: DesignOps and the impact of design
    • Theme 2: Collaborating at speed and scale
  • DAY 2
    • Theme 3: Developing new cultures – developing new organisations
    • Theme 4: DesignOps in the era of AI and cognitive computing

More details of the event and to get the pass visit https://designops-conference.com/

 

 

 

 

 

 

 

 

DesOps 101: Overview

[This is part of the slides I used in Community Call at Red Hat UI/UX Community of Practice on 9 Nov 2018. More details : http://desops.io/2018/11/09/talk-at-rh-ui-ux-community-of-practice-desops-101-overview/]

(c) Samir Dash, 2018. All rights reserved. This content including the images are licensed under a Creative Commons Attribution 4.0 International license

Talk at RH UI/UX Community of Practice: DesOps 101-Overview

DesOps 101: Overview

 Community Calls 

The talk will focus on overview  DesOps.

Three key takeaways:

  1. Background and overview of DesOps.
  2. The high-level overview of the different dimensions of Design operations
  3. DesOps from Service Design point of view
  4. Samples/Examples
  5. Cultural dimension and Open Org aspect.

Date & Time: 12:AM – 1 PM  on 10 Nov 2018 (IST)
Venue:  Virtual Community call over BlueJeans.

 

 

 

Slides

 

 

 

 

 

 

 

 

[Workshop Deck] PART-1: Applying DesOps in Your Enterprise

[This is the first part of the half-day workshop titled “Applying DesOps in Your Enterprise” I conducted at the “UX India Conference 2018” on 4th October, 2018, Bengaluru. This part focused on ‘Process’ aspect of DesOps, and tried to address the challenges of bringing the designers to the same page to that of diversified subject-matter experts (SMEs) during the ideation phase of an Design Thinking workshop, by collaborating on “Petal Process Diagram”(PPD) . PPD is a mind-mapping kind of activity with the focus to involve all the entities involved in and around a touch-point in a feedback-loop, and helps everyone in the room to be on the same page on the potential possibilities, feasibilities involving “props” and “process” components.

You can explore more at http://desops.io/2018/10/03/workshop-at-ux-india-international-conference-2018-applying-desops-in-your-enterprise/ ]

Continue to the next part of the workshop, in the next post.

Meanwhile, you can explore more here:

https://youtu.be/J5Igx25pj5A

(c) Samir Dash, 2018. All rights reserved. This content including the images are licensed under a Creative Commons Attribution 4.0 International license

 

 

Download the Paper – “In Search of Truth: At the Crossroad of Critical Theory and Technology in DesOps World”

It was a great pleasure to be at UGC seminar in Department of English B.B.Autonomous Mahavidyalaya, Chandikhole on the topic ” In search of truth: At the crossroad of critical theory and technology in DesOps world” It was a very engaging session presided by principal Dr. Kedarnath Das, HOD English, Prof. Rajendra Padhi, Senior lecturers Jachindra Rout, Bimal Ch. Mallick, Dilagovinda Pratap, Nabajyoti Biswal. Dr. B.K.Nayak and the students from the department of English, Maths and Science.

Resource person Prof. Samir Dash, Bangalore. Sanjeev Behera, Psychologist, Presided by principal Dr. Kedarnath Das, HOD English, Prof. Rajendra Padhi, Senior lecturers Jachindra Rout, Bimal Ch. Mallick, Dilagovinda Pratap, Nabajyoti Biswal. Dr. B.K.Nayak.Image may contain: one or more people and text

 

Topic: In Search of Truth: At the Crossroad of Critical Theory and Technology in DesOps world
Date: 16 July 2018
Venue: Department of English, Baba Bhairabananda Autonomous Mahavidyalaya, Jajpur, Odisha (http://bbmchandikhole.org/)

 

Read it here: 
https://www.linkedin.com/pulse/search-truth-crossroad-critical-theory-technology-desops-samir-dash/

Downloadable Paper/Slide: 

https://www.slideshare.net/MobileWish/in-search-of-truth-at-the-crossroad-of-critical-theory-and-technology-in-desops-world-16-july-2018-bbautonomus-college-chandikhol

 

Abstract:
This UGC seminar session was an attempt to understand, from a non-traditional lens, the relevance of critical theory in context to today’s ever-changing technology space that is moving towards the Automation, Artificial Intelligence, Machine Learning and Distributed Computing, become much more important in history than ever, as it deals with softer aspects of human identity and socio-cultural dimension through communication or human expression.

This interactive session will have two major focus:

1. A brief overview of the critical theories from a diachronic lens that will be helping the students in grasping the fundamentals in a socio-cultural context.

2. A cross-discipline comparison with the modern design-driven practices in the software industry that would help the students understand the potential and opportunities in the real world scenario where these theories would help.

#DesOps #DevOps #design #designthinking #communication #criticaltheory #literature #englishliterature #englishlanguage

     

 

 

[Paperback ]: The DesOps Enterprise -Re-invent Your Organization  : (Volume 1) The Overview & Culture

Paperback on DesOps 
The DesOps Enterprise -Re-invent Your Organization  : (Volume 1) The Overview & Culture
By Samir Dash
Published on : 5 June 2018
Get the paperback from:  http://a.co/cdPAwPU

In this three-part book series, we will be touching upon the practical approaches on how to prepare for this next-wave in service-design of that compliments DevOps in the concepts of a cultural shift, collaboration and automation. We will also see what are the available solutions today that contribute to bringing the full circle of design in the context of software development lifecycle.

This book series aims to deliver the explorations and insights into the modern approach to design, as a creative process, spanning across the whole gamut of

disciplines like Product Management, Marketing Management, Market & User Research, Interaction Designing, Information Architecture, Quality Assurance, Product/Service Strategy and Delivery etc.Current, the first volume of the series, deals with the fundamental principles and explores the cultural aspect of DesOps. To implement successful Design driven organization, it is important that every member of the enterprise must understand and believe in design (unlike the popular belief of it being a discipline of visual arts) as a creative approach to problem solving to capture delight and in this light be a part of the design operations which encompass from envisioning of the product till delivery of it as a delight to the end-users and customers.

 

5″ x 8″ (12.7 x 20.32 cm) 
Black & White on Cream paper.

Paperback and Kindle eBook version.

ISBN-13: 978-1720635062
ISBN-10: 1720635064

Infographic: The 3 Dimensions & 3 Characteristics (3Cs) of DesOps

©2018,”The 3 Dimensions & 3 Characteristics (3Cs) of DesOps” by Samir Dash.
Creative Commons Attribution-Share Alike 4.0 International License
Read about 3 Dimensions

Team’s Vicious Circle and Avoiding the Organization Turning into a Pack of Zombies

On the theoretical level, the interaction can be modelled based on various entities like tasks(i.e. activities users perform to reach their goals), dialogues (i.e. interaction between user with users and machines and vice versa ), rules or instructions (i.e collection of behavioural instructions ) and states (i.e. conditions present in the system ) etc. Broadly, the interactions in the team/organization involving communications and sharing among members or more specifically among the roles, though is part of the Process dimension, constitutes the components that are part of the core of Cultural dimension of DesOps.

Basically, this is all about getting answers to two questions that a typical Product Manager or a CEO of the startup has in mind :

  • Do I have the right team?
  • How do my team can be effective in communicating and collaborating at different spheres with different types of entities involved?

In the previous article, I was primarily referring to two levels of the interaction were human-to-machine and machine-to-human and how minimization of the touch-points where the translation of value happens. This is primarily about “consciously and proactively considering the exchanges between people and organizations in the enterprise, and supporting these interactions with automation and tools” (Guenther, Millan Intersection, 2013 ). Solving the challenge to minimize such touch-points are relatively easy, as it involves some aspect of technology and toolchains associated. However, the level which is about human-to-human interaction is the most complex to deal with as it does not have any technology involved in it. In the last article, we slightly touched upon the full-stack roles, that handled some aspects of it. This aspect is more about involving knowledge, skill and expertise attributes of humans involved, and some aspect of it is also involved with human-to-machine & machine-to-human levels, which are partially solved by the redesigning the process involving the technologies. However, the human-to-human interaction is more complex, because it involves the attributes of human emotions, attributes and bias and cognitive fixedness that are counter-productive for any organization heading for disruptive innovation.

Broadly these attributes are part of forming a right set of team, with the right mindset. This is broadly about what kind of team members you should be looking for and also about to implement a set of practices and rules which would help grow each team members towards the self-awareness about there cultural fitment as well as motivate and guide them to grow themselves to overcome their fixed mindsets if any.

Fixed mindsets are the roadblocks to innovation in any organization. The fixedness is part of the human attribute that acts as the vitamin for a pre-defined process oriented no-brainer’s job to bring effectiveness, but at the same time acts as cancer for innovation. Typically, the key types of fixedness that hinder having effective human-to-human interactions in DesOps organization are as follows:

Cognitive Bias: The Cognitive Bias is typically defined as a mistake in reasoning, evaluating, remembering, or another cognitive process, often occurring as a result of holding onto one’s preferences and beliefs regardless of contrary information. The cognitive bias is a kind of fixed mindset that sometimes also manifest itself as a tendency for people to evaluate ambiguous information in a way beneficial to their interests apart from the aspect (popularly known as Confirmation Bias) that induces the tendency to search for or interpret information in a way that confirms his/her preconceptions. This leads to the premature closing down of options in a creative process, as the person affected by this only seeks out the evidence from the information he has that was pertinent to his argument, and remains blind eye purposefully to any other information.

HiPPO effect or Authority Bias: HiPPO (highest paid person’s opinion) is one of the popular terms in the organization-productivity domain. Basically, this is more about having authority biases and the team’s tendency to attribute greater accuracy to someone how holds a higher position in the organization. Beware of the HiPPO (highest paid person’s opinion) in the room as it means that the team has fallen foul of the law of the HiPPO — When a HiPPO is in play, the organization is most likely not relying on data to inform decision-making, rather the HiPPO (highest paid person’s opinion) tends to win out. In large corporate environments, it’s easy to experience it first hand. Usually, when a group of people are trying to make a difficult decision, for which there are lots of opinions, the person in the room who is further up the hierarchy (and therefore typically paid more) expresses what they think and tries to hijack the spirited discussions to steer towards forming an opinion among the team to follow what he thinks and labels it as the team’s decision.

HiPPO effect is the biggest roadblock in interaction aspect of DesOps. If you remember in previous articles of this series I had mentioned how one of the key philosophies of DesOps is to advocate and put a data-driven decision making into practice. HiPPO Effect actually is cancerous to DesOps culture. All the efforts to implement the right process and toolchains as a part of having an effective DesOps in the organization can fail, even only this cancer is still there as a part of the work culture.

Authority Bias is in similar lines with the HiPPO effect, but this may not necessarily about the person who is higher in the organizational hierarchy or paid more, rather it is about the person, who is “seen as experts” or even as an authority in the organization or even in the team. We have an inbuilt tendency to believe those who we perceive as “experts” and usually have a deep-seated duty to authority, and tend to comply when requested by an authority figure.

For example, in typical design or UX team meetings, it is the most difficult situations for young members who are just fresh out of colleges and had to present certain aspects of their solution that are in opposite directions to what the leader of the design team thinks or beliefs. In many cases, these ideas are brushed aside by the authoritarian leader or manager sighting even some frivolous reasons e.g. “it has to improve”, “immature and not practical”, “you need to understand our design process first”, “can’t use that to discuss with stakeholders as it is half-baked design” and so on. And in such cases, most of the “faithful” designers to the leader, echo the leader’s decision and even some start advocacy to explain the logical reasons behind the leader’s reasons. Some may be “yes-men” to the leader consciously, however, some do so as they perceive the leader as the “authority” or “expert” and this allows the authority bias to be successful in killing new ideas and fresh thinkings. In many cases, the member does not realize that they have already fallen prey to such bias.

One of the most famous psychology experiments of all time, known as the Milgram experiment, provides a terrifying example of that a very high proportion of people would fully obey the instructions. Read about this 1961 experiment here: https://en.wikipedia.org/wiki/Milgram_experiment ) and here is a video of that experiment:

 

The Bandwagon Effect is typically a psychological phenomenon in which people do something primarily because other people are doing it, regardless of their own beliefs, which they may ignore or override.

The Herd Mentality The Heard mentality and mob mentality, also lesser known as gang mentality, describes how people can be influenced by their peers to adopt certain behaviours on a largely emotional, rather than rational, basis. Basically, when the Bandwagon effect is blended with the catalysts of emotions, it takes shape of the herd mentality. This is the most negative extreme of the Bandwagon effect.

Also, the Cognitive Bias is more induced by the Herd Mentality as the persons involved turn blind eye to the factual information which can be used for making data-driven decisions. Rather, the persons depend on the emotional ripples for taking decisions and develops a strong Cognitive Bias, thereby contributing to form the Vicious Circle in the team.

(Download the PDF of above at http://desops.io/2018/05/13/infographic-the-vicious-circle-in-teams/ )

The Vicious Circle, refer to complex chains of events that reinforce themselves through a feedback loop, and it is interesting as feedback loop acts as the essential spine for any DesOps organization. The fixedness attributes in persons involved in the team essentially turn the feedback loop into the Vicious Circle that gradually cuts-off the supply of oxygen to the innovation in the organization.

In many cases, HiPPO effect or Authority Bias makes the team meetings ineffective and counter-productive. The members either fall prey to these bias, or they try to avoid conflict in the team and keep themselves safe in the organization by remaining silent (mostly by seeing the large mob of the zombies of these bias in the team. In such situation when some spirited members typically lower in the organizational ladder counter the argument of the upper ladder persons or the leader, the conflict arises, which is in most of the case becomes counter-productive for the team and the organization and becomes suicidal for the those at the lower ladders. Else, the typically the long silence follows in the team meetings when the leader explains his/her idea or viewpoint to a problem (in a tone of judgment in many cases). In both the cases, when it becomes a regular trend that when a leader of the team’s or the ideas or viewpoints from the those who are placed on the upper ladder are praised or unanimously advocated without a few valid questions and some set of team members regularly remain silence, this is a very symptom of the cancer. In another scenario, if the young minds in the team who used to have questions earlier when they had newly joined the team, have no more show any interest in questioning or ask the obvious questions where most probably they do not really need an answer or seems to know the outcome of the questions they asked, that is another alarm for the cancer.

If the team does not have a diverse-voice or the team members mostly ask questions which do not really going to impact those who asked those, and fall in the graph in questioning opinion of the leader in a productive way or some members in the team remaining silent who used to be more creative in the past (and for a long time their opinions were brushed aside and never mattered ) then the team or the organization has already become a totalitarian state and is in a serious condition that requires the fix of the culture.

This is important to remember here, that the foundation of DesOps is based on interaction and collaboration that is productive and supports innovation from grass-roots. In the trueDesOps organization, the ideas flow from bottom to top, like the seed of ideas germinate and grow as plant and gradually through continuous nourishment from the surrounding culture which turns it into a big tree with the fruits of innovation. All the process improvements, toolchain support and the technologies act as the catalyst to support such a culture. Going DesOps is about adapting to change, being flexible, adopt disruptive innovation in a measurable and informed approach. For such eco-system to be successful, it is essential to ensure the work-culture is supportive and provides motivation to the actual people who are part of it.

So where is the way out? One of the fundamental tasks of DesOps, as a Service Designapproach, is to prepare the work culture of the product team for more positive interaction in context to hum-to-human communication and collaboration so as to prepare them for the process changes that might follow up along with the aid of automation and new technologies supporting radically new toolchains. And in such cases, to avoid the team falls prey to fixed mindsets, mostly three steps can be taken:

  1. Choosing the right people with more open personal traits at the time of hiring. During the hiring process, there are many popular psychological tools and methodologies can be employed to avoid personal traits with higher index in the person, which is less willingness to take the risk, or avoid the person too much structured-perosn who is more prone towards process-oriented obedience. The new age innovation in organizations needs the product team with the people with more open and inquisitive mindset — those who have lot of questions in them with passion than the structured minds who always define the box as the red line for him as well as his team members, to play within.
  2. Always keep an eye on symptoms of Vicious circle getting formed within the team or organization. Mostly it starts with the persons who are at the top of the ladders. And the most commonly it starts with HiPPO effect. Evaluate internally if there is any change in the behaviour of the team during meetings — try to find answers to question like “Has the spirit of some members have changed?”, “Is there fewer questions in meetings and especially fewer questions to the people at a higher hierarchy? “, “Has the agreements to the top leaders’ views have increased without much discussions over last few meetings?” “Has some set of members are regularly putting up silence since a period whenever the leader of the team or people on the higher ladder is throwing the ideas?” “Has there been an increase in rejection of ideas from the grassroots ?” — These will help in forming the timely suspicion to avoid the Vicious Circle. Note, that these may seem like addon work, but this timely diagnosis is worth it, as it helps to ensure that the organization is not got cancer at its’s brain and heart.
  3. Another key aspect is to bust fixed mindset is to enable un-learning. The systematic un-learning is a key to fixedness that is more functional or structural in nature. Unlearning helps in fostering a sense of willingness that helps in opening up minds. Especially this is effective as well as critical to have the managers and the members of the top hierarchy, to develop a sense of willingness to unlearn and learn something new. Unlearning helps to put team members out of their comfort zones so that they are more willing to pursue the unfamiliar and fosters curiosity.

We will be exploring these in details in forthcoming articles of the series. Be in touch, and do not forget to share this post.

(c) 2018, Samir Dash. All rights reserved.

[Originally published on May 14, 2018 at https://www.linkedin.com/pulse/desops-next-wave-design-part-12-teams-vicious-circle-avoiding-dash/]