Things I Learned About Software From Things Tina Fey Learned About Producing From Lorne Michaels
Part 2: Nerds thru Crazy People
Posted by Charlie Recksieck
on 2021-11-18
* * *
As we said last week, there’s a fantastic New Yorker article called "Lessons I Learned From Late Night." with legit managerial advice, as well as being funny. (We strongly encourage you reading the original piece!)
Meanwhile, here in our blog we’ve adapted these principles to be relevant to software development. As a refresher here’s the full numbered list of things Tina Fey learned from Lorne Michaels ...
1) Producing is about discouraging creativity.
2) Figure out if there is something you're asking the actor to do that's making him or her uncomfortable.
3) The show doesn't go on because it's ready; it goes on because it's 11:30.
4) When hiring, mix Harvard Nerds with Chicago Improvisers and stir.
5) Television is a visual medium.
6) Don't make any big decisions right after the season ends.
7) Never cut to a closed door.
8) Don't hire anyone you wouldn't want to run into in the hallway at three in the morning.
9) Never tell a crazy person he's crazy.
4 - When hiring, mix Harvard Nerds with Chicago Improvisers and stir.
In software, this hiring tension would be more like having a staff which is a blend of computer science majors and programmers who are completely self-taught.
Personally, I feel like I can usually count on the self-taught folks a little more. Everybody on your staff is going to have to start over and learn new software languages, platforms and architecture in 3 to 5 years. I trust the self-taught to do this with fewer problems.
That said, well educated programmers first of all were smart enough to get into those good colleges in the first place. And they've been exposed to ideas and architecture beyond whatever their boss has assigned to them.
5 - Television is a visual medium.
Tina Fey's section on this isn't what you'd probably image - and funny. Take a look.
But in this context, I'm going to say that most software designers don't think about how intuitive their design needs to be. When you're programming, you're doing builds and tests of the program constantly. If you're working on app dashboard, you may have been working on it for 120 straight days for 6 to 10 hours a day. Unfortunately, you've become the world's greatest expert on this software.
The new user has just come to see this dashboard for the first time. If it's not clear how to get to settings, press play, change volume, upload files, etc. then there will be complaints.
6 - Don't make any big decisions right after the season ends.
The homestretch of releasing a product is grueling. It's also a rush, just not quite the rush of "We just did live comedy for 90 minutes to a nationally televised audience", but it's a rush.
At the end of the project, there are some pain points that are fresh in your mind. Your team may have lost a week because Jerry goofed on checking files back into version control, Linda may have violated the strict naming convention for supporting files all over the code, etc.
If your project was rolled out on the 1st, don't start making big personnel decisions or policy changes on the 3rd.
We strongly encourage having "post mortem" conferences a week after rollout. First of all, waiting a week let's emotions cool down, and lets everybody get caught up on sleep. Right here at Plannedscape, we're having a big post-project meeting tomorrow. And everybody is encouraged to speak up. You might have to be a taskmaster adhering to chain of command during the big push, but in this more relaxed post-project state it's a great time to get input from everybody - so they feel heard, and it's now time to hear "On the next project, what if ..."
7 - Never cut to a closed door.
In the original New Yorker article we're referring to here, it's basically about doing things in a way where the audience feels like they're in good hands.
Likewise, in software development - don't give users an opportunity to think you don't know what you're doing.
Always give error messages. Try to give as many ways for users to give feedback. Use professional graphic design (programmers just might be the worst graphic designers I've ever seen, and I include myself in that group of bad graphic designers).
8 - Don't hire anyone you wouldn't want to run into in the hallway at three in the morning.
To those who haven't been on the hiring side of business very much, here's some news for you. Many interviews and most final interviews have little to nothing to do with your ability to do the job. If you've gotten that far, the hiring managers probably already believe you can do the job and you're among the final few potential hirees.
Just as in baseball where "the tie goes to the runner", in my evaluation of a few different people who could do the job, the clincher questions are: "Could you be stuck in an airport with this person?", "Would you mind eating lunch with this person two times a week?" and "Would you saw your arm off to get out of broken elevator with this person?"
9 - Never tell a crazy person he's crazy.
In a work context, somebody on your team might do things in a way that you would never do in a million years. Unless their way is objectively idiotic or counterproductive, then maybe hold your tongue and hear them out. People doing things differently is also kind of the value of true diversity.
Secondly if they are doing things that are counterproductive to the overall mission, then you do owe it to tell them. Not "You are crazy" but some gentle version of "That is a crazy idea." If you find you can't tell an employee how to do better because it won't help ... then you've got a real problem. If you're humoring a worker to cover for them, you're not doing them any favors.
Now when it comes to just being annoyed by people on your team, as Tina Fey says in this section of her article, "There is not one management course in the world that recommends self-righteousness as a tool." If you just want to tell somebody off to make you feel better, hold your tongue; just wait til you get home and bitch about it to your spouse like a normal person.
