Chapter 7: The Downsides of CoPs
April 23, 2020
- Downsides: hoard knowledge, limit innovation, hold others hostage to expertise, exclusive membership
- What do you think you have to accomplish to be recognized as a leader in UX? (Ex. school, work experience, title, publications, social media following, speaking, recruiting, etc.)
Single Communities: What Can Go Wrong
- Failed community is still better than no community
- Can fail in aspects of domain, community, and practice
Domain
- “Pride of ownership”
- recognizing / seeing oneself as an expert makes you believe you know all there is to know
- Imperialism; competition between multiple domains to be more important to the organization than others; instead of working together
- Do you come across he same UX information (ex. trends) from multiple sources? Are these sources from competing organizations?
- Formations of “knowledge police” can occur where they must approve information
- Narcissism – “they pursue their own agenda with little regard for what teams or business units really need in terms of expertise or capability” (143)
- Marginality – community is not taken seriously, therefore not effective to the organization
- Factionalism – disagreements are accelerated into wars
Community: Too much of a good thing
- What kind of UX teams do you think you will not get along with? Ex. “dev-bros”
- Tight bonds create exclusivity
- “toxic coziness” can be counterproductive
- In cliques, “relationships dominate other concerns”
- Needs meaningful interactions, include new generation members, apprenticeship, mentorship, multi-membership
Practice: The Liabilities of Competence
- Practice places members on a closed paradigm; this makes me think about how all designers speak about their work as if they’re going to save the world…
- How do you describe what you do to others? What do you have to consider about who you are speaking to before describing what you do as a UX designer?
- You can get stuck in “documentism”; repository is used but not screened for quality; creates “information junkyard”
- Have you ever had to solve the same problem from scratch?
- These downsides occur naturally in CoPs; in order for CoPs to succeed, they must be recognized and solved
Constellations of Communities; What Can Go Wrong
- Problems occur across multiple communication in and outside of the organization
- Boundaries of practice STICKS and LEAKS
- Stickiness:
- Jargon, methods, customized environments makes it hard for outsiders to join
- Moving knowledge across disciplinary boundaries is difficult; knowledge does not necessarily apply to other communities
- What is it like to talk about UX design requirements to a team member who is not a UX designer?
- Leakiness:
- It’s easier for practitioners in competing organizations to gain expertise than different departments in your own organization to gain understanding of specific products
- “Firms in alliances often find they can gain knowledge faster from the practitioners they know in other firms than from their coworkers in other business units of the same firm.”
- This is possible when shared practices happen across organizations (something which I can expect occurs for UX designers)
- Why is it important for UX designers to experience working in multiple companies?
- Why is it common to see UX designers move around different organizations early in their career?
- How do you learn about the way other organizations do UX design?
- When proposing a new project, how does your team describe your UX capabilities and services?
Managing Boundaries
- Knowledge is TIED to practice (sticky)
- As long as practice moves, knowledge moves also (leaky)
- Boundary crossing = “deep kind of learning”
- “Learning potential of an organization lies in this balancing act between well-developed communities and active boundary management”
Organizations: What can go wrong
- Organizational barriers:
- Irrational politics; communities are seen as a threat/rebellion
- Short term focused and tangible outcomes leads to mediocre execution of ideas
- Anti-learning culture only focuses on individual contributions; organization cannot exploit the community
- Rigidity and agility; Successful methods / practices develop from community might lead them to close-in on that practice only
- What types of UX design problems would be inappropriate to bring up to your design team, and why?
- When you are given a task, can you picture what the end result would be? What are some examples of when this occurred? How were you able to imagine that result?
- At what point of the project’s development are you able to flesh out the look and feel of the final product?
Conclusions
- Organizations need to let communities grow bottom-up first, and then apply the applicable management procedures top-down
- “…it takes organizational leadership to provide an environment that is both supportive and challenging.”
- What kind of impact / influence do you bring into your UX team?