little rules for working life
September 22, 2013
Working in a new situation, closely with a new colleague this summer, I found myself often saying “I have a policy…” and I realized that over time I’ve create quite a few silly and some serious rules that help me navigate the day-to-day work of software development or simply working with people. These echo in my head or I say them aloud when I find myself in a specific situation. I do break these rules, but they make me think through those exceptions very carefully.
- I never take a job where I don’t know at least one team member very well. The most important indicator of success for any group is the quality of the people. VCs invest in the team, rather than the idea, since it is easier for a great team to change their idea, but impossible for a great idea to find a new team. Where you choose to work is an investment.
- Do a quick web search before you meet with or hire someone. It takes ten minutes. You should know if they are in the news or what they just blogged about. You spend your time more effectively, often develop a closer relationship more quickly, or learn that they are crazy so you can make yourself scarce.
- Sometimes, fun trumps other priorities. I try to spend some time every week doing a task which is prioritized based purely on the joy of doing it. It keeps me happy, and sometimes, there’s a part of me that understands what’s important better than my prefrontal cortex.
- Never do anything just because a VP told you to. I learned this at Macromedia where there was a new VP every year or so. I had to live with the consequences of my decisions and explain them to the new guy. It’s pretty lame to have to say, “because someone told me to.” Of course, you can’t just say “no” either. You need to understand why you are being asked to do something and make sure the right thing happens, which may be just a little different from what you are being asked to do.
- Working code is 9/10s of the law. I first heard this from my friend Eric Bloch. Sometimes it is faster to demonstrate than discuss. Sometimes spending a little time on one practical solution is better than spending the extra time to discuss options and then implement something marginally better.
- People are more important than software.
Communication
- Write stuff down. I take meeting notes and send them out afterwards. I don’t work without a contract. It’s not an issue of trust. There are a thousand small decisions about the work that go unsaid in a meeting. This applies to any collaborative work. Anytime I need to say to you “I will do this” or “I expect you to do that,” a follow-up email will solidify alignment or catch misunderstandings — saving time and forging stronger relationships.
- Think through the desired outcome, before hitting send. Sometimes just a little more information or one additional “cc” will be the difference between action and yet another email in the thread. Sometimes, this causes me to delete, rather than send.
- “Why” is more important than “what.” Know why you are building software or writing an email or having a meeting. Remember why a decision was made, not just what the decision was.
- Before giving a speech, stand at the back of the room. Just for a minute, feel what it is like in the worst seat in the house. Once I did this and overheard someone tell me what a stupid waste of time this class was going to be. I had the opportunity to find out why and then address his concerns in the class. Even if the room is empty when I do this, I feel more connected to the audience.
- Never blog more than once a day, save it for tomorrow. I’d make up a different rule if I blogged more often. Sometimes I’ll go for weeks, or even months without blogging. Then I’ll get back in the swing of it and have so much to say. I just keep drafts and release them later. I write for myself, but it’s good to think about audience also.
Celebration
- Iterate. Celebrate. Iterate. Celebrate. I wish I knew where I read this. Celebrate the little things. You can’t really control the big win. It’s the small series of little wins that we can make happen. We need to celebrate these.
- For parties, always buy a good lager, not Michelob or Bud, and something non-alcoholic too. Even though I prefer Pale Ale, there are some folk who like a lighter beer. I try remember that there are divergent tastes. Someone can still like good beer, even if they don’t like ale. And sometimes there’s that guy who really loves Michelob lite. Know your team and cater to their whims, when you can, but keep the Jack Daniels off the list for the holiday party.
Know the org chart
- Tell someone’s boss, in writing, when they do a great job, especially if they are far away in an organization.
- Always take the meeting with the big boss. Having relationships at all levels of an organization is helpful. It’s important to see the bigger picture, understand how your work fits into broader goals.
Expectations
- Don’t apologize. If I know I screwed up in a way that I know affects someone else, I should, of course, apologize. However, I used to apologize when I would send an email a week late. Then I noticed that I would get an email apologizing about lateness and I hadn’t even realized that it was overdue.
- Don’t make promises we don’t need to make. It’s sometimes important to set expectations. If I avoid habitually making promises that I don’t actually need to make, then it easier to remember the important ones.
- Never say that solving a software problem will be fast, say it is “straightforward.” Even if I think it’ll take ten seconds, it might take longer to deploy it. It might need to be scheduled later.
Time
- Plan to be early, arrive on time. A good friend once told me “to be early is to be on time, to be on time is to be late, to be late is to be fucked.” So true, though sometimes, you can make people feel awkward if you are waiting for them so don’t make it too early. You can always have a coffee nearby or take short walk around the neighborhood. Remember, there might be security or sign-in procedures. Just because you know where the building is, doesn’t mean you know where the meeting is.
- Date commitments as time ranges when possible. If I think it’ll happen on Monday, I say “early next week.” Instead of July 10th, consider “this summer.”
- Nothing happens between Thanksgiving and Jan 2. When scheduling I have date ranges that I skip over and pretend they don’t exist, unless I have specific commitments from every individual who is needed to deliver or review whatever. Every group, every culture has dates where less work gets done for good reason. We all need these down-times. Know them and simply work around them like water in a stream flows around a rock. In San Francisco, I usually black out the week of Burning Man and a few days after Pride. In the northeast at my first company, it was Rosh Hashanah.
- Never ship on a Friday. Monday is usually soon enough. Think about whether the release really merits having the team on deck over the weekend. If it does, plan for it ahead of time.
As a Manager
- The #1 job of a good manager is hiring and retaining great people. When I’m in a management role and things get crazy, as they often do, I tell this to myself every morning and twice during the day. It takes discipline to spend time writing an excellent job description or having individual meetings with staff when there are urgent, pressing, seemingly more important issues to deal with.
- Never hire until you’ve interviewed at least three great candidates. Hiring should be a tough decision. We should have to ask ourselves what is really important so we can decide between these amazing people. We should have cause to wonder if we should stretch our budget to hire more than one.
- Move fast on a great candidate. This can conflict with the previous rule, but only when I’ve failed in prioritizing recruiting. When I have a job opening, I spread the word far and wide as quickly as possible, then if I have a great candidate, I’ll already be talking to other candidates and have context for a quick decision.
- If all of your candidates look the same, you have a recruiting problem. Know the demographics of your industry and of the region where your office is. If you are only interviewing white guys or Stanford grads, you are missing some of the talent pool. Since I work in a male dominated field, I’ll sometimes tell a new recruiter, don’t send me any resumes until you have at least one women among them. With 20% women in our industry, 20% of my candidates should be women. There’s should be a few qualified, talented people of color in the mix. I can then hire the best person for the job.
- Always be recruiting. Imagine your dream team. Your people should be on their way to becoming your dream team, if they aren’t there already. Just getting to know people who you will want to work with, will make you more able to create that team. Sometimes you can’t hire them, but maybe they’ll come give a talk to your team or serve as a mentor or informal advisor. Maybe you want to work for them in your next job.
Linked from
- Sarah Allen’s Little Rules For Working Life | The Art of Ass-Kicking September 22, 2013
- little rules for working life - maiki September 22, 2013
- Five tips for managers | David Jackson October 18, 2013
- Establishing boundaries in the workplace | d1ana is a designer March 5, 2014
- How a Potluck Brunch Led to My New Job at Percolate | The Art of Ass-Kicking March 22, 2014
Comments
Dennis Furlaneto December 9, 2013
Incredibly useful advices Sarah - There are so many good things in this post that it is hard to pinpoint what is the best of them. (This post alone made me favorite your blog.)
Keep up the great job!