Driving systemic change

A bug is usually considered a self-contained technical issue with a piece of hardware or software. There are, however, larger or more systemic issues that we face every day, and these can be expressed in terms of a culture or in terms of the everyday conventions and patterns that we employ throughout a system. Here are some fictional examples of issues from within a typical IT consultancy:

  • We tend to use typefaces throughout our designs that are inaccessible
  • We have a hundred different standards for how to write good JavaScript
  • We seem to always forget to update third-party dependencies
  • We don't feed back into the open source community

These issues are slightly too broad or subjective to be expressed as definitive bugs, so we'll need to explore other means to surface them and get them resolved. It may be useful to think of such systemic issues as opportunities for growth instead of bugs, as this can vastly affect how on-board people are with your proposed changes.

Broadly, the steps involved in creating systemic change are as follows:

  1. QUALIFY: Articulate the problem with specific examples: Find examples that demonstrate the problem you're trying to describe. Ensure that these examples plainly show the issue and aren't too complex. Describe the problem in a way that makes sense even to people that aren't fully immersed in the problem domain.
  2. FEEDBACK: Gather feedback from other people: Gather thoughts and suggestions from other people. Ask them open questions such as What do you think about [...]?. Accept the possibility that there is no problem, or the problem you're encountering is best viewed in some other way.
  3. IDEATE: Collaborate on possible solutions: Source ideas on possible solutions from multiple people. Don't try to reinvent the wheel. Sometimes the simplest solutions are the best. It's also highly likely that systemic issues cannot be solved in a purely technical way. You may need to consider social and communicative solutions.
  4. RAISE: Raise the problem alongside possible solutions: Depending on what the problem is, raise it to the appropriate people. This may be via a team meeting, a 1:1 chat, or online communication. Ensure that you are raising the issue in a non-confrontational way and with a focus on improvement and growth.
  5. IMPLEMENT: Collaboratively pick a solution and begin work: Presuming that you are still considering this problem is worth pursuing, you can begin to implement the most preferred solution, possibly in an isolated and Proof of Concept kind of way. For example, if the problem being tackled was We have a hundred different standards for how to write good JavaScript, then you could begin to collaboratively implement a singular set of standards using a linter or formatter, reaching out for feedback along the way, and then slowly updating older code to align with these standards.
  6. MEASURE: Check in frequently on the success of the solution: Get feedback from people and seek quantifiable data to discern whether the selected solution is working as expected. If it isn't, then consider going back to the drawing board and exploring other solutions. 

One of the traps in creating systemic change is to wait too long or to be too cautious in approaching the problem. Gaining feedback from others is really valuable, but it is not necessary to depend entirely upon their validation. It's sometimes hard for people to step outside their perspective and see certain issues, especially if they're very accustomed to how things are currently done. Instead of waiting for them to see things your way, it may be best to go ahead with an isolated version of your proposed solution and later prove its efficacy to them.

When people reactively defend how things are currently done, they are typically expressing the status quo bias, which is an emotional bias that prefers the current state of affairs. In the face of such a reaction, it is very normal for people to be unwelcoming of a change. So be cautious of placing too much value in others' negative feedback about your proposed change.

Many of the things we wish to change within the technologies and systems we work with every day are not easily solved. They may be complex, unwieldy, and often multi-disciplinary problems. Examples of these types of problems are easily found on discussion forums and community feedback surrounding standards iteration, such as with the ECMAScript language specification. Rarely is an addition or change to the language accomplished simply. Patience, consideration, and communication are all needed to solve these problems and move ourselves and our technologies forward.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.62.94