# Hiring Notes

> Talk about hiring strategy and boundaries (as input/mission for the committee)

## Project Outline

1. Brainstorm (in board & community) limits & risks of hiring
> see section below

2. Community consultation
> see section below

3. Draft the hiring practices
* Decide on criteria for when we -can't- wait for volunteers to step up
* We should stongly not prefer hiring when there are decent volunteer options.
* Brainstorm (in board & community) & write down checks & balances, on hiring rules, to address risks
* Strong preference against paid staff having prestigious job titles <-> job title can be practical, are cheap and make you a more attractive employer, also helps staff find another job when this project ends
* Hire from long-time volunteers (except if necessary to keep essential services going) <-> don't hire people just because they're volunteers
* Avoid paid leadership positions
* No "automatic" replacement of employees who leave
* Contractually enshrine that first loyalty is to the community <-> make sure people don't have 10,000 bosses
* Set a groundwork so that Dorothea does not find herself with a worse contract than others
* make employees cooperate remotely through the same platforms that volunteer contributors to that project also use
* How would we hire people
* procedures, budgets, committee, nitty gritty details
* Work out employment policies
* Define management protocols
* Define reporting structures
* Define interaction with community: expectations and "how"

MM: Keep a focus on creating a good working environment for staff/employees. So may need some finesse on the hiring practices. For instance job titles can be useful for someone's career path; volunteering should be a factor, but not the only one (a stronger non-volunteer candidate should not be unduly penalized); replacement isn't automatic, but backfill should be discussed; "loyalty to the community" could result in 1000 bosses, needs reframing.

AM: Should we explore the possibility of hiring small firms project by project? For example, hire a firm to assist the sysadmins, and contract for a definite quantity of hours of work, to be assigned by task orders from our volunteer sysadmins. Hire a firm to work on the API, but in this case specify the exact work to be performed, what's called a product-oriented contract. This would avoid most issues related to having "employees" and would leverage the existing OSM commercial ecosystem.

4. Community consultation

5. Implement: management, reporting structures, interaction with community

# 1. Brainstorm notes

## LIMITS and RISKS

### RISKS to model and mitigate

#### Harm to volunteers
* Crowding out of volunteers

* Paid work drives away volunteers, who don't want to do it if someone else is getting paid

#### Community Ownership
* Project becomes used to what the employee(s) provide, so there is no choice in rehiring, the project would _have_ to rehire, meaning rapidly needing to find funding
* Paid staff has other incentives than volunteers, less of an implicit filter for well-intentioned people
* Paid staff set direction of the project
* Who pays the piper, calls the tune. A company can tell us what to do, or they will pull funding
* Board (or whoever ultimately decides what people work on) becomes a lot more important → vulnerability for takeovers, departure from do-ocracy

#### Bad hiring outcomes
* Exponential growth of number of employees
* Nobody wants to work for us (or they burn out quickly)
* Paid staff don't interact with OSM contributors

### LIMITS

* Avoid exponential growth of number of employees
* Do we define a limit of X number of people, explicitly limit the growth rate
* Explicity ban certain terms in job titles: “Manager”, “Executive”, “Director”, “Chief”, etc?
* Require that funding for each employee comes from N different sources, who don't contribute more than 1/N of total
* Require funders have a X year cancellation notice period
* Re-evaluate after X time

## NOT COVERED

* Paying for this
* What general roles to hire for

# 2. First community consultation

The OSMF Board wants to think about a general framework to hire people to fill in the gaps that volunteers can't fill. We believe that, given good practices and firm boundaries, hiring people would be worthwhile. It could ensure the continued stability of the OSM platform (servers, integral software) among other things, and augment the currently overworked volunteers and under resourced efforts in the face of continued growth.

We would like to gather your input on strategies to have the highest possible positive impact at an acceptable cost, and with as few negative effects as possible.

~~Benefits~~
* ~~Stability of the platform (servers, integral software) is paramount to success of the project.~~
* ~~Paid services would augment the currently overworked volunteers who maintain the platform.~~
* ~~Demand for OSM services (data, tiles, geocoding) is growing by about 50% per year, which places an increasingly unsustainable burden on the all-volunteer sysadmins.~~
* ~~Outreach has surfaced community concerns about sustainability of the API based on a 100% volunteer do-ocracy.~~
> Compressed into the introduction [name=Tobias]

We had a brainstorm about this during the screen2screen, and these are some things we all agree on:

* We stongly prefer not to hire when there are adequate volunteer options. In particular, we are not going to engage in paid mapping.
* We need to define criteria for when we -can’t- wait for volunteers to step up.
* We do not want to grow an army of employees. We do not envision 20 employees within 5 years, let alone 200!
* We want to make employees cooperate remotely, and through the same platforms that volunteer contributors to that project also use.
* We should make sure all employees are treated equitably.
~~Some tensions are already visible:~~
* People with an OSM volunteer background should be preferred (because it demonstrates qualifications, added trustworthiness, and is the right thing to do), but we don't agree to which degree.
* We want to avoid paid leadership or decision-making positions ~~, but we do want people do have some freedom to do their work~~.
* We want people to work for the community, not for the Board. But we also do not want employees to have 10,000 bosses - that's a recipe for burnout.
~~* We do not want fancy job titles (“Manager”, “Executive”, “Director”, ...) - they might make people think they have special authority, when they will always be servants to the community. On the other hand, job titles don't cost money and are an attractive benefit to our employees.~~

Some of the risks we hope the community can help address include the following:
* Paid work can have a chilling effect on volunteering.
* Paid staff has other incentives than volunteers.
* Paid staff has more power to set direction of the project than a volunteer, if only because of the amount of time they have.
* Paid staff hired from outside the community may lack an understanding and appreciation for the way the community works.
* A direct link between organizations providing funding and a job being done might give those organizations undue power.
* The organization that decides what gets worked on becomes quite powerful, which risks losing the benefits of do-ocracy.

We know there are many issues with hiring people, but we hope that we can install meaningful guardrails against the risks. Your input will help us devise a strategy that makes sure we define the right jobs and hire the right people for them.

Feel free to share your ideas here or send them to [e-mail]