A Manager has three primary jobs:
Want Things,
Acknowledge People, and
Maintain Integrity.
People will do anything, including even give their lives, if they have a well-defined goal, are acknowledged for their contribution, and their activity is a joyful expression of truth.
"Smart people will always do cool stuff, but they need to do the right cool stuff."
— Peter Akeman, co-founder of a successful software startup
Prefer organizing people using Human Makefiles over Human Scripts.
Todo lists are Human Scripts. Locally they are ok, but managing people with todo lists is problematic.
Scripts do not easily parallelize.
Scripts do not allow easy separation of specification and implementation — this separation means the wisdom, intelligence and creativity of the result is limited by that of the authors of the script, who may be a few.
Scripts induce one to adopt an arrogant mental state: the state of a mind attempting to manipulate reality to its will. For the same reason, scripts are brittle.
Goals and dependencies with perhaps some of the actions to get to one from the other notated below.
Makefiles are a dataflow language and tend to parallelize trivially.
Specification and Implementation are separated, and so the wisdom, intelligence and creativity of the result is limited by that of the implementors, who may be many.
Scripts induce one to a mental state more receptive to not knowing how the path of the result will go: the state of mind of one "dancing with the world" or "responding to causes and conditions". Makefiles tend to be more flexible as conditions change.
The coherence of this should be manifest in a single document checked in to a Team Repository. This document should probably be called TeamMakefile. Maintaining this document is one of the primary responsibilities of management and it should be updated at least once a day.
Each engineer should have their own personal Makefile(s) in the same Team Repository. I spend much of my time just managing myself and all the ideas I have for what needs to be done next. I have one big Makefile for my whole life. If one project gets big enough, I factor it out into its own Makefile. Do not work on anything unless what you are working on is in the Makefile; otherwise, what the heck are you doing? If you want to do something not in the Makefile, ask yourself "what is the goal I am doing this for?", then add this goal to the Makefile.
If you find yourself procrastinating, be sure to procrastinate correctly. People only procrastinate because they do not see clearly the next task. If you are procrastinating, you are not doing work, so instead take a goal and break it down into sub-goals, thinking "if I were doing work right now, this is the work I would be doing." This is quite a pleasant way to spend time and I have found that whenever I am tired of doing work, I am still willing to break down tasks in my makefile. Eventually the tasks get so small that you will just say "oh, what the heck, I'll just do this one".
A properly maintained Makefile containing all the goals and sub-goals and with sufficiently fine-grained tasks will call you forth powerfully. I have gotten into a state of anti-procrastination where I cannot stop working on something because the vision of the goal and the tasks needed to achieve it were so clearly presented that I just couldn't stop doing the next one and the next one and the next.
If people were truly motivated by money, science, art, civil society, and churches and the Open Source movement would not exist. Something else is at work: people want to make a difference and they want the difference they made to be acknowledged. One of the primary activities of war is singing the glory and honor of your fallen fellow warriors. Think: why is an unsung hero considered a tragedy?
People want to be part of the story. No matter how small their contribution, they just want to know that someone knows. One of the best acknowledgments I can imagine is to bring the secretary in front of the room and say what a great job she has done: absolutely no one has noticed her for three months! That's her job.
Don't acknowledge people for bullshit, the way the American K-12 school system graduates people who can't read. More than anything doing so destroys people because they no longer trust any of the feedback they get from anyone and they know the story about themselves is a fraud.
Acknowledging people may sound easy, but if you have never acknowledged someone in front of a team, you might be in for a shock: people are very uncomfortable with both being acknowledged and with acknowledging others. One thing people tend to do avoid their discomfort is to get silly and pretend that it is not serious or a waste of time: think of how many people don't go to their graduations.
You must insist on a little seriousness ceremony just to make it work: The person being acknowledged should stand and to go the front of the room. The manager should acknowledge them for something specific. Perhaps someone who worked with them should also acknowledge them with a little story of what happened. People then clap, even if the manager has to tell them "the traditional ceremony of acknowledgment in this culture is that we clap — now do it!" The person being acknowledged has an asymmetric role in this ceremony and does not clap, even if they have to be prevented from doing so.
"Constraints are Freedom." — Engineering saying
"Freedom is not Free." — American saying
People to work for something beautiful. I was once told this story: A man is walking and meets another man sadly and slowly hammering on a rock. The first man asks "what are you doing?"; the second replies "breaking rocks." The first man walks further and meets a third man enthusiastically wailing away on a rock with all his energy. The first man asks "what are you doing?"; the third replies "building a cathedral!" If you lying, cheating, or stealing in the slightest way to get to a goal, such as money, you aren't building a cathedral and everyone on your team knows it.
To a first-order approximation moral codes throughout the world seem to say primarily: Play a Win-Win Game. This is not just a good idea. Buddhists at least insist that doing so literally is the difference between Heaven and Hell — not later — but on this earth and in this very life right now.
Rigorously enforce win-win behavior. People want to work with others who a playing a win-win game. People playing politics is a win-lose game and that's why it destroys morale. The problem is, that it is easy to think that some people are the good people and some people are the bad people. I think Shunryu Suzuki said it well when he pointed out that instead of thinking good versus bad, think to do or no to do. For one thing, it gets your attention on the behavior, not the person. The same person in a different context can behave very differently. In any case, win-lose behavior is not fun playfulness between employees, it is something that must be handled instantly.
[Suzuki-1970, p. 30] Good and bad are only in your mind. So we should not say, "This is good," or "This is bad. Instead of saying bad, you should say, "not -to-do"! If you think, "This is bad," it will create some confusion for you.
Do not tolerate even suggestions of win-lose behavior. I was in a meeting of our whole startup once, and one of the other employees suggested that we tell a "small" lie to a customer. I objected that we should not be lying to customers. He said it again, and I objected again, but no one seemed to be noticing. He said it a third time and I stood up and in front of the CEO and everyone told him in a loud voice that I was going to take him outside. I was sent out and put on probation, but I was sure I had done the right thing. That company later collapsed mostly due to the lack of integrity of the way the business side was being run.
When the boss says something, others rely on that. The reason C is such a popular programming language is because it is solid: looking at C you can see the assembly language underneath and that is the truth of what the program is really doing. When you are the boss, you need to provide that kind of solidity to the team. Consider carefully and then speak. And further, you cannot avoid speaking: avoiding making promises has no more integrity than breaking them. Solidity and progress are both necessary.
If you make a decision, and then an engineer relies on it, and then you change your decision you never get to say "well, I'm the boss and that's the way it is." You owe the engineer a sincere and public apology. Your engineers will respect that.
Once people start not taking schedules seriously, it is a rapid slippery-slope into disorganization. When you are even one second late, say "I am late." Do not avoid it.
In Zen temples, if you are even one second late, the Zendo door is slammed in your face. The circumambulation ceremony happens and then after five minutes the door is opened again to let those who are late in and then shut again for the duration of mediation period. Personally I think the door should be shut when a meeting starts. When it opens again there should just happen to be no free chairs for the duration of the meeting.
Note that all of these rules apply to the boss even more so. You can't ask people to do something you don't do. I once was volunteering for an organization and I showed up for a meeting with my boss's boss. He insisted that everyone always be on time and I was. He was late. He said "I'm late, but I'm the boss and that's the way it is: you wait for me but I don't wait for you." His voice smirked as he said it. He simply destroyed my enthusiasm for volunteering there by that one act.
Most bosses seem to not want to hear what is not working. This is insane. Every time I hear a story about some company disaster, it always seems to be because:
something started to go wrong,
the people who noticed it were afraid for the boss to find out,
so they hid it,
and the problem got worse.
Your jobs is to be the person who every knows when things start to go wrong, they can go to you. You can't fake this; you just must want to know what is going wrong.
One thing I really want to know about any system is what the gotchas are: the emergent properties of the system that I'm not going to expect. Here are some that occur to me.
Conflicts between people come up. Management actually has very little real choice about how to handle them. People have a very specific sense of fairness and management had better follow that or they will loose the respect of the team.
If you call someone into your office to talk to them about their behavior or handle a conflict, people will just tell rumors and make things up because they don't know what happened. Address behavior, not people.
Someone once assaulted me by ramming his body into mine to get through a doorway he was not authorized to enter; I subsequently kicked him in the head. Unfortunately he happened to call the police first and the officer who came refused to even listen to my side of the story. The officer's mind-set was already in that of the first story he had heard.
Ownership is an ancient distributed decision-making algorithm that works really well.
Most conflict arises because people do not have a clear sense of who is allowed to do what. Since people are doing things all day long, most decisions of what people are or are not allowed to do must be very "lightweight". People should own:
Resources: such as physical space and the "right to the quiet enjoyment" of it.
Responsibilities: anything that needs doing has exactly one person who owns that it gets done. If no one owns it, then the manager owns it.
Creative result: sure the company legally owns all the code that engineers write, but within the company source code should be owned and maintained by the author and no one should be able to alter it.
Just as society would collapse into violence if the judicial system did not take seriously the exact and rigorous enforcement of ownership the team will collapse into passive verbal violence (politics), aggressive verbal violence (arguments) or in severe cases actual violence, if the management does not take seriously the exact and rigorous enforcement of ownership.
Many times an architecture of technology can prevent or solve social problems; when this is possible it is a huge win as social problems are much more difficult than technological problems.
Use a source code control system such as Mercurial or Git where each engineer has their own repository. There are never arguments as to who has check-in privileges because everyone can check in only to their own repository; however people can pull from each other's repositories.
If Fred owns the problem of producing a Foo, then the Manager is going pull the official Foo from Fred's repository. If others want to help Fred, they can do part and if Fred likes it, he can pull from them and he gives them an assist when he reports to management.
Any man can withstand adversity. If you really want to test his character, give him power.
— Abraham Lincoln
You simply cannot ask your team to do anything you are not willing to do. I worked at a company where we basically had a part-time technical boss; it was a disaster. Decisions are being made constantly and this computation flows through the boss; if this flow is not working, the whole team is not working. If you take the power, you must use the power, because by having the power you are preventing others from having the power, which prevents them from doing things and making decisions that need to be made.
Social status is basically who is in charge when to people meet: the one with higher social status. While maintaining a coherent organization requires a hierarchy, in many organizations the managers like to abuse the employees because the like demonstrating that they have the higher status. This produces no good result whatsoever. Do not do it. If you catch yourself doing it, it is your fiduciary duty to your company to fire yourself.
[Spolsky-2000] … It reminded me of a visit I made to EDS once when I was working for Microsoft. EDS had modern, clean, well lit offices, but they were just seas of cubicles. Any kind of personalization of the workspace was forbidden. Fluorescent lights everywhere. Windows were strictly for managers. If you've seen the movie Office Space, you know what I mean. As I left the building with my Microsoft colleagues, I remember saying, "you know, if I had to work in a place like that, I'd cry for two hours when I got to work in the morning."
Notice that telling people what to do is not on the list. Anytime a manager has to tell someone what to do, they loose points in that big scoreboard in the sky. Why did you have to tell someone what to do? Why was it not clear to them already?
Avoid the Illusion of Power: Prohibition was a time in the United States when alcohol was basically illegal. I did not work: people kept drinking anyway; however as it was illegal the industry went underground and lacking in regulation and oversight, the problems it caused just got worse. As Zen Master Shunryu Suzuki says it well in "Zen Mind, Beginner's Mind":
[Suzuki-1970, p. 32]: Even though you try to put some people under control, it is impossible. You cannot do it. The best way to control people is to encourage them to be mischievous. Then they will be in control in its wider sense. To give your sheep or cow a large, spacious meadow is the way to control him. So it is with people: first let them do what they want, and watch hem. This is the best policy. To ignore them is not good; that is the worst policy. The second worst is trying to control them. The best one is to watch them, just to watch them, without trying to control them.
There are basically two kinds of jobs in this world:
jobs where you get to make a mess, and
jobs where you clean up the mess.
Most people want to do the first and not the second.
It is very important that everyone be doing both kinds of jobs. In Japan, they have no problems with graffiti at school: the students are the janitors. In a Zen Buddhist temple, the highest ranking monk is known as the Shuso, or "Officer In Charge of Temple Purity": the one who cleans the toilets. There was a famous Zen Master who was very beloved by his students, and in his old age, they no longer wanted him to have to work. He refused to stop working. So they hid his tools. He stopped eating, saying "a day without work is a day without eating."
Joel Spolsky hits the nail on the head when talking about how not to use social status in a company.
[Spolsky-2000] At Microsoft, for some reason, lots of people at the lowest rung of the hierarchy were completely satisfied with their jobs and were happy to go on doing them forever. Whereas at Juno, people in the same positions rapidly got frustrated and wanted to leave because they couldn't get promoted.
I think the crucial difference here was in the corporate culture, specifically, in the way management worked.
At Microsoft, management was extremely hands-off. In general, everybody was given some area to own, and they owned it. Managers made no attempt to tell people what to do, in fact, they saw their role as running around, moving the furniture out of the way, so their reports could get things done. . . .
At Juno, quite the opposite was the case. Nobody at Juno owned anything, they just worked on it, and different layers of management happily stuck their finger into every pie, giving orders left and right in a style which I started calling hit and run management because managers tended to pop up unannounced, give some silly order for exactly how they wanted something done, dammit, without giving any thought to the matter, and leave the room for everyone else to pick up the pieces. The most egregious example was the CEO and president of the company, who would regularly demand printouts of every screen, take them home, and edit them using a red pen. His edits were sometimes helpful (spelling and grammar corrections), but usually, they demonstrated a complete lack of understanding as to what went into the screens and why they said what they said. For months later, we would have meetings where people would say things like "Charles [the CEO] doesn't like dropdown list boxes," because of something he had edited without any thought, and that was supposed to end the discussion. You couldn't argue against this fictional Charles because he wasn't there; he didn't participate in the design except for hit and run purposes. Ouch.
Hit and run management is but one symptom of what I would call Command and Control Management… something right out of the General Motors 1953 operations manual. In a particularly political company, it even becomes worse — more like Command and Conquer management. It's completely inappropriate because it makes people unhappy, it causes the person with the least information to make the decisions, and it doesn't allow a corporation to take advantage of all the talents of the people it hired. If, like Juno, the corporation had been careful only to hire the brightest, most talented people, then it squandered an incredible resource and made those talented people frustrated as all hell.
Coherence is the property of the many acting as one. This state does not happen by accident and will rapidly degrade and cease unless constantly maintained.
Any reductionist approach to Team is doomed to fail. The most important thing is that everyone on the team is playing a win-win game with everyone, rather than a win-lose game. The management section talks about what management can do to promote and maintain this. However, one thing not to do is to see a programmer as just a programmer: even if they are a really good programmer, if they are destroying team around them, they must be removed from the team immediately.
Team is facilitated by shared state; accomplishing shared state by means of "communication", such as emails, doesn't work very well. What you want is a coherent vision of the aspects of the team, which is better incarnated as a document rather than a pile of emails; emails are like diffs in the state, but with no patch and no revision control. Therefore shared state should be maintained in a single Team Repository: a shared version-controlled repository.
Lightweight Markup languages, such as Re-Structured Text (ReST) allow for ease of editing, ease of viewing in text and sending in traditional text email, and ease of viewing as they can be converted automatically to other formats. This document is written in asciidoc instead of ReST because I don't know ReST yet.
I like reading about Agile [agile] and Scrum [scrum] Methodology, but I have never been on a team that used either of them. However I think the lack of
a daily scrum and a Scrum Master to resolve blocked dependencies
tasks scheduled into small tasks and
coding in well-define sprints to well-defined goal states
led to many problems on other teams on which I have worked. Reading about Scrum on Wikipedia now, it sounds more like what my intuition says is really going to work. I love these descriptions of sprints and meetings, quoted below.
[scrum] During each "sprint", typically a 2-4 week period (length decided by the team), the team creates an increment of usable software. The set of features that go into a sprint come from the product "backlog", which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint.[1] During a sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software.
[scrum] Each day during the sprint, a project status meeting occurs. This is called a "scrum", or "the daily standup". The scrum has specific guidelines:
The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)
All are welcome, but only "pigs" may speak [dsw: see article for definition of "pigs" and "chickens"]
The meeting is timeboxed at 15 minutes regardless of the team's size
All attendees should stand (it helps to keep meeting short)
The meeting should happen at the same location and same time every day
During the meeting, each team member answers three questions:
What have you done since yesterday?
What are you planning to do by today?
Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)
At the end of a sprint cycle (every 15-30 days) a "sprint retrospective" is held, at which all team members reflect about the past sprint. The purpose of the retrospective is to make continuous process improvement. This meeting is timeboxed at four hours. Two main questions are asked in the sprint retrospective:
What went well during the sprint?
What could be improved in the next sprint?
[agile] http://en.wikipedia.org/wiki/Agile_software_development.
[scrum] http://en.wikipedia.org/wiki/Scrum_(development).
[Spolsky-2000] Joel Spolsky, 2000-, http://joelonsoftware.com; archives are searchable. Read the entire archives of Joel Spolsky's blog. Yes, read all of it. Two print editions of the archives exist.
[Suzuki-1970] Shunryu Suzuki. 2001, 1970. Zen Mind, Beginner's Mind. Weatherhill, New York & Tokyo. This is the most helpful book I have ever read.