How Thomas Jefferson prepared for meetings | Hacker News Reader

How Thomas Jefferson prepared for meetings

johndcook.com

159 pointsgnosis22 comments

No disrespect to Mr Jefferson but this management method does not work.

It always results in a pyrrhic victory and resentment from the other people on the table from being made to look incompetent (although the truth is that indeed, they are for not coming to meetings prepared).

Let me explain

My last job was President of a College Newspaper. It was a pretty cool job. I had lots of power and I felt like I was "the one" who would usher this paper into a web 2.0 era. I came up with this grand plan and all. Unfortunately, much of the rest of my board was largely incompetent (or this was what I thought). Also, running the college newspaper wasn't as much of a passion for them as it was for me. They all had better things to do.

Ofcourse the natural resulted. Lots of meeting where we would not make quorom. Discussions without reading the background material however earlier on we had sent out a padded agenda etc. Naturally also, I was the most prepared for most of the meetings. I knew our Byelaws and PnP in and out and ofcourse, I knew the operations and management procedure for the newspaper, start to finish at the back of my hand. I got my way at meetings a lot of the time because no one at the table knew better and the people who knew better knew I was (mostly) right.

Soon enough however, resentment had begun to build. I was "arrogant" and an "asshole". We were always moving "too fast" even when it was clearly the right management decision (often taken 2 weeks after it should have). My VP was beginning to overrule management decisions we had discussed at meetings she had failed to attend for one reason or the other. In short, it was chaos.

I started work in May. By October, I was insane, overworked, single and had not spoken to my family in months. I resigned.

Long story short: If you are banking on the ignorance of your team to succeed in a project by pushing through your agenda. You have already lost. Surround yourself with people smarter than yourself, who will come to meetings as prepared as you are. Watch your project, team, committee soar. Surround yourself with morons who are too slow to keep up with you and you'll always be lagging behind.

You can trust I took this lesson to heart when I started building my own startup.

I don't intend to be disrespectful to you, but were you perhaps arrogant and an asshole?

In the past, when I was passionate and full of ideas on a particular subject, I have later looked back and noticed my behavior to be.. less than what I would expect from myself. It was too easy to take that energy I had invested in my ideas and snap that around negatively toward others when they came off as ignorant or wasteful of my time.

The historical anecdote of Thomas Jefferson may have left out - for brevity, focus, or other reasons - the notion that Jefferson not only prepared heavily for the meeting, but likely also won over the participants through diplomacy. It's never just one trick that wins the day.

If you're building a team from scratch, that's wonderful. If you are coming into an existing committee or group of people, the soft skills come in very handy.

Before you take my comments as a quick insult, would you be able to look back at the entire newspaper debacle and see if there wasn't anything you could have done better to win people over? In retrospect only, consider those "stupid" and unprepared people a lost cause. It's not for their benefit but yours.

I actually considered this possibility after I resigned. It might sound pretentious but no I wasn't. I was just stuck with a bad board.

Why? First it had a track record for organizational incompetence. I should have known better but few of my predecessors especially the more competent ones had had a good experience in that position. They had all warned me when I began but in my naivete and exuberance I still took the position and assumed I could change everything. Second, after I left, one by one the board turned over and it became very obvious that I had simply been shouldering too much personal responsibility with making sure our organization ran smoothly. I ended up still having to advice the organization from the outside after resigning.

Most importantly, till this day, I still have a good relationship with many of the more competent people in the organization (many of whom were recruited by me). The organization remains moribund however, bound together only by the strings of infrastructure (and personnel) I left behind.

Nonetheless, I think the more useful point I have to admit you make is that when you are joining an existing committee or group of people, there is a bit of compromise that goes on. To that, I say, make sure you check the background of the people you are working with before taking up any position. If they are people with a track record for incompetence or failure (in my case the fact that many of the people I was working with had been staff with this organization for several years should have been a warning signal),don't accept the position. Your peace of mind is way more important than any opportunity to marktime in the name of making a difference.

Given human nature, it was probably both.

