Effective Management: Want Things, Acknowledge People, Maintain Integrity

A Manager has three primary jobs:

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.

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.

Goals and dependencies with perhaps some of the actions to get to one from the other notated below.

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.

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.

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:

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:

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.

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.

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":

There are basically two kinds of jobs in this world:

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.

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

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.

[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.