In the early days we used to have a central dispositioning approach for our sales stuff at it-agile. A customer called us and our CEO answered the call. He figured out what the customer wanted. Afterwards, he searched for the right guy to do the job.
He knew all the employees very good, so most of the time he found the right person to do the job. This comes with a price: he had to know where everyone was at any given time and how long their job would last. Since we are doing all coaching, training, and consulting, or software development jobs, it’s hard to tell how long a job will last. Our CEO was in a constant controlling mode. He had to be.
This controlling job was easy to do as long as we were only a dozen people in the beginning, but got harder as our organization grew. Over time, we got an officer with procuration and a second CEO, so more manpower to do sales stuff. With more people doing sales stuff, the coordination of sales became more difficult. The decisions became worse, sometimes customers complained.
The biggest pain we had was, that nobody at it-agile really wanted to do sales all the time. We all wanted to do Agile coaching or training, to consult or develop. The more we grew, the bigger the necessity to have corporate sales become a full time job for a few people.
Then we changed to pull.
These days, everyone at it-agile is encouraged to do sales. We coordinate our work with a Kanban board. Whenever a customer calls us, Moneypenny – our organization team – creates a ticket on our board and puts it into the first column called “request”. We then tell the customer, someone will contact him within the next week. Then we wait for someone of us to pull the ticket.
Everyone is allowed to pull this ticket. If nobody pulls it, one of the Moneypennys calls the customer and explains that we’re all booked out at the moment and that he might try again in a few months. If nobody pulls, we’re booked out. It’s that simple.
If someone pulls the ticket, he’s the new ticket owner, the guy with the sales hat on. The ticket owner moves the ticket into the next column “clarify request” and calls the customer. He then clarifies what the customer wants and how we can help him. He documents his findings in the ticket and moves it into the column “staff request: searching”. He tells the customer that he’s now looking for someone in it-agile to do the job. Even though it’s a bit untrue, because he’s not looking: he wants to be found. He’s actually waiting for someone to pull the job.
If nobody pulls the job, the ticket owner calls the customer and explains that we don’t have the capability or capacity to do the job. Furthermore, he might refer him to someone outside of it-agile who might be able to help the customer.
On the other hand, if someone pulls the job, the ticket owner pulls the ticket into the next column “staff request: found”. He calls the customer to tell him that he found someone to do the job. Then he makes the customer an offer with a price tag attached.
This pull system has several advantages for us:
- It’s a self-regulatory system: when we’re “land submerged!”, we don’t do sales stuff and have to apologize to our customers for not being able to take on their job; when we don’t have enough jobs, then we have time for sales stuff. That’s not a black-or-white thing but a greyscale.
- There’s no single-point-of-failure (aka CEO): lots of employees at it-agile can do corporate sales these days, and it’s an open and transparent system so everyone is able and encouraged to join.
- Experts decide, rather than management. Our people are the best ones to say whether they can do the next job – and then they just pull.
- Push doesn’t scale for us, but pull does scale for us. If we’d still push, we’d have a huge part of our organisation controlling everyones job. With the pull system, I see scaling at least for the next dozens of new employees at it-agile.
- it-agile’s employees are self-responsible for getting a job, not through some managers. If you’re an it-agile employee and don’t have a look onto our board on a regular basis, chances are pretty low that you’ll get a job.
We made it from push to pull, and it wasn’t easy. We had to overcome several trust issues, like: Why is nobody else pulling this ticket? Is it because they can’t do the job right or are they just lazy and think someone else will do it for them?
To overcome mistrust, we talked. Whenever we wanted to know why a ticket wasn’t pulled, we asked our employees why they hadn’t pulled. Sometimes we learned that there were good reasons we had not considered (like all the people capable of doing the job were working with other customers at the time), sometimes people were reminded of the capability or capacity they didn’t consider (like someone who thought he couldn’t do a training when others thought he was ready to do it). Over time, we learned to trust the pull principle, and finally ourselves.
Great things happen when you pull, things no one could have imagined. For example, normally our consultants do the sales stuff and both developers and consultants pull job tickets in the “staff requested” column. Once one of four developers had a developer job at one of our customers. That job of hers ended at a time with no developer tickets on the board for a longer time. So she had nothing to do. During her search for new work, she thought: “Hey, I could try to pull a sales ticket.” And so she did and succeeded in doing so.
Who’d’ve thought? If we still had a push system, I doubt that we would have pushed a sales ticket to a jobless developer. Since we have a pull system, magical things like this happen.
We also use pull to hire people. Whenever someone sends us her application papers, she becomes a ticket on our hiring Kanban board. The ticket gets pulled from one of our senior consultants, who establishes the first contact with the applicant and stays in contact with her until we either say “Good bye!” or “Hello, new member of our family!”.
The senior consultant then sends out a pull request as an email to the rest of the company. He explains who’s applying for a job and requests three other participants for the job interview. People at it-agile will then have a look at the applicant’s papers, and if the applicant looks promising, people will pull a place for the job interview. If the applicant does not look promising, nobody pulls a place for the job interview, and the senior consultant will say “Good bye!” to the applicant eventually.
Again, like looking for their work (aka new jobs) when working at our customers, our own employees are responsible for hiring new people, not some managers.
“With great power comes great responsibility.” — Peter Parker aka Spiderman, super hero character by Stan Lee
Furthermore, we use pull on several smaller occasions:
- Peergroup members and mentors are pulled.
- Conference owners (people responsible for everything we do at a given conference) are pulled.
- Moderators for internal retrospectives or open spaces are pulled.
- Coworkers for a new product, e.g. a new training, are pulled.
Also, meetings are optional:
“Meetings at it-agile are optional. Every employee decides for himself if he attends. […] As long as the results are achieved everybody can work when and where he wants. (Of course this has to be coordinated with colleagues and customers since most of the results can’t be achieved without colleagues and customers.)” — Stefan Roock in it-agile: State of Play
In all these cases, no one at it-agile has the authority or higher place in a hierarchy to command these jobs. We just trust in the responsibility and the commitment of our people. So far, it worked well.
- [The Pull Principle] On Supermarkets and Balance Weights
- [The Pull Principle] People Signing Up for Work
- [The Pull Principle] How to Pull a House
- [The Pull Principle] Pull Your Next Job and Work Mate
- [The Pull Principle] Don’t Impose Commands, Offer Choices!
Pingback: ALE2012 Lookback | Markus Gärtner