Managers and Makers
A little over 20 years ago, I started working for the other large software development company. They had recruited me from college and I was honored to join them. At the time, the perception at my school was that no one got to work for them because everybody wanted to. In fact, many of my fellow students said, don't even submit your resume because it will end up in the circular file. I was thrilled when the company interviewed me and even more thrilled when they hired me.
Life at that large company was interesting. I started working on ECF, a mainframe to PC data transfer system written in OS/370 and later in a dialect of PL/1. When I started, I was clearly out of my league. The veteran programmers schooled the young college graduate (me) and I worked really hard to keep up with them. At some point though, working through lunch and into the night seemed to have paid off. I was one of the few "kids" on a really tough project but the veterans started to give me cudos for my work.
On my next project, we had a project manager who liked to meet to discuss status. It didn't matter whether it was 15 minutes or two hours, the meetings always seemed to interrupt when I was debugging a vital piece of code or writing something complex. Additionally, this large company had a lot "all hands" meetings which always seemed to come right before my deadlines. I would work late into the night to make up for a day where executives would spend the day BSing. Most of the time, they would tell us things like “If you don’t like working for this company, leave!” I was too busy building products to think about these things but the meetings started to give me ideas.
But the schedules had to always be made even if I lost an entire day to one of these meetings. I realized that as a coder, my priorities and focus was different than theirs. Peter Coad gave me the first clue when he said that every interruption to a coder required, on average, fifteen minutes for a programmer to get back “into the flow”. In other words, interruptions impact programmer productivity. And they impact the productivity greater than the length of the interruption.
Last night, I was talking about this with Brian Crissup. As a veteran programmer, I get back into the flow much quicker than I did in my youth (seems counter-intuitive). But he turned me onto the idea of makers and managers. The idea is that a maker's schedule is divided into large chucks of time of being “in the flow” to create a tangible element such as software.
A manager’s schedule is divided into one hour chunks (meetings) where information is communicated but nothing tangible is delivered (unless your company sells meeting minutes). When a manager injects an interruption (meeting) into a maker’s time block, it can have an impact far greater than that one hour block. It can destroy the entire large chunk that a maker needs to accomplish something tangible. Thus makers will often work into the night to get that block back while the manager goes home.
Depending on the urgency of the project, this can either be annoying or downright maddening. You see, the maker is responsible for the delivery of a tangible item so they are “on the hook”. While a manager just reports the lack of progress by the maker. As a manager, you get what you need through your meeting and leave the makers to pay the price.
One of my beliefs as someone who is now both a maker and a manager is to endeavor to make reporting painless to the makers. As someone who participated in creating TFS, I had always hoped that work items would allow makers to make and managers to manage without a cost to either one. The idea behind TFS work items and reports was exactly this ideal.