PowerPoint presentations get a bad reputation. That’s because most of them are terrible—they’re boring, they’re too long, and they’re full of tiny text and awkward animations.
On the other end of the spectrum, there are the highly-produced Keynotes from Apple that have been agonized over by legions of designers to sell you the company’s latest products. These decks are so intricate that they seem impossible for mere mortals to put together.
When my longtime friend and collaborator Brian Capps and I worked as iOS engineers at The New York Times, we noticed something concerning. There were a lot of intractable technical problems in the organization that seemed unsolvable due to politics and inter-team communication roadblocks. Everything from bug reports, to performance issues, to new features that needed newsroom buy-in got backed up this way.
So, as people who cared deeply about the quality of the products we were building, we searched for any way to get product people, designers, and business folks all on the same page about what we wanted to fix in the iOS app. The best tool we found (after trying many) was the humble slide deck.
Here’s what we did when we really wanted something to get fixed:
Brian and I would book a conference room together in the middle of the day, write an outline of what we wanted, and then develop a well-designed and straightforward slide presentation to make our argument. (By the way, we never told our bosses we were doing any of this.) We’d rehearse our spiel and then, we’d presell the idea by showing the deck to just a few people we knew would be critical decision-makers and solicit feedback, editing the deck as we heard their objections. Finally, we’d book a meeting with everyone in the organization who would need to be on board if we were going to make the change.
For example, once, we wanted to make sure that the NYTimes iOS app rendered all advertisements at the proper resolution on the new iPhone 4. We knew we’d need to convince a designer, the head of sales, an ad trafficker, a product manager, and our engineering manager. So we invited all of those folks to a meeting, dimmed the lights, and pitched our hearts out. For the first time, everyone in that room saw the blurry non-Retina ads for what they were—ugly and unbecoming of The Times. Everyone came out of that meeting jazzed to solve the problem, and together, we did!
This technique worked so well that we used it repeatedly, improving the app along the way. Our little slideshow sideshow became so familiar that it earned us a nickname: “the twins”. In fairness, we did have a bit of a Ringling Brothers vibe going on at the time.
Presentations are perfect for persuasion. Solid slides make information digestible; they show that you’ve thought deeply about the problem. And putting effort into them shows that you’re serious and that you care. Anyone can write an email, post a Slack message, or toss a meeting on the books. But few people will take the time to prepare a thoughtful, well-reasoned, and persuasive deck.
The next time you want to convince your coworkers, despite their differing priorities, to commit to working on something you care about: open your slideshow app of choice and make your argument in big type, one slide at a time. I bet your slides will change more minds than you expect.
There is no gate keeping, no screening, just a calendar form. I just show up to whatever appointments folks booked on my calendar with hopefully a little context of what they’d like to discuss. I don’t think I’m some industry pundit, but I do recognize that anyone who has been doing roughly the same thing for 10 years might be able to provide advice for someone earlier on in their career. Also, it just feels like the right thing to do to try to give back to folks in this very small way.
My pal and former Tumblr coworker Brian Michel is opening up his office hours to the public and wrote a great post about why experienced technologists should be open to new connections and offering support, as well as some instructions on how to set it up.
Your job as a founder or CEO is to run your company and make your customers happy, not to do every little thing by yourself. Work with the pros who will save you time and make you money. Hire a lawyer, hire an accountant, and (if you’ve got room in the budget) get some help with your operations. Trust me, you’ll be glad you did.
Over on the Lickability blog, I wrote about my company’s history of working with outside professionals and have some advice to business owners about what to look for when hiring lawyers and accountants.
Last March, I gave a 7-minute speech at a reading series that scratched my persistent itch to be in front of a crowd. But in 2019 I want to get back into my usual schtick of giving longer, prepared presentations with slides. I love attending conferences, and I especially enjoy having the opportunity to hone a talk and share it with a group of my peers.
Later this month, I’ll be heading north to speak at (the appropriately named) NSNorth 2019. NSNorth is Canada’s premier independent Apple developer and designer conference, and like Çingleton in years past, it’s taking place in beautiful Montréal, Québec. I’ve never been to this conference before, but I’ve met the organizers at other events, and I’ve heard great things.
My talk is called Growing Pains and it’s about the things that break as your software team or company gets bigger and what you can do to make that a less painful process. If you’d like to hear more about the conference and my experience on the topic, Dan and Phil interviewed me on the NSNorth Podcast. Give it a listen below or wherever you get your podcasts:
Finally, the organizers have announced that this is the last year for NSNorth for the foreseeable future, so if you’ve always wanted to attend, now’s your chance. If you need help convincing your boss to cover the cost, they’ve got you covered. Tickets are on sale until this Friday, April 12, so act fast.Je vais te voir là-bas! 👋
It’s Julie’s last day at work. She’s already turned in her laptop to IT, sent her goodbye email to the team, and is wrapping up her last knowledge transfer meeting. Tonight, there’s a goodbye drinks with the whole engineering department at that bar everyone loves across the street from the office. You’ve followed all the processes as a manager to offboard this person correctly, and wished them good luck at their shiny new job with more stock options and a higher salary you just couldn’t match. “Good for her,” you think, as the night winds down over a final round of cocktails. But wait – you’re not done yet.
When you’re a manager, the way you treat the people that were on your team matters almost as much as how you treat the people that are. Your ex-employees are the people out there talking the most about your company and your team. They’re the people that get DMed when a new recruit is trying to find out what it was really like to work for your company and for you. And handled really well, ex-employees are often great folks for you to tap in a few years for the new team or company you’re working on, when they’re ready for a new challenge.
How should you treat the people you used to work with, so you won’t leave a bad taste in their mouth? Here are a few do’s and don’ts I’ve picked up from my own ex-managers over the last decade or so. Disclaimer: this advice won’t apply to every situation, including if an employee left or was pushed out on bad terms.
What to Do
Let them leave with dignity.A CTO I really respect taught me that letting people take the time they need to say their goodbyes and tie up loose ends, without rushing them out the door, pays dividends. He gave me the great advice to spend my last day on the job having coffee with everyone that had an impact on me, thanking them, and exchanging contact info.
Remember that it can be emotional to process endings, even if it was their choice, and last days can be full of paperwork and tears. It’s okay if they need to come back the next week and pick up a few more things, or need building access for a final meeting after their technical last day. Don’t be a jerk or make mean-spirited jokes about how much they must want to stay. Not cool. You want their last memory of this place to be a positive one: handshakes, hugs, and well-wishes.
Keep in touch (if they want to). Some of your reports or teammates probably view you as one of their mentors, and it can be hard to abruptly lose that guidance when they switch jobs. In your last 1:1, ask the person departing if they want to stay in touch after they get settled in their new role. If they do, set up a recurring reminder to check in with them every few months or a few times a year on their career over coffee or lunch. If they blow you off or don’t seem interested, take the hint.
Let them hang around. It’s natural for folks to miss some of their coworkers, the office, and aspects of the culture when they quit. So if you see them coming by for lunch or after work to hang out with some pals, say hello and be cordial. Obviously, also be aware of the security / guest policies of your company and make sure those are being followed. The benefits of knowledge-sharing (of things they’ve learned in their new role) with your team far outweighs the risk that they’re going to “steal all your people” or whatever other irrational fear your lizard brain has cooked up. Chill out; it’s nice to see their face again.
Take their feedback seriously. They likely understand and care about your product a lot. So it might not be long before you see a tweet or email from an ex-employee about the thing they used to work on. They might be reporting a bug or airing a grievance. While it might not be the most polite way for them to give this feedback, it’s still useful. This person is essentially doing free QA on a system they’re very knowledgeable about. If you see something like this, shoot them a message asking for more details and thanking them for the report. Stay classy and fix the issue if you can! You’ll make them feel heard and respected while helping them and lots of other users too. Win-win.
What Not to Do
Don’t blame them. A few weeks after an engineer leaves a team, there will be a bug that someone will blame on them—their code, their oversight, their fault. Resist this temptation. Your team has code review, unit tests, and architecture meetings to prevent this type of singling out of developers. Remind them that every issue is a shared responsibility, and focus on fixing the problem instead of dredging up historical evidence of whose fault it was. Don’t let folks blindly rewrite systems just because “only Jim understood how this worked.” Work to build a shared knowledge base and set of documentation so that no one person is completely indispensable.
Don’t make them work for free. There’s often a temptation to message ex-employees with “quick questions” about esoteric code or systems that they worked on after they leave the company. Please don’t do this. If you absolutely need these answers, hire this person at their consulting rate and pay them for their time and labor. This kind of arrangement is super common, and your company should hopefully already have a boilerplate agreement for this scenario. If not, now’s the time to draft one.
Don’t erase them from history. This isn’t Eternal Sunshine of the Spotless GitHub. It’s unprofessional and petty to remove folks as contributors to your open source projects (especially if they want to contribute in their spare time) or scrub their bylines from your engineering blog. I’ve even heard of bosses ignoring their former employees at conferences and industry events or blocking them on social media. This is a really bad look. Don’t be a jerk to people who worked for you.
Don’t ask them on a date. I wish this went without saying, but it doesn’t, because I’ve heard of this happening. If you had a crush on your employee and the only reason you weren’t asking them on a date is because of the HR policies in place to prevent that, now is not the time to flirt with them. The power imbalance that existed between you doesn’t magically disappear because they work somewhere else. This is a really bad idea, and you should do some soul-searching and work on your boundaries if this is your first impulse.
Many managers think a lot about how they treat their team, but very few I’ve spoken to have a philosophy about those who leave it. Treat your ex-employees like they’re professionals that helped you build and ship great things, because that’s exactly who they are. If you’re consistently nice and professional to the folks you’ve worked with in the past, it’ll help build your reputation as the kind of person that’s great to work for.
A talk I gave last year at the CocoaLove conference in Philadelphia about why you might want to step away from the keyboard and into leadership, and what happens when you do. It’s about the difference between managing programs and managing people.
Inside The New York Times Building next week, it’s going to get harder to do your job. Clifford Levy, a Pulitzer prize winning journalist, and former coworker tweeted that the way to get this company thinking mobile first, is to block the website. Wait, what?
Just like Cliff and the others, I believe very strongly that if The Times is to survive, it needs to think about its apps and mobile website a hell of a lot more than www.nytimes.com, or “triple dub” as it’s known inside the company. But is blocking the site for its own employees really the right way to do that?
It feels like a punishment. Your dad is turning off the TV and making you eat your vegetables. This kind of paternalistic attitude is not what will spur the brilliant engineers and journalists at the Times to improve their pocket-sized offerings and consider the report from a mobile angle.
So what’s a better way to get a company as large and old as The New York Times to care more deeply about its report on phones, tablets, and watches? There’s no magic bullet, but in my years there I saw incredible ideas, people, and talent wasted on a website with declining traffic while the iOS app suffered a lack of attention from the newsroom. I saw initiative after initiative to make mobile more important flounder while many of the reporters still aimed to be on the front page of a gray piece of paper.
It may be that the way to make sure that employees of the Times care more about mobile is to point out when these failures happen, to be critical of the web first mindset, and to remind people every time they try to perfect a web layout, that they’re doing so for a rapidly declining number of readers. Along with that, the Grey Lady should be celebrating the teams and people who are getting this right, without putting people who still rely on the website in time out.
The newsroom brass at the Times are trying to solve a social problem with a technical solution and I can’t imagine anyone there that’s too happy about it. It feels robotic, oppressive, and downright annoying. Honest conversation and critique of the attitudes and norms of a century old organization will almost certainly be received better than playing with the valve of information flow inside the Times. I hope they reconsider.