Open allocation
Lua error in package.lua at line 80: module 'strict' not found.
Open allocation refers to a management style in which employees are given a high degree of freedom in choosing what projects to work on, and how to allocate their time. They do not necessarily answer to a single manager, but to the company and their peers. They can transfer between projects regardless of headcount allowances, performance reviews, or tenure at the company, as long as they are providing value to projects that are useful to the business goals of the company.[1] Open allocation has been described as a process of self-organization. Rather than teams and leadership arrangements existing permanently in a company, such relationships form as they are needed (around important projects) and disband when they are no longer necessary. Additionally, open allocation implies that projects are not unilaterally created and staffed by executive mandate. Rather, the person forming the project (who might not be an official manager) is responsible for convincing others to invest their time, energy, and careers into the effort.
Contents
History
The term lattice organization for an organization using open allocation was coined by Bill Gore in 1967. He used the term to describe the company he founded, W. L. Gore and Associates.
Google introduced and publicised an unusual perk known as 20% time, in which - in theory - employees have freedom over one-fifth of their working time, which may be put into a personal project or a high-priority internal effort outside of management's direction. However, the other 80% of the time employees would be still working under closed allocation, and also may not in practice be able to use their 20% time all of the time, for example due to deadline pressures.
While startups vary wildly in work environment quality and employee autonomy, one of the main selling points of technology startups in the early 21st century has been a claim - demonstrably true of the best startups, but not of all of them - that employees enjoy a high level of autonomy, at a level traditionally only seen in basic research labs.[2]
GitHub and Valve, in the early 2010s, became well known for having such environments. In 2013, Tom Preston-Werner gave a talk at Oscon in which he spoke about the importance of open allocation to GitHub's success.
Leadership under open allocation
Organizations using open allocation do not give middle managers unilateral control over their reports' work. People management, product direction, and project-specific leadership are, in this way, decoupled. One argument in favor of this is that when the people defining projects no longer have the unilateral ability to terminate employees or deprive them of opportunity, better projects and leaders (those that can convince, rather than coerce) will emerge. Middle management may play roles, however, in mentoring, handling of conflict (as an absolute last line of dispute resolution), and (especially) ensuring that new hires are appropriately "onboarded" into the open allocation system.
Leadership in an open-allocation organization is typically organic; the person to propose the project will lead it, if he or she can convince others to follow.[1][3] When projects end, the leaders may rotate back into being "followers", and there is no stigma attached to this.[4] Leading and following are temporary distinctions and largely by choice; one may choose to follow in order to learn more about a different part of the business, for example. Ideally, the leader for each project will be the most committed, capable or passionate person involved, and companywide rank (which may not exist at all) has little to no bearing on the selection.
Performance reviews in open allocation companies are handled in a variety of ways. Valve uses stack ranking driven by peer review to determine raises and bonuses, but unlike the hated stack-ranking regimes of other technology companies, these do not initiate termination or interfere with internal mobility, but are strictly used to determine compensation.[5]
Benefits of open allocation
- Information: In a closed-allocation company, the people doing the work and those deciding what is to be worked on are typically disjoint sets. This means that impractical projects are often proposed because the people responsible for the firm's executive function are deprived of important knowledge—in particular, whether the people doing the work consider the project worth investing their time, energy, and reputation. (If the answer is negative, they typically cannot communicate it, especially in at-will employment situations.)
- Peer review can be used and encouraged not only for source code, but also design, business strategy, and publicity.[1] More people are allowed input into the issues they consider important.
- Motivation: Employees who have chosen their projects are more likely to be productive and highly motivated. There is more personal pride at stake when the person selected or defined where to put his or her efforts.
- Personal responsibility: People can no longer blame bad project assignments or inept immediate managers for underperformance, since those are results of their own choices. A person who worked on a bad project, in an open-allocation environment, is at fault.
- Efficiency: Hierarchies of people (which frequently duplicate efforts) are replaced with conceptual hierarchies, but extra-hierarchical collaboration (the norm, in an open-allocation company) allows cross-domain knowledge to be formed and deployed. An employee who wants to start a new project that may add value to the business can do so immediately, but those that require investment of others' resources and time require convincing them that the idea is valuable.[5] In essence, workers are trusted with their own time, but disallowed from attempting to control others' time.
- Communication: In the ideal open-allocation environment, anyone can communicate with anyone else in the company, without having to pass a message up and down a management relay.
- Less waste: One theory on the causes of corporate efficiency is that much unused or low-quality work is the "promotion-oriented" kind, directed by a manager for his or her career goals while generating little or no value for the company. Under open allocation, it is difficult to staff such projects. However, unpleasant but important work will get done, because performing it well will lead to more esteem among peers, and make it easier to lead others in the future.
- Low turnover: Open-allocation companies typically have low turnover.[citation needed] People rarely leave, because the work environment is considered superior to the norm; they are rarely fired, because there are so many avenues toward success that most people can find a project where they can perform well.
Problems
Because open allocation is an unusual organizational style, it can be at odds with external demands on an organization. For example, consulting companies that promise a certain number of staff will work on a project must assign work to people in order to meet those commitments. Additionally, regulatory pressures such as Sarbanes-Oxley may require that people are assigned to certain duties.
Additionally, open allocation's strongest successes are in businesses in the areas of science, technology, and in particular, software - the most successful of which are typically staffed by highly competent and educated people. Whether the successes of open allocation apply more generally to other types of organizations is an open question.
Finally, terminating employees in an open-allocation environment can be challenging, because establishing a performance-based case in such a flexible environment is difficult.[citation needed] While open allocation generally creates fewer of the "unlucky" low-performers who landed on the poorly-fitting projects or with incompatible managers, and therefore tends to reduce turnover (voluntary and involuntary) dramatically, it doesn't provide a mechanism for getting rid of severe under- or non-performers who "hide" in the organization. This has not been an issue to this point, if only because the companies using open allocation have been highly selective ones that can hire people with strong track records. Furthermore, the increase in performance among high performers under open allocation is typically so dramatic as to counteract any risk of decline among the lower performers.[citation needed]
Organizations using open allocation
Organization | Industry | Type | Number of employees | Used open allocation |
---|---|---|---|---|
Valve Corporation[1] | Video games | Private company | 400[1] | Founding year - date[5] |
GitHub[1] | Technology | Private company | 175[1] | Founding year - 2014[6] |
Treehouse[7] | Technology | Private company | 60 | June 20, 2013 - date[8] |
W. L. Gore and Associates | Manufacturing | Private company | 9,840[9] | 1958 (founding year) - date[10] |
Monk Development[11] | Software as a Service | Private company | 25-30 | 2013 - date |
Mechanics
At Valve Corporation, employees' desks have wheels under them, allowing them to move to another team with ease - a symbolic as well as practical marker of Valve's open allocation approach - and physically reorganize as their projects demand.[5]
GitHub, on the other hand, has many remote employees, so team membership is to some extent determined by which chat rooms an employee is in.[1]
Treehouse allows any team member to switch teams at any time, but says that it is "not cool" to leave a team at a critical time or when you are needed by your team-mates, and such an action would be reflected in poor performance reviews.[7]
See also
References
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ 5.0 5.1 5.2 5.3 Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ 7.0 7.1 Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Cutting Edge Agile, Part II: Open Allocation Agile SD. 5 January 2015.
Further reading
- Lua error in package.lua at line 80: module 'strict' not found. - which discusses W. L. Gore and Associates, amongst other topics