The only way this usually works in software is to JFDI (Just Freakin' Do It). The thing that Jefferson did is he did the _work_ , not just present the idea. In software, the "work" is running prototype code.

Even then if you have a "vision" person, they may not be 100% sold if they don't like the design, but know your audience a bit you can be prepared for it.

I understand what you are saying, because very early on in my career I was one of those people that would present ideas, even architectures and expect people to get on board....now I realize that you have to sometimes drag them and in software, you drag by showing them something working and how it is possible...give them something to tweak and criticize that is real working code, not drawings on a page.

>"The thing that Jefferson did is he did the _work_"

Jefferson didn't do it alone - his team slaved away for him.

Literally.

University of Virginia's Apology for using slave labor in the execution of Jefferson's plan [2007/4/27].

http://www.virginia.edu/uvatoday/newsRelease.php?id=1933

"The only way this usually works in software is to JFDI (Just Freakin' Do It)."

Aka "rough consensus and running code" - as used by David Clark and the IETF: http://www.ietf.org/tao.html#anchor3

If you've got an idea - _and_ a plan _and_ a working implementation of that plan, you'll get taken much more seriously that the people who're trying to come up with ideas on the spot (even though occasionally their ideas might genuinely be better than yours).

This works very well IME. There is a potential issue however, in that if you are too prepared, you become married to your vision, even when someone else points out fatal flaws. Essentially you can lose flexibility.

This may or may not be what is desire, but I have seen projects go down in flames because of over-prep. The goal is to find a nice balance.

If you know what you're doing, then you'll actually be the first to dismember your original vision. Indeed, a principle value of this approach is that when you do hit the inevitable need for changes, you're already well acquainted with how all the pieces fit together. This allows you evaluate options by considering not only their obvious pluses and minuses, but also by anticipating the more hidden costs and benefits of any given alteration.

This (I believe) is what Eisenhower meant when he said "plans are useless, but planning is invaluable."

I concur, in principle, but in practice I have both seen and experienced what happens when one gets too involved. It can be quite the challenge to accept that a good idea is coming from some jerk who didn't even bother thinking about it before the meeting. Or worse, the fatal flaw gets pointed out by someone who has spent the last half hour trying to torpedo the thing by hoping to get lucky with random comments.

On the other hand, there is quite the satisfaction that comes from seeing an opponents face when you show up so well prepared -- the moment of victory is sweet :)

Um, actually you WANT the lazy jerk to contribute a good idea. For one thing, a good idea is a good idea, and the object of the game is to surface as many as possible.

More importantly, by giving the jerk copious credit, you'll do a lot to mitigate his natural tendency to derail things that may require risk and / or effort on his part. Win #2.

And of course, nothing irritates the truly motivated more than seeing a known lazy jerk score an easy victory. Chances are high that a calculated display of magnanimity from you will cause people who actually deserve credit to restore moral equilibrium by making their own (and probably better considered) contributions as well.

All that said, if you use Jefferson's approach to pre-emptivly silence a reflexive critic, yeah, it's great.

Agreed. For example, you can intentionally leave the color of the bike shed unspecified. So the other folks can launch into heated debate over something they can understand and take ownership over the final decision. Meanwhile, the overall shape and functionality of the shed gets accepted per your design, even the very necessity of the shed may be blindly accepted.

A classic play. If Jefferson were involved in product design, I suspect he would approve in full.

It can be tough being "that guy" in every dev meeting who always asks the same awkward questions: "Do we even need to do this? Are we sure? Can we get by with something smaller?"

Sometimes it's easier just to let people's pointless bikesheds through committee. I'll save my political capital for something I feel more strongly about.

I've used this approach before in meetings where I suspected I was going to meet resistance to the ideas I wanted us all to form a consensus around.

I found that this approach is successful but, as sophacles says in a different thread, it can (in theory) lead to you become somewhat blinkered to better ideas. Since I know I'm right when I go to meetings this prepared it isn't an issue, right? ;-)

However, the main problem I found with this approach is not that it leads to me to reach detailed conclusions without all the input I may need to do so. I'm fortunate that a lot of people I meet with are either smart, experienced, stubborn, or some combination of the three - the information needed to reach a sensible consensus will often emerge.

Instead, what concerns me is the sheer amount of time it takes to do this much preparation and the opportunity cost I have to pay while I'm busy trying to get an "A" on one particular meeting.

There's a lot to be said for "winging it" (or, in the recent history of memes, "doing it live"). If you're confident in your ideas and in your ability to persuade people then over-preparing is a waste of time akin to procrastination.

I can't guarantee that arriving for a meeting without elaborate handouts will always lead to a better result. But in my experience I'd rather get 80% of what I want in 3 meetings than 100% of what I want in only 1 meeting.

Disclaimer: This advice obviously doesn't apply to the once-in-a-blue-moon meeting, e.g. meeting with a potential investor or asking your boss for a raise. My context here is working for a large bureaucratic organisation where meetings are a frequent and necessary evil in order to get things done.

One thing I've learned is how much surface quality of presentation matters. As much as we might pretend to be perfectly logical rational beings, psychology, aesthetics, and emotion are always part of our decision-making process. So when I present something, I try to have great material, but I also try to make it visually appealing, clearly-written, friendly, and warm. Makes a huge difference.

A beautiful demo beats a working prototype, at least as far as management is concerned.

I've actually seen this at work, where I managed to hack together a working (but ugly) system only to experience a lot of push-back. Once I polished the output, the same idea was welcomed.

Oddly enough, I learned this lesson back in college. In one engineering design class, I got an A on an assignment that looked really cool, but didn't actually work. I didn't hide the brokenness at all: I clearly documented the fact that it produced utterly nonsensical results in my report and discussed how I would have fixed the problem.

In retrospect, I've decided that they were teaching me an important lesson, but I'm still not quite sure if it was intentional or not.

I'm running a project right now where the main stakeholder contact wanted me to call some meetings so we could brainstorm the use case scenarios, functions, etc. Thing was, she didn't want to relinquish the lead creative role for the project. So I'd be running meetings being a facilitator. The way she explained it, I felt like I would be babysitting people unnecessarily.

