Meetings, Meetings, Meetings…
For those of you not in employed by a Large Corporation, let me tell you something: meetings are awesome. They let you look productive all day long while not actually doing a thing. People will look at your calendar, say, “oh wow, you’re booked solid,” and assume that you must be terribly busy. They don’t realize that you are actually just walking from room to room, introducing yourself, and then daydreaming about canoes until someone says, “well, thanks for coming.” The advent of the dial-in meeting improved meetings immeasurably; now you can pretend to be busy while sitting at your desk surfing the internet! What could be better!
The problem is, if you actually want to be productive, you may find meetings to be somewhat of a bother. As you get involved in more and more projects, more and more people will want to hear your input, to the point where giving input to other people about their projects can take up the majority of your day. As the change is gradual, it’s so easy to not notice it until…
Well, until you get to the end of a workday and realize that you’ve been talking to people all day long and still haven’t gotten anything done. Ouch.
pri·or·i·ty: A thing that is regarded as more important than another - Oxford Online Dictionary
It’s up to you to define what which “things” are most important. If other people are asking for your input, you’re the only one who can gauge whether that should come before other tasks on your plate. Sometimes this requires the skill of saying “no”. Sometimes this requires lots of artful juggling. It’s so easy, though, to just say, “sure, I’ll help”, without considering your own needs.
Stephen Covey, in his book “Seven Habits of Highly Effective People”, popularized the following time management tool:
Long story short, you want to be in quadrant 2 as much as possible. If you’re ever in either quadrant 3 or 4, time to rethink priorities.
Experience > Tenure
"Hi, Dan, welcome to Acme Widgets. I’m Bob Kishintuchus, and I’ll be interviewing you today. So, one of the things we look for in all our analysts is a strong familiarity with Excel. Are you familiar with Excel at all?"
"Oh, sure, I’ve been using it for over fifteen years by now."
"Really? Great. So, tell me, how experienced are you with (some very basic function)?"
"Hm, I haven’t used that bit so much."
"Oh? OK, how about (another basic function)?"
"Well, not so much. I mainly use it to send around reports."
The above conversation has occurred so many times during interviews I’ve become more surprised when people actually know how to use whatever tool it is I’m asking about. Please take the following to heart: stating that you’re familiar with something simply because it’s been a part of your life for a “long” time is not the same as actually knowing how to use it. There’s a really simple litmus test here: if your first response to “how familiar are you with (topic)?” is “I’ve been using it for (random number) years”, you’re doing it wrong.
When I’m asking you about a topic, it’s because I’m looking for someone who can jump right in without training on how to use the tool. I know before we start talking that any potential hire will take a few months to learn the business, I don’t want to lose more time to you learning a new tool as well. I need you to tell me specific examples of how you used this tool to do awesome things. I don’t need you to tell me that you’ve sat in front of it for the past two (five, ten, twenty, etc) years and never took the time to actually make it sing. If you haven’t shown initiative before, I don’t think you’re going to suddenly start now, and I probably don’t want to hire you.
Management Tip of the Day: How to Call Someone Over To Your Desk
Don’t do this:
"Hey Bob, can you drop by my desk for a second?"
Instead, do this:
"Hey Bob, can you drop by my desk for a second? Quick question about the framistan project."
You’re a manager. If you’re calling someone and provide no context, they’ll feel this momentary pang of “oh poop I’m getting called to the principal’s office”. Even if you think they won’t, why risk it? A little bit extra communication is almost always a good thing.
On The Value of Naive Inquisitiveness
Few experiences are as panic-inducing to a geek as viewing an error message during reboot right after trying to “fix” the computer.
As a child, I once got in my head that I needed to organize the files on my dad’s Mac. In my mind, “organize” meant make sure that all the files were aligned to a grid, nice and square. This would have been a pretty achievable and low-risk goal, except for one pesky uncooperative folder. For some reason, this one folder had some two files that, no matter what I tried, wouldn’t align to a grid. Naturally, I tried deleting them (the obvious first approach to solve this problem), but they always came back, unaligned, taunting me. After a few weeks of this, I found a utility which claimed it could delete anything. I tried it and, sure enough, it really deleted them. Folder organized! Mission accomplished!
Except that when I rebooted the computer it wouldn’t even turn on. Turns out that my dad had the entire hard drive encrypted by Nortons SomethingOrOther, and I had found my way to the system folder and deleted the two files necessary to decrypt the computer. Whoops.
My dad was pretty torqued about this, naturally. I was banned from using a computer ever again. In a moment of clarity (the likes of which I never experienced again, unfortunately), I put forth the following argument: If he wanted to ban me, he should have done it earlier. Now that I’ve screwed up, though, I know what I did wrong, and I won’t do it again.
He thought about it, agreed, and reversed the ban.
That happened over 20 years ago, and the experience resonated with me pretty powerfully. You can’t be afraid of the computer. Try things, and even (sometimes) break things, but be willing to poke around and see what you can do. I’ve learned that you have to respect the machine, the same way you respect anyone; if you don’t know what you’re doing and the machine tells you not to do something (e.g., deleting a crucial file); don’t do it until you’ve researched enough to understand what you’re doing and know the consequences. Sure, you’ll break things occcasionally, but you’ll learn to make those experiences less painful (backups!) and you’ll fix them, and you’ll learn things along the way.
It’s a general life lesson, which applies equally to this situation: if you replace “fear of unknown” with “respect for unknown”, you’ll learn things you never thought possible.
The Inestimable Value of the Posthoc Review
Few events provide the raw satisfaction and relief as the completion of a large project. You’ve been working on something for months, keeping track of dozens of details, monitoring timelines, considering all the possible ways that things can go wrong, and now it’s all finished. Sure, there’s going to be bugs that crop up after the fact. Undoubtably, there will be questions, training, support, feature requests, refactoring, and all the other stuff that goes on with supporting released software and development of the inevitable 1.0.1 bugfix release. Even so, there’s still a wonderful feeling of satisfaction that comes with the sending of the “we’re live!” email.
Right after release, the most important task is to celebrate. Working on any project that will eventually be released to the public is often be highly stressful, and an environment that doesn’t celebrate it’s successes is a sad one indeed.1 However, when the party’s over, your next most important job is to perform an informal post-hoc review. Depending on the complexity of the task and the number of people involved, this can take anywhere from a half-hour to a few days. No matter what, though, you should perform this review… the yield from this nigh-negligible time commitment is immeasurable. Some of the benefits we’ve seen in our group:
- Clear the air: Long group projects bring out both the best and the worst in everyone. By providing an outlet for criticism—both good and bad—you help keep everyone sane and, hopefully, in good spirits. In our experience, we had lots of comments (positive and negative), and the atmosphere of “we’re here to make sure we do an even better job next time” helped avoid anyone taking anything personally.
- Improve trust: People generally want to do a good job. The posthoc will result in clear opportunities for improvement for everyone, which when executed upon will help build a more cohesive, trusting team. (Do note, though, that by doing a posthoc you are committing to executing on the feedback. If you don’t, you will not only lose all credibility, but you’ll be acting kinda like a jerk. Don’t be that guy.)
- Know thyself: I love Donald Rumsfeld’s “unknown unknowns” quote, and this helps me take it to heart. Discussing the groups (and my own) strengths and weaknesses helps us improve as a team and as individuals.
During one posthoc performed by our group after the recent completion of a project, the discussion was so beneficial that it not only recharged everyone on the team, but led to us tackling the next projects with a renewed energy, knowing that we’re getting better each time.
Our posthoc had only one rule: comments must be directed at tasks/processes, not people. Even failures on a one-man task may have been due to poor task assignment or lack of support from group rather than individual shortcomings. The posthoc is the place for group discussion on group efforts, not group discussion on individual performance.2 When the discussion is over, the group should know where the group succeeded and where the group failed.
The actual execution of the posthoc was straightforward:
Before the discussion, we compiled a list of aspects of the project we wanted to review. For us, this included the following:
- Technology: Did we use the right tech? Did we take advantage of it correctly?
- Project Management: Were everyone’s roles clear? Was there confusion on tasks? Were deadlines realistic?
- Communication: Were the right people informed at the right times? Did everyone in the group know what they needed to know? Did you communicate well with customers?
You probably want to make your own list of relevant items.
- In the meeting, we would go through each of the areas we had thought of in step 1 and ask people to think of things that went well and things that didn’t. We would sit quietly and think for a few minutes, writing our ideas on yellow sticky notes, which we would then post on the wall. Having a few minutes dedicated to reflective thinking is pretty nice and helped get everyone involved; even the quiet folks who don’t talk much during meetings aren’t averse to writing things on notepads.
- When time was up, we’d discuss each item the “went well” bucket, do the same for the “didn’t go well” bucket, and then move on to the next topic. Note-taking is encouraged by everyone.
In our group, the whole process took about one hour, and it soon became apparent that everyone was learning something during the exercise. While working on a project, you’re often far too deep in the weeds to step back and notice the most obvious problems. The posthoc exercise lets all those little “issues” come to light.
The best part is that, unless you were planning on closing the company immediately after release, you can immediately take the lessons learned and apply them to the next project, or even towards ongoing work on your newly released project. The payoff is immense, and the effort required is so small—one discussion—as to be negligible. I’ve been in the work environment for a few years now, and this one post-hoc discussion has been by far the most informative and fruitful discussion I’ve had since I began my professional career. I can’t recommend this practice enough!
My postdoc advisor, Nathan Urban, would pop a champagne bottle whenever someone in the lab published a journal article. Not only did everyone get a celebratory drink, but the cork would always shoot up and make a nice dent in the ceiling tile. A few years of this practice had generated quite an attractive mural of celebratory ceiling damage. ↩
As a manager, one approach to individuals critiquing each other is to ask the group members to email you directly with any comments on each of their teammates (again, after the project is completed). You can then group these together and deliver them to the individual, anonymously, during a private session. The drawback is that this requires significant trust from the teammates, which the manager may not have yet developed. ↩
The Microsoft Tool For The Job
Many technophiles have a special disdain for Microsoft. I’ve been using Microsoft “stuff” for over two decades, but only within the past two months have I been able to articulate the underlying reason behind that disdain, and I can now state it in a single sentence:
The vast majority of Microsoft tools intentionally avoid the title of “Best Tool For The Job”, instead favoring the title of “Easiest Tool For The Job”.
This is most evident in an ingeniously infuriating tool named Microsoft SharePoint. Sharepoint allows anyone to create a website using pre-built templates. You can make documents repositories, wikis, lists of… whatever you happen to want to list, issue trackers, even just a departmental homepage. The problem is that the quality of these sites are all exactly the same: very mediocre. They don’t outright suck, as measured by the fact that they all accomplish their stated purpose. The wiki acts as a wiki. A fairly difficult-to-use, ugly, and slow one, but a wiki nonetheless. The issue tracker lets you track issues, provided you don’t mind the lack of standard issue tracking features and the abysmal user interface.
These things are all fine so long as you’ve never used a good implementation of whatever functionality SharePoint is trying to replicate. Consider the issue tracker having used a number of actual issue trackers, ranging from Bugzilla to Trac to Github Issues, SharePoint sucks. Without even bothering to list the deficiencies—that would be a long, boring post all by itself—it’s perfectly clear that this is truly the poor man’s Issue Tracker.
To pick on a different Microsoft tool, this mentality of “Easiest > Best” is even more apparent with Microsoft Access. No matter what task you’re performing, creating a database in Microsoft Access is the wrong way to do it. There are countless other alternatives that are more capable, powerful, robust, and significantly faster. Again, Microsoft Access is definitely not the Best tool, it’s the Easiest.
For power users, this is death by a thousand paper cuts. Seeing people regularly deciding to use inferior tools just because “well, we know how to use them better than we know how to use anything else, so meh, it’s good enough” is painful to watch. “A little training, a little education,” we think to ourselves, “would make these people so much more efficient.” Unfortunately, with such an easy crutch to lean on, most users of Microsofts software never even realize the crutch is there, despite the fact that it slows them down every step of the way.
That is the source of my disdain. Microsoft, creator of the invisible crutch.
The Wish List
You’re looking for a job. In reading through the job listings, you notice that many seemingly entry-level corporate positions have these oddly extensive and specific requirements, such as “three to five years work experience” coupled with “two years experience in the <whatever> industry” and “knowledge of XPR, EGS, CPP, and MMCS methodologies” or something similar. You click away in exasperation and wonder to yourself, who do they think they’ll find with a posting like that? What kind of entry level person has that type of knowledge and experience?
You’re missing something very fundamental here: the vast majority of low- to mid-level corporate job postings are actually just wish lists. Some manager in some corner of a large organization realized that they need more people to do whatever specific job it is that he manages, and wrote a posting for that task. Do you know how to do that task? Of course not. Very few people do. This is even more true regarding familiarity with software packages; the majority of software packages used by large corporations are highly specialized, used by a very small group of people in a very specific industry.
So, our manager has a problem: the talent he is looking for doesn’t exist. How can he solve this problem? Oftentimes, he’ll take one of two possible approaches:
- The manager will craft a very detailed and specific job listing, carefully outlining what the perfect candidate would look like, in the hope that people who apply will have some, if not all, of the posted requirements.
- The manager will slap together a very generic job listing—sometimes provided to him in template form by HR—detailing the typical skills possessed by people in the positions similar to the one being posted, and hope that the candidate can be trained.
These differing approaches reflect two different approaches to hiring.1 In both cases, though, they’re unlikely to find the “perfect person” for the job, and they’ll have to train later on. With that in mind, even if you come across some bizarre job description that appears to describe a mythical creature that doesn’t exist, don’t be deterred from applying to a position that sounds promising.
The first is an attempt to weed out via the job posting, hoping to only receive applications from candidates with the necessary skills. The second relies more heavily on the phone screen and interview process to identify talent, with the downside that many more resumes will be received, and more time will have to be dedicated to the hiring process. ↩
Some interesting wordplays I thought up while on the bus recently.
The wording of red-light district legislation:
sin tax syntax
An end-user license form allowing others to use your unique chemical:
formula form ULA (or formula ULA form)
Making disparaging comments about a poor report card:
degrade D grade
Competition for the best criminal psychological test:
con test contest
What neural growth hormones attempt to do:
attract a tract
Warehouse that contains information on length of business lifecycles:
store age storage
Two musicians riding on the back of a male cow:
ensemble on some bull
When a new army conscript uses a racial slur:
ensign “n” sin
Two years of blogging
To improve a skill requires practice, practice, and more practice. Two years ago as of this past June, I decided to work on improving my writing, and I started this blog. I wanted to share some thoughts on how this exercise is going so far.
Writing takes a lot of time. I definitely did not appreciate how long it takes to write before I started. Most of my posts take between an hour and a half and three hours of often disjoined writing until I have something that is half-decent. I’ve learned the value of outlining, writing, reading, re-doing the outline, write some more, etc. None of my posts have come out well on the first draft; every single one has had at least three revisions of each paragraph.
You don’t know what you like until you try it. I spend a lot of (read: way too much) time on Hacker News. At the outset, I wanted my audience to be the Hacker News audience. I’ve been successful, to a small extent, in that a good number of my posts have made it to the Hacker News front page. As I developed my writing, though, my writing started to focus more on different topics, that interest a different audience. I’m still trying to really determine the types of topics I enjoy writing about; I suspect this is a common theme among novice writers, the long search for the topics they feel most comfortable writing about.
I think about writing a lot more now. As I go through the various experiences of my day, I find myself thinking “that would make a good blog post” very often. As a result…
My thinking has evolved. Previously, I would do my best to understand “things” for myself; reading the news, learning a new trick, going through some funny/sad experience at work/home/life in general would be an effort in trying to understand what’s going on for myself. Now, I find that I’m asking myself, “how would I explain this concept or argue this point to a larger audience?” This approach of explaining ideas from a different angle has helped me thinkg through concepts and arguments more deeply, and get a better understanding of when I really understand something.
So far, it’s been fun. Here’s hoping I can keep this up for a few more years!
I’ve recently started doing something I haven’t done for a long time: read books. The two that I’ve recently finished are Good Boss, Bad Boss and Contagious, and I’m currently working through A Random Walk down Wall Street and The No A****** Rule. While reading, I’ve noticed a clear pattern in the writing style: all of these books are written like storybooks. The chapters comprise of one short story after another, each one between a paragraph and a page and a half long, often making the same point over and over and over again. The next section will be the same: a basic idea, and then dozens of stories illustrating the point over and over again.
This works. People don’t remember endless streams of facts, they remember stories. More pointedly, they remember stories that they find interesting and/or relevant. This is why all good public speakers know to make liberal use of stories, jokes, and anecdotes when talking; the audience enjoys it more, and will remember it better than a simple recitation of facts. A good friend of mine who frequently gives talks as a motivational speaker told me that a good speech “begins with a joke, continues into a story, and then ends with a joke.” What about content, I asked? Make your jokes and stories convey your content, he said. People want to be entertained, not lectured. Entertain them, and you’ll convey your message much more powerfully.