Is GitHub's self-assignment of tasks a myth?
I’ve been listening to Scott Chacon‘s great talk at Cultivate, and during that talk he was sharing how employees at GitHub get to pick their own tasks. They let people pick tasks using a very simple “decision algorithm”:
Crazy, eh? Or is it?
As someone who’s never worked at the company with such freedom of choice in terms of task assignment, I cannot help but wonder how they handle the following scenarios:
1. Working on non-critical issues first: Say we’ve got 50 problems in our company’s backlog, ordered by priority, how do we make sure people will take the top problems that intersect with their interest? An effective organization, one may claim, would start with the most important problems, while at companies with a complete task assignment freedom, there is no guarantee that someone would not start with the 50th task.
2. What if there are important tasks with no intersection? What happens if there is an urgent task with a huge impact on the business which is simply not that interesting to the employees? Just remember the last time you had to integrate with some 3rd party vendor. The horror!
Should we force an assignment here or can we say “if it’s not interesting to our employees then we should probably not do it”?
It’s hard to imagine a situation where the company would not force a decision in this case.
3. What if we cannot eat our own dog food? Some of us are not working for companies in which the employee is actually a user of the product (GitHub employees are using their own tools all of the time). That makes it a bit harder, in comparison to GitHub, as there is no direct motivation to fix a bug or introduce a new capability.
“Let’s tell them what to do and motivate them with customers’ success (aka KPIs)”
Most companies, including the ones I’ve worked for so far, will assign the most urgent issues to their employees, by priority. Usually the Product Team (or CEO) will make sure the backlog will be prepared and prioritized to best serve the business needs. This makes it easier for each team, and team member, to pick the most urgent tasks and start with it. It reduces dramatically a situation of analysis-paralysis where employees do not really understand or sure what they need to work on and why. Then, we motivate our employees by looking at the metrics – did our effort just changed the KPI we were aiming for (say increased retention for the app)?
Using this paradigm, we couple employees’ motivation to customers’ happiness. The problem with this approach for the long run is that for most time, people would work on tasks here:
While it makes a lot of business sense, it raises a lot of questions:
1. Motivation and retention of employees – What happens if you let employees work on important problems that the company has, but with almost zero intersection to the employees’ interest? We can always go to the basics – improving our skills – there is value in merely learning to write better code, design better products or any other craftsmanship in the company. Working on tasks which will improve our engineering skills but would also cost us days of pain, would make anyone reluctant to continue and grow in the company for the long term. As @rands said before – “Bored people quit”.
2. Branding (type of people you’d attract) – Joining a company known for a very clear hierarchy and certain way to assign tasks, may create a very specific impression for your values. An easy way to see it is to compare a traditional manager-assign-the-tasks company to a self-assignment company. Trying to judge from no internal knowledge, who do you believe have employees who are more self-managed? Where do you think people are more or less motivated? Can you explain why? What about the expectations each company has from their employees? Do you prefer to work at a place which demands decision making abilities?
Even if your gut feeling is incorrect, it is still a great way to understand the difference in “branding power” between these two paradigms. Certain kind of people would naturally be drawn to each company, and it is my belief that if I had to guess, higher-quality employees would love to join a company who trust them enough to make their own priority and calls.
3. Mentoring (which behavior do you want to cultivate) – We are what we do, not what we say. In a company where managers decide on the task order, how can we mentor anyone inside to make their own decisions? Is it okay to let them determine the priority of the tasks inside a feature but force them to implement the feature because it matters most to the business? What does it tell our employees when we trust them only to priorities and decide for the tactics without applying the same logic to the strategies?
I’m not sure there is a clear cut here. There shouldn’t be. Obviously, GitHub encountered many of these situations I’ve stated above and solved them, but it wasn’t covered during the talk (Scott, mind sharing a nice link to Quora or a blog post, pretty please? ;)). The team at Treehouse took the same path and described the entire process in a few blog posts. It’s pretty incredible and inspiring to see how they expect their employees to “sell” their ideas and projects internally. For me, it says a lot about the kind of employees they want to have and what it would be like working there.
I do believe that self-assignment is something that companies should actively strive to. Not as an end-goal, but rather as a metric or score to track. Treehouse’s example is great, as they started as a traditional organization and made the move while also kept writing about their lessons learned during that transition. This change forces hiring (and retaining) self-managed people, or at least people who want to become such and have a mentor to show them the way.
Scalable companies are ones which built autonomy and self-purpose into their DNA. Having self-managed employees with great sense of balancing their own passion with business’ needs, for me, sounds like a great way to assure employees retention while having business success.
What do you think? Do companies like GitHub and Treehouse make an exception to the rule, or is it the beginning for one of the biggest cultural changes we’re about to see in the next 5-10 years?
p.s. check out my latest side-project, SoftwareLeadWeekly – A free weekly email, for busy people who care about people, culture and leadership.