Me: OK, I can do that, but I'll just send a note out to everyone to brainstorm their ideas first, and then we can have items on the table to discuss.

Her: No, nobody has the same ideas or same vision, so we need to have a session first to brainstorm all the ideas.

Me: Well, I find in my experience that discussions can be much more productive if a lot of the thinking has been done beforehand. How about I'll just get everyone to think of a few items to suggest/discuss before we meet, and then our discussion will be able to really get into it?

Her: No, that's a waste of time. You'll be duplicating work. Besides, people won't know what to write beforehand. They need someone there who can help pull the ideas out of each person. Everyone already has the ideas, it just needs to be pulled out.

Me: Judging from my conversations with everyone else so far, I think this team is quite capable and intelligent. I really do believe we'll be more productive if everyone contributes some ideas beforehand so we can assemble an agenda of sorts. This won't restrict us from brainstorming new ideas either.

Her: No, they need someone there to guide their discussion and help them to articulate what it is they're thinking.

Me: That may be the case with many people, but that's really not the sense I'm getting from these folks. To be frank, I think it may even be insulting to think they need that kind of help.

Her: I'm not going to argue about this anymore. We can agree to disagree. Just organize the meetings.

Me (in my head): You're just too lazy to do your own work to figure out what you want, even though you claim to already know what you want.

End of story, there was no way getting around it. This was escalated to senior management, and while senior management agreed with my perspective, they told me to essentially take just care of her. So I scheduled the weekly meetings. The very first meeting, as I tried to lead the discussion, one of the senior customer folks involved suggested that they take away this discussion and come up with some documents and lists, and they'll come back to me when they're ready. I thanked God that competent people still existed.

You're very patient. After the second idiotic "no, it's a waste of time" I would have just said "ah ok, as you wish" and then did it how I wanted. Why bother trying to educate people who don't want to be smarter?

The HN title somewhat implies that Jefferson showed up to all the meetings this way; overly prepared. But the title of the original article states "Thomas Jefferson and preparing for meetings" which clearly does not convey that Jefferson was always like this. Furthermore in the article it is narrated one instance when Thomas Jefferson showed up prepared, which does not constitute enough evidence to support that Jefferson was this guy that wanted to be the most prepared in the room.Hence the HN title is very misleading.

Anyway, my point is not about Jefferson; my point is this: Why do people change the wording in the HN tittles (vs original ones) so that people would click on them? Can't we all be accurate when we transmit information to others?

"The HN title somewhat implies that Jefferson showed up to all the meetings this way; overly prepared. But the title of the original article states "Thomas Jefferson and preparing for meetings" which clearly does not convey that Jefferson was always like this."

Actually, the HN title does not in fact say that Jefferson prepared for all meetings like this. He clearly prepared for at least one meeting this way. And I wouldn't be surprised if this was not the only occasion where he was so prepared. But I'll grant you that perhaps using the plural of the word "meeting" instead of the singular was a tiny bit misleading.

"Furthermore in the article it is narrated one instance when Thomas Jefferson showed up prepared, which does not constitute enough evidence to support that Jefferson was this guy that wanted to be the most prepared in the room. Hence the HN title is very misleading."

Actually, the title doesn't say anything like "Jefferson was this guy that wanted to be the most prepared in the room". The article may have implied that (with good reason, I think), but not the title.

So to call the title "very misleading" because we can't know what was going on in Jefferson's mind is a bit harsh, in my (admittedly biased) opinion.

"Why do people change the wording in the HN tittles (vs original ones) so that people would click on them?"

The fact is that the stories submitted to HN have to compete with other stories. Many, many other stories. Personally, I find every story I submit to HN interesting, and think they would be found interesting by other readers on HN as well, if they'd actually take the time to read them. But if people don't click on them, they obviously won't read them, and not even know what they missed.

Usually, that means the titles have to be attractive, punchy, and interesting to grab readers' attentions, no matter how interesting the contents of the article may be. That's just a fact.

Another fact is that otherwise interesting authors sometimes suck at giving their posts or articles good titles.

Here's a case in point:

http://news.ycombinator.com/item?id=2143752

The original title was "Understanding Syntactic Macros", while my submission had the title "How Lisp macros differ from static code-generation and metaprogramming" (a title I got verbatim from the body of the article, which I felt was a better and more interesting description of what the article was about).

My submission got a lot of upvotes; and, consequently, was probably read by a lot of people. Do I think it would have gotten the same amount of attention if I'd used the original title? Not for a second. The original title might have been technically correct, but not very interesting at all.

So I do occasionally change the titles of my submissions to improve the odds of the article being read (while remaining faithful to the author's intent), or to make the title more clearly reflect what the article is about. I think of what I do as a positive service to the HN community, and am not ashamed of it in the least, since when it works and the stars are right, people will actually read the article and be pleased by what they read. Then everybody wins.

Reply on news.ycombinator.com