mb

A photo of mb bischoff in a red lip and leather jacket.

mb bischoff (she/they) makes  apps,  posts, &  podcasts changes

rss subscribe mb

The Allusionist: Enjoy 

Last night, I listened to this episode of the podcast The Allusionist from October. As a keen observer of language, the host Helen Zaltzam is often bothered by the cliches of foodservice phrases like “Enjoy!” or “Are you still working on that?”. What follows is a fascinating discussion with restaurant professionals about the origin, meanings, and functional purposes of these and other similar expressions. I’d highly recommend giving it a listen.

#language #podcast

A New Look for The Atlantic 

The Atlantic app

It is the most dramatic new look for our magazine in its 162-year history, and one that, we hope, reflects boldness, elegance, and urgency. The redesign of the print magazine, as well as the new look of our website, was led by Peter Mendelsund, our creative director. His design work, carried out in collaboration with many teams across our magazine, is also reflected in the new Atlantic app that launched today.

Really excited about this bold new look for one of my favorite publications, and honored to have gotten to work on the development of the app at Lickability.

#app #atlantic #news

At the Times, a Hesitance to Hyperlink 

The next day, he said, “We are looking at a way to link. Noting Motherboard explicitly—and I understand why [sic] would want this—is more complicated, however. Are we then obliged to note that The Guardian had some of the documents, too? If half a dozen other publications got a piece of the Facebook material, as well—for ‘internal’ documents, they do seem to get around—would we need note them, too? Where does it end?” The Times never added a link.

Thinking about a journalist in the NYT newsroom in not being able to figure out how to make a hyperlink cracks me up and I’m not the only one.

#hyperlinks #internet #journalism #nytimes

NSNorth

NSNorth Pormotional Image

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:

NSNorth #57: Matthew Bischoff

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!

#canada #conferences #nsnorth #speaking

How to Treat Ex-Employees

Fire Pit from XOXO

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.

#firing #hiring #management #work

Write Your Way Out

mb speaking at Release Notes 2016
Photo courtesy of Ben McCarthy

In September 2016, I was honored to be invited to speak at Joe and Charles’s incredible Release Notes conference in Indianapolis. Release Notes, an outgrowth of their podcast of the same name, approaches the software business as a business first and foremost. Their guiding principle is to discuss “everything but the code”.

Here’s the audio and slides from my talk. It’s called Write Your Way Out (yes, it’s a Hamilton reference). I spoke about writing and the importance of writing well as a software engineer, a product manager, and especially the owner of a software company. Watch it below and let me know what you think on Twitter.


The dates for Release 2019 in sunny Playa Mujeres, Mexico have just been announced (Oct 3—5). If you’re in the software business, I can’t recommend it more strongly. Get on the mailing list so you don’t miss tickets!

#release notes #talks #tech #writing