We want all of our policies to be living documents which can improve and change as we learn and grow as a company. This is how we'll propose and make changes to our policies.
We’re using several different tools and platforms to collect feedback and discuss the handbook. I’d like to codify the way we’re using them now, and then adapt as we find new ways to use them -- here’s how I see that now:
The handbook is hosted on Github, and anyone with a Github account can make an issue or open a pull request. This is an important home for the project, and we want to encourage and reward participation. We should respond to issues and comments here and use the edits in pull requests when they’re appropriate. B will do this regularly, and anyone else is free to respond when they're interested. This will help more people feel bought into the handbook and will help us gather more opinions on our policies.
However, our internal processing does not need to happen on Github. Anyone should feel free to post their thoughts on Github, but there are a lot of sensitive topics that we’ll want to discuss internally. When we make changes, they should be merged on Github and we should explain our rationale there, but we don’t need to rehash the whole conversation.
Github is a tool that the technical members of our team will already need to get familiar with, but special consideration should be taken to make sure our non-technical teammates have accounts and understand how to participate there.
There is an internal Trello board at https://trello.com/b/gTmLFJgs that lists the current areas of interest, research, and proposals. This is where we can track the currently active internal discussions. If anyone has an issue they would like to start discussing, they can add a card to that board.
Proposals should be written in Google Docs and linked to on the Trello board. There is a folder in “Active Projects” for ‘Handbook Research and Proposals’ which will hold the documents for research being done and proposals being written. This folder will be accessible to everyone internally, but will not be public.
A lot of folks have commented on the handbook outside of Github, especially on Twitter. The best thing for us to do is acknowledge their input and make sure it gets recorded in one of our other channels (especially Github) so that we don’t lose it. As individuals, anyone should feel free to talk about their opinions about feedback, but as Clef we should thank people for their input without being defensive.
This channel is a good place for us to comment on policy changes asynchronously. Any questions, concerns, ideas, or discussion about our handbook can go here. If a conversation seems particularly interesting, we'll document it in Google docs or in a Github issue for future reference.
B will be blocking out a few hours every week on Friday mornings to look through and respond to issues, create proposals based on feedback, schedule time to talk about changes as a team, and merge in changes that are ready. Regular work will make sure that issues don’t stagnate, and any team member is welcome to create proposals or contribute to research on policies that they’re interested in.
During our weekly team lunch, B will summarize open issues and proposals.
Any substantive change to the handbook should be laid out in a proposal that the team can comment on and discuss. Proposals should lay out the details of the change and the reasons for making them.
Every proposal should have an open meeting for feedback from the team. B will schedule these, and will be there for all of these discussions. Everyone is invited to all of these discussions, though attendance is not required. Participation in these conversations is really important because this is the best place for us to get a sense of how different team members relate to or will be impacted by a certain policy.
Team members can also talk to their manager about concerns they have with a given change or policy privately, as well as ask that the manager bring up the issue if they’re not comfortable doing it themselves.
Team members can comment on the proposal document before or after the meeting, in the meeting directly, or they can privately ask their manager or another employee to bring up their comments anonymously.
There should always be notes from these meetings, which should live at the bottom of the proposal document.
After changes have been proposed, discussed, and B decides they are ready to be merged into the handbook, B will do the merge on Github, update the card on Trello, post about it in Slack, and send an email. For major changes, he or another team member may also write a blog post about the change and the factors that went into making it. Blog posts should (with their permission) acknowledge all of the community members that participated in the discussion and helped us make the change.
Everyone at Clef needs to sign an Acknowledgement of Receipt for the Employee Handbook, but any change to these documents need to be acknowledged by every employee. Most companies do this on each employee's first day, and then have employees sign another acknowledgement whenever they make a change (because they're rare).
Because we want these policies to constantly improve, we will merge changes as they appear. To make enforcing policy clear and unambiguous, we will adopt the changes at the beginning of each quarter. We will use milestones on Github to mark these canonical versions of the handbook, and we'll host them all at getclef.com/handbook. They will be labeled with the dates that they applied, so if there is ever a question or complaint about a policy violation, it will be clear which policies applied on which dates at Clef.
Every employee will need to sign an Acknowledgement of Receipt of Changes to the Employee Handbook each quarter, which may not scale as we grow to more employees.