# Developers oriented project management: Take the first task

We recently talked how **[small](/2013/09/story-of-size-1/)
and [unassigned](/2013/10/refactor-to-remote-leave-tasks-unassigned/)
tasks can help you manage the risk in the project**. In short: they help to
guarantee that despite the obstacles people keep working on the most important
things.

But to take most from such
approach we need one more rule. Let's talk a little about it.

<!-- more -->

When project managers assign tasks to developers they will usually try to do it
based on who they think are most qualified for them. Unfortunately when
developers are in charge of assigning stories the effect is not much better. They
will usually try to take tasks, that they feel most comfortable with. Frontend
developers will take frontend tasks. Developers with more backend background
will take backend tasks. **The long term the effect is that people specialize in
particular areas of code and _Collective Ownership_ declines**. And this is exactly
what we would like to avoid.

This happens because sometimes the developers have different goals to your goals.
They want to make their job easy or fun, where the goal of the project owners is
to have the most important task get done. And the most important task is not
always the most compelling, neither related to the most fancy, recent technology
that the developers would like to learn and use

The solution is to have very strict and simple rule for the developers to follow. And the
rule says **Take the first task**. Where _First_ means unstarted tasks with highest
business value. When I join the project as a developer for the first time, or
on Monday after weekend, or after a two-week-long vacation, I am interested in
one thing only: _What can I do for you?_. The answer should be immediately
visible for me. I do not care if you use _Pivotal_, _Redmine_ or _Trello_. I just
want to look at the top of the list and finish your most important task today.
Get it done, deliver on production and forget about it.

## Get more

You can find out more in our book:
_["Async Remote"](https://blog.arkency.com/async-remote)_
or if you are not sure yet, by [subscribing to the newsletter](//arkency.us5.list-manage.com/subscribe?u=1bb42b52984bfa86e2ce35215&amp;id=4cee302d8a&group[15297]=4)
with tips and excerpts from the book similar in form to what you just read.

## In next episode

The next blog post will be about _Project Managers_. Whether you actually need them
and what are the alternatives to hiring them.
[Subscribe](//arkency.us5.list-manage.com/subscribe?u=1bb42b52984bfa86e2ce35215&amp;id=4cee302d8a&group[15297]=4)
to be notified when it is out.

## How about you?

**Is it immediately clear to you in your current project what you should be
working on as a developer?** How long does it take to figure it out? Do you need to
talk to someone to get that information? Leave your feedback in comments or
on [twitter](https://twitter.com/intent/tweet?source=webclient&text=Hi+%40arkency+I+have+just+joined+a+new+project+and+it+takes+me+XYZ+seconds%2Fminutes%2Fdays+to+figure+out+what+to+work+on).

## In this series

* [Story of size 1](/2013/09/story-of-size-1/)
* [Leave tasks unassigned](/2013/10/refactor-to-remote-leave-tasks-unassigned/)
* [Take the first task](/2013/10/take-the-first-task/)
* [Chronos vs Kairos: Find out how you think about time when working on a project](/2013/11/chronos-and-kairos/)
* [Developers oriented project management](/async-remote/)