This was presented at Code4libBC 2019.
Slides
Hi everyone, hope you’re enjoying Code4libBC so far. While I’m up here, I just want to take a quick moment to thank the organizers past and present. We’re on our 7th one and still going strong. I hope to continue attending and see this event get to its 10th and beyond.
Anyway, I don’t normally do this, but even though many of you know me, for this topic I think it’s worth giving a little bit of background about myself as context.
My background
With the exception of a couple of summer jobs, all of my positions until my current work have been in a wide range of public services or public organizations, and I’ll likely return in the future. So, even though I don’t work in public services right now, I care about the work environments we have. When someone asks me what I do, I still sometimes have to catch myself not to automatically say I’m a librarian.
My work
I currently work at GitLab, a startup based on the open core project of the same name, which basically helps others work on their digital projects. Many people think of it as another GitHub, but it’s a lot less focused on the social aspects and more on being a one stop shop for all development, operations, and business needs.
I’ve been at GitLab for about a year and a half as part of the support team. The company has grown exponentially in the last few years. When I started we were at less than 300 people and now we’re over 1000. We’re also a global company in over 65 countries and regions, and yet: we’re fully remote.
Disclaimer
I will add the usual disclaimer that should be obvious that I’m not here representing GitLab. These are my own views based on my experiences especially in moving from public services to my current workplace.
More importantly, in talking about today’s topic, I know that some of what GitLab does doesn’t apply to public organizations. So, I’ve said all that for context, but I have tried my best to exclude anything that I don’t think will work in a typical public organization and considering a unionized environment. Nevertheless, each organization is unique so not all of the strategies and ideas will work in any workplace.
While I strongly believe that GitLab’s values and the way we put them into practice is how we’ve achieved a great workplace that is also highly efficient and produces excellent results, the culture we have is also a collective thing where we all implicitly agree on the values that we should uphold, and is in large part carried over from those who started, and have since been a part of, the company.
In only 10 minutes, I also won’t be able to cover everything. I’ve chosen points that I believe are more relevant.
Why?
When I went to work for a tech company, I knew for a fact that I would improve my technical skills and my understanding of development work, but I honestly never thought it would be such a huge culture shock. While it took some adjustment, it was a positive culture shock that made me a better team member, leader, and contributor.
Hopefully, through this talk, some of the reasons will become obvious, but I’ve heard time and again that one of the hardest things about technology in public institutions is hiring and most importantly keeping talented people.
- Hiring and keeping talent
In competing with private companies, we often can’t provide a higher salary (though we should if we can), but we can implement the values we believe in; providing a great work environment and non-monetary benefits. A positive work environment usually results in better:
- Job satisfaction
- Productivity
- Team work
- Reputation
- and more
Example: Shobe K (2018) Productivity Driven by Job Satisfaction, Physical Work Environment, Management Support and Job Autonomy. Bus Eco J 9: 351. DOI: 10.4172/2151-6219.1000351
The Values
To help frame the discussion, I’ll be using GitLab’s list of values. I believe the individual values are fairly common to both public institutions and private companies.
- Collaboration
- Results
- Efficiency
- Diversity & inclusion
- Iteration
- Transparency
Collaboration
Collaboration means working together. I don’t think there’s any disagreement here. However, when we’re told that we did a good or bad job at collaborating on something, what does that mean?
How many here would agree that we should positively recognize collaboration?
How many would say that we should reward getting consensus?
- not consensus
I think we can agree that consensus is not the same as collaboration, and yet, more than once, in previous positions, I was told that I wasn’t being collaborative because I didn’t get consensus from everyone in management or worse, almost everyone in the organization. It made me afraid to do almost anything without asking my manager or even multiple managers for permission or agreement. I sincerely hope that none of you are in that sort of situation.
- recognize when others are needed
Instead, I think good collaboration is about recognizing when you should work on something individually and when others are needed,
- working well with others
working well with those other people,
- be kind, assume positive intent, blameless problem solving
which means being kind, assuming positive intent, and problem solving blamelessly. If something goes wrong, focus on the problem and work. People generally aren’t actively sabotaging the work, and playing the blame game only makes things worse, so focus on fixing things and learning from mistakes.
- letting others take the lead / having short toes
when appropriate, let others take the lead. Often people say that they don’t want to step on other people’s toes, but we should encourage initiative and positive contributions by others in areas that we might feel we own.
Decision Making
I’d like to go on a slight tangent
Quick raise of hands, how many here have heard the phrase “making decisions by committee is a bad idea”?
Decision by committee is typically inefficient, because if not everyone agrees, negotiations happen and compromises are made, or even worse, you end up implementing everyone’s ideas. Either way, it often produces poor results.
Most times we want consensus, it’s because we want buy-in from all the stakeholders, but consensus and buy-in aren’t the same things either. Typically, we can get buy-in as long as people feel heard and that their comments are addressed. That’s not saying they have to agree.
So how can we make decisions that follow our values?
- Make an initial open proposal. Smallest change possible.
Open in this case means that as many people as possible can see it and have the option to provide feedback. The smallest change possible, because it can easily be changed back if needed.
- Ask and receive feedback.
- Address feedback as needed.
- Make a revised proposal.
The person making the revised proposal may not be the same person as the one who made the initial proposal.
- Responsible individual makes a decision.
- Proposal is implemented.
- Cycle as needed, revert if necessary.
And by cycle, I mean, someone can open a new proposal for further changing, or building on, what’s been implemented. There may be a point where the person responsible says there won’t be further changes for now, but more often, there is a new initial proposal to improve what’s been done, iterating on the results.
This is a generalized process of course, so the order of steps might differ, some steps may not apply, and the amount of time spent on each step definitely varies. For example, feedback might only require a single person, and if they accept, revisions may not be needed. So the whole decision making process from start to finish might be less than an hour.
The important thing is that while we recognize the importance of gathering data and feedback, the person doing the work or the approver makes the decision.
Okay, I know that was a lot already, but that’s probably the meatiest one, and decision making touches on all the values.
For now, let’s move on.
Results
- Taking responsibility
I think it’s fairly well understood that individuals should complete assigned tasks, but part of the responsibility is anticipating problems as well.
- Use numbers responsibly
Statistics are important, but we should be cognizant of how we use them. For example, while it’s important to have an inventory of a collection, having more books doesn’t mean it’s a better collection; and having more users can’t tell you how engaged users are. This may seem obvious, but I’m not saying we shouldn’t use numbers at all. However, we should remember to use them responsibly, using them as evidence for a bigger picture or story.
- Bias for action
If we want our organizations to move faster, then we need to push people towards action, so that they become comfortable with seeing results based on taking initiative. Action shouldn’t be taken willy-nilly, but with the other values in mind. Of course, this comes with being able to
- Accept uncertainty, and the possibility of failure
accept uncertainty and the possibility of failure. We’ve all experienced failure. We wouldn’t be able to run a fail4lib session if we didn’t. We can foster a great deal of learning by letting people fail.
Efficiency
Being efficient is particularly significant in organizations where we’re trying to do things on small budgets.
- Global optimization
The idea behind global optimization is that it’s better to optimize for a larger portion of the organization, and not to implement something that might be more efficient for a small team if it means making things more inefficient for the rest of the organization.
- Make the smallest change you can
Making the smallest change you can means you can undo the change more easily if something goes wrong. It also makes it easier to iterate and tends to produce results faster.
Even if you’re planning at the level of a whole project, you can plan to make incremental changes to get to the end goal. Having the breakdown provides transparency into the process, and helps with collaboration and getting buy-in because feedback can be provided on a single step.
- Write things down
As a self-proclaimed documentarian, I am a big proponent of writing things down. Sometimes I am flabbergasted by how little importance is given to documentation in organizations that deal with written works and information. How do you know how your own organization works unless it’s written down? If it’s in someone’s head, how do you function if they’re unavailable or leave? What is your bus or lottery factor? Meaning, if someone got hit by a bus, or the more positive version, they won the lottery and decided to leave work, what would happen? Would the organization be able to go on smoothly or completely stall? Documentation isn’t the only way to reduce this risk, but it can be a huge factor.
Cross-training to ensure there are backups, or rotating people into specific positions that use a similar skill set are other ways we can reduce risk and give people variation in their work.
Diversity & Inclusion
- Assign a buddy/mentor
Often, we’re afraid to take up too much of a manager’s time, so having a peer as an additional contact can help someone feel connected. Even if they don’t talk a lot, it’s great to have a new member know someone is there to help support them.
- Build a safe environment
Call out and do not tolerate any sort of abuse or harassment. Beyond that, this goes back to not blaming people for work that goes wrong. People are not their work, though we can of course also be cognizant of the fact that people often see criticisms of their work as a personal attack so we should think about how we provide constructive criticism.
- Unconscious bias
It’s natural as human beings to classify things, and that includes classifying people. We should not only be cognizant of our biases, but also provide training for all employees. In-person training sessions, while often more effective are also much more expensive, but you can provide a short self-paced learning module and simply require completion as part of onboarding. Not only does such training help interactions internally, it can also be effective in public service roles.
Iteration
- Don’t wait
Even when given permission to publish code on a public repository, I’ve heard of code not being published because it “needs polishing”. Aside from the fact that code will probably never be perfect, other people cannot see, learn from, or make use of code if it isn’t published. That’s true for any resource. Releasing early doesn’t just create transparency, it also means you’ll get feedback or contributions earlier.
- About improvement
Viewing things as iterative means we should look at continuously making small changes. As long as it’s an improvement over the current state, then we should make those changes. I touched on this already in talking about collaboration and efficiency, so let’s move on.
Transparency
- Directness
We strive to be straightforward but also kind to each other. Clear communication without bull isn’t always easy to give or receive, but is important to how it related to other values and build trust.
- Single source of truth
In talking about documentation, having a single source of truth not only makes work more efficient, and usually collaborative, but it makes things transparent rather than needing to rely on people’s notes or even memory. Documentation becomes the source of truth and shared understanding.
- Public by default
I’ve already touched on this, but making things as public as possible means better opportunity for feedback, buy-in, and collaboration. Things are written down which increases efficiency so that people can read what they want or need instead of having to ask, and people in the know don’t have to repeat themselves to every person who asks. Making things public means others can learn from you, but you can also learn from them if they can propose improvements.
While people are allowed to make requests for information to many of the public institutions we work at, why do we force them into having to make requests for any and all information they might want to know about? If we’re allowed to talk and write about the work that we do, why make it hard to find those conversations and documentation?
I for one am forever indebted to the technical services departments that made their cataloguing guidelines and MarcEdit instructions public. I learned and pulled a lot from some of those to inform some of the work that I’ve done.
Take Aways
I know that was a lot, so a couple of take aways.
Positive Reinforcement
There are a lot of ways we can positively reinforce actions and work that we believe fit the values we consider important and what we want to see more of.
I think one of the more obvious ones is to
- Lead by example
and do what you would want others to do.
- Reward significant contributions
Rewards can be anything, including swag (take this mug as an example), bonus, or gift (the year the team I was part of won the CLA/OCLC Award for Innovation Technology, we each got a laser engraved bookmark, some places use gift cards as low as $5).
- Say thank you
In addition to thanking someone, consider having a place where messages of thanks are visible to others. You can have a thank-you-board or a section of your intranet for this. The team I work with at Gitlab even added a section for thank-you’s in our weekly team updates document. This not only shows appreciation for someone, but also lets other people know what specific things are valued.
Trust
Example: Matzler, Kurt & Renzl, Birgit. (2006). The Relationship between Interpersonal Trust, Employee Satisfaction, and Employee Loyalty. Total Quality Management and Business Excellence. 17. 1261-1271. 10.1080/14783360600753653.
A direct report once thanked me for trusting them with more responsibility. I don’t think it really sunk in what a big deal that was though until a few months into my current job, when I asked my manager about what I could improve on. In his response, he mentioned that I shouldn’t feel like I needed to ask permission to make changes or be afraid of stepping on people’s toes, and especially for small things, to just get it done because it’s more efficient. More than anything, he told me that:
We trust you to contribute.
I think trust goes a long way to improve a work environment. I feel privileged to work in an organization where I feel like I can trust people at all levels and across all teams, but even then, I think it’s important to ensure that there is a shared understanding.
(see contribution graph)
You can even visually see when I started to contribute more and more consistently.
If you’re a manager, please explicitly tell your reports, and if you’ve never heard it from your manager, maybe ask about it. And if you don’t have a relationship of trust between manager and direct report, consider having an open one-on-one conversation about why that is and how to increase the level of trust.
Do what you can
I’m not saying any of this is easy. What might be easy in one organization or situation, might be very difficult in another. Nevertheless, I truly believe that doing whatever we can to implement the values that we want to see, create the kind of positive work environment where salary becomes a secondary concern, and more importantly, where people want to work, will retain and attract new hires.
Thank You
Source: DeLoach, V. (2015). have a blessed Good Friday. Flickr. https://flic.kr/p/rVPrkD CC BY-NC-ND 2.0
Learning (Lib)Tech 