Is technology by itself good, bad, or neutral? Does the application of technology as its own process carry any inherent viewpoint or judgment? Are technologists — the engineers, scientists, builders, makers, and creators who build, utilize, and share technology — cognizant of their role in the design and functioning of their own tools? If technology advances internal beliefs in a more efficient, widespread manner, is it important to examine those internal beliefs first?
These types of questions, as well as questions adjacent to technology — such as around privacy, security, and surveillance — have been part of an ongoing discussion inside Lullabot. As strategists, designers, and developers, we not only do our work, but we also help our clients reach their own audiences, shape their own business models, and spread their own values into the world.
Where there is great power there is great responsibility.
Discussions about values, morals, and ethics happen daily in workplaces across the country, with tech-specific examples, including, body cameras and police accountability nationwide, GitHub employees protesting the sale of the software they build to U.S. Immigration and Customs Enforcement, Salesforce employees protesting over continuing contracts with the U.S. Customs and Border Protection, the Moral Machine, which gathers a human perspective on moral decisions made by machine intelligence (such as self-driving cars), and the National Institute of Standards and Technology (NIST) report on how face-recognition algorithms fare at identifying people from different demographics.
Values are implicit in those of us architecting, producing, and deploying technology, and we have been grappling for the past year with the creation of a living Engineering Values Statement.
During our 2019 team retreat, Matt Westgate mentioned "engineering values" in his presentation, and our Design & Strategy team led a company exercise inferring values from a hypothetical build of a podcast page. From this work, some wanted to clarify and publicly state the type of work that we engage in to help identify what would be a good fit versus what would not be a good fit for our work from a sales perspective, as well as to share this information with clients, staff, and new hires.
The evolution of our engineering values came out of continued focus and clarification of our core values. As the retreat drew to a close, some volunteers decided to start meeting on a regular basis to come up with the parameters of the project with the ultimate goal of encapsulating a list of succinct engineering values for circulation.
The idea was to create a reference list to help with various situations, such as:
- The sales team outlining our default values when we begin an engagement
- Account managers evaluating values with clients during ongoing engagements
- Evaluating technology for ourselves or our clients
- Arising conflicts from engineering problems with ourselves and our clients
The committee's call for volunteers was:
- "We’re looking for 4 to 7 members who can attend a 30-minute meeting each week, along with an hour or two of help with whatever tasks we come up with. Of course, client work will ebb and flow, so we don’t expect this to be 100% every week. And while we’ve called this 'engineering values,' that doesn’t mean this group is only for 'engineers.' We’re sure anyone who's interested will have something valuable to contribute."
Our volunteer group organized around a series of Paper docs, and met via Zoom every week for a half hour with the first task of brainstorming questions and ideas for what we'd like to ask ourselves and the team. Through the initial creation of a charter document, the group identified a list of "must-have" deliverables as well as some "nice-to-haves:"
Deliverables
- A summary of interviews and feedback from the team, with any notable commonalities or conflicts in values.
- An initial draft of an engineering values document, presented to leadership and the team.
- A summary of research on what Drupal agencies and the broader industry communicate as their engineering values.
- A final document based on a round of feedback from the team.
Nice to haves / to be determined
- Whatever resources, if any, the sales team would like
- A page on our company website
- A marketing announcement (e.g., blog post, podcast, etc)
In terms of logistics, a weekly meeting for thirty minutes worked well, as not all participants could attend all meetings. Any action items identified were in manageable increments and all could asynchronously connect through a shared folder that included meeting notes and the actual list of values. The recurring calendar invite was held by one person and periodically circulated to the greater team as new hires joined, with a specific focus on making sure the group represented a cross-section of business roles, backgrounds, and geographical basis. Discussions centered around a shared wiki-style document. The facilitator role was held by different participants as availability and capacity changed over time. The working group also opened a Slack channel to post information as well as align around comments, next steps, and action items.
In terms of process, the group came up with a first round through assessing personal, individual engineering values, and documenting those, discussing in small groups, and aggregating into an initial group-wide list. We sent a Google Form to the entire staff asking, "What are your engineering values?" This triggered a follow-up activity to do a roundtable on whether or not team members consider themselves engineers. We discovered that not everyone (even those who are developers) considered themselves "engineers." Through continuous feedback and sending reminders to participate approximately every six weeks, the group continued to identify who was not in the room and which voices needed to be added to the conversation.
Lessons learned
1. Proposing an initiative
The project, like any other project, demanded that the working group align around timelines, success criteria, deliverables and scoping, and getting leadership approval and feedback.
2. Including those not present
Leaning on other groups, such as our Diversity, Equity, and Inclusion and Accessibility groups, helped unblock us throughout the year. Also, inviting others to participate in ways like a one-off interview provided a nice balance of respecting time and getting unique feedback.
3. Space for different perspectives
Including multiple voices helped form a more comprehensive discussion. Including different perspectives didn't end at the invitation: we followed up. We found we needed to be prepared for surprising disagreements and leaned on the idea that working group leaders should facilitate instead of participate.
4. It’s OK to opt out (or opt in)
Everyone in the working group also had client responsibilities and sometimes project scheduling changed, which meant participation by one or many in the group became difficult or impossible. Other times, a project ended so time was available to participate. We asked participants to commit to blocks of availability at a time (say 2-3 months) so the group could rely on individuals.
5. Delegate!
Sometimes, initiative leaders had to be direct to not allow their own absences to become blockers. We used dice to assign a facilitator out of available participants.
In terms of feedback, the team prepared for a presentation at the 2020 Lullabot Team Retreat, to share the first draft with the greater team. This list had 13 values on it. By soliciting feedback in the form of comments on the document (comments are visibly tied to a specific username), as well as index cards (snapshots of cards were anonymous), the committee gathered a wide variety of responses. Incorporating retreat feedback, the group continued to narrow down the list to six core engineering values. Along the way the working group continued to ask for feedback from operations, marketing, sales, and other departments. We published the values to an internal blog and released them to a private GitHub repository.
Our team is happy to have phased out the working group and successfully handed over the document, moving to a living document. While we’ve closed the loop on this first phase of the work, we now look forward to discussing these values with the community and engaging around these values with those working in technology who have similar conversations happening within their own organizations.
With many thanks to Andrew Berry, who facilitated the Engineering Values Committee, for his feedback and review.
Members of the Engineering Values Committee included: Andrew Berry, Brian Skowron, Darren Petersen, Hawkeye Tenderwolf, Helena McCabe, James Sansbury, Marcos Cano, Mateu Aguiló Bosch, Matt Oliveira, Matt Robison, and Monica Flores.