Skip level meetings: What they are, and exactly how to run them

If you manage other managers, holding skip level one-on-one meetings with their direct reports is paramount. Here’s how to do ’em.

If you’re a manager of managers, skip level meetings are your lifeline. I don’t mean to sound bombastic, but if you’re a CEO, executive, or director who manages other managers – then skip level meetings are an essential way to keep your ears on the ground.

Skip… what? If you’re anything like me, when I first heard the term “skip level meeting,” I was befuddled. Yes, I held one-on-one meetings with my team. But as the team grew and I had a manager who had someone else reporting to them… I wasn’t talking to their direct report with any regularity. How was I supposed to ever learn what that team members was thinking and feeling about the company if I never talked with them?

Keep reading “Skip level meetings: What they are, and exactly how to run them”

Basecamp no longer requires Google for two-factor authentication

When it became clear to us last year that using SMS for two-factor authentication (2FA) was insecure, we kinda panicked. We’d spent a lot of time originally building that SMS-based 2FA login system for Basecamp, and the prospect of having to build an entirely new system compatible with proper authentication apps seemed daunting. Especially with major security liability hanging over our head.

So we went the easy route, and handed the 2FA authentication flow over to Google, using their Google Sign-In APIs. Now, that certainly gave us an immediate and secure solution. Nobody is disputing that Google knows security.

But requiring people to have a Google account to get a 2FA-protected Basecamp was an uncomfortable compromise. There are about a million good reasons for why you wouldn’t want Google to know everything about when you log into apps all over the internet. Google’s business is literally based on collecting as much data as possible, so it can use it all against you for ad targeting. That’s just not a regime we feel comfortable encouraging, let alone requiring.

So I’m thrilled to announce that we got our shit together and built our own, wonderful, and secure 2FA login protection for Basecamp. Google Sign-In still works, but it’s deprecated, and we’ll no longer be recommending it going forward.

Our new secure 2FA solution is built on the TOTP standard with backup codes as a fallback. So you can use any TOTP compatible authentication app, like Authy, 1Password, or Duo, and it works for all versions of Basecamp (here’s how to set it up in Basecamp 3 and Basecamp 2), as well as our legacy apps Highrise, Backpack, and Campfire.

Big kudos to Rosa Gutiérrez from our Security, Infrastructure & Performance team for putting our fears about doing our own TOTP-based 2FA system to shame. She led the project, did the work, and the final result is just great.

Finally, it feels good to have one additional area of the business free from Big Tech entanglement. We also dumped Google Analytics a few months back from Basecamp.com (relying on Clicky.com instead), and we’ll continue the work to untangle ourselves from Google and the rest of the industry behemoths. It’s a long slog, it’s unlikely ever to be fully complete, but every little bit helps.

Oh, and please, if you haven’t already, turn on 2FA to protect your Basecamp account. And if you aren’t already, use a password manager, like 1password. If you’re reusing a password on Basecamp, and you’re not protected by 2FA, you’re at a grave risk of having your account compromised. We work hard to protect everyone at Basecamp, but nothing will protect you online like using 2FA and a password manager everywhere you go.

The 5 mistakes you’re likely making in your one-on-one meetings with direct reports

Don’t waste your time. Make sure you’re getting the most out of your one-on-one meetings with your direct reports. 

You’re feeling good: You’ve started to hold regular one-on-one meetings with direct reports. But have you paused to ask yourself, lately, “Am I making the most of them?”

The question is worth asking. One-on-one meetings with direct reports can have a surprisingly large impact on your team’s performance. In Google’s widely known 2009 manager research code-named “Project Oxygen,” they found that higher-scoring managers were more likely than lower-scoring managers to have frequent one-on-one meetings with their team members.

Our own survey results revealed a similar narrative: After surveying 1,182 managers and 838 employees from all over the world this past year, 89% of managers said that one-on-meetings positively affect their team’s performance – and 73% of employees said that one-on-one positively affect their team’s performance, as well. For both managers and employees, the majority of them think of quite highly of one-on-one meetings.

Keep reading “The 5 mistakes you’re likely making in your one-on-one meetings with direct reports”

Q&A: How do I win in a packed category?

Today I got an email from a fellow who asked:

I’ve been trying to think about my next B2B play but everytime I think of an idea I stop myself due to how saturated the markets are. How do you still win in a packed category? I feel like it’s a lot harder to win now than it was 10 years ago.

-J.B.

Starting something new can definitely be intimidating. Especially when there are already lots of other people/companies with a huge head start. I feel you.

But I’m going to ignore all that and focus on what I think is the bigger concern with the mindset represented in the email: This person asks “How do you still win in a packed category?”

Winning what? Winning who? Winning it all? Taking everything? That’s an insurmountable mountain of intimidation right there. Don’t do that to yourself.

How about just making something that can sustain itself? Why do you need to win it all? Why would you ever want to make it that hard on yourself?

Build something good, keep your costs low, keep your growth in check, hold back your expectations, find some customers, charge them money for your good/services, make more than you spend, and you’ll buy yourself another day, or week, or month, or year in business. Just aim to stay open, don’t aim to win anything from anyone. Staying afloat is a win for yourself.

Just start there. The odds are still against you, but they’re a whole lot better than trying to win it all.

Nevermore, Amazon

In the spring of 2019, Danny Caine, the owner of the Raven Book Store in Lawrence, Kansas, overheard a customer saying she could buy a new hardcover online for $15. Danny took to Twitter to explain the economics of independent bookstores and the thread went viral, putting the 32-year-old small business in the national spotlight. Danny comes on the Rework podcast to talk about why his activism and outspoken stance against Amazon haven’t just felt right, but been good for business too.

Open source and power with Matt Mullenweg

Yup, I put the graphic back in

A couple of weeks ago, Automattic announced it had raised $300 million from Salesforce Ventures in a Series D round. In an interview with TechCrunch, Automattic founder and CEO Matt Mullenweg said:

“I think there’s potential to get to a similar market share as Android, which I believe now has 85% of all handsets. When you think about it, open source has a virtuous cycle of adoption, people building on the platform and more adoption.”

That comment kicked off a Twitter discussion between Matt and David Heinemeier Hansson about funding and tech monopolies. Then, in a rare example of Internet discourse taking a positive turn instead of devolving into a Godwin’s Law-fueled nightmare, Matt and David got on the phone to keep the debate going. We recorded their conversation and released it as the newest episode of the Rework podcast.

When to give feedback to an employee?

A perfect time to give feedback doesn’t exist – but some times are better than others. In deciding when to give feedback to a direct report, consider these 4 things.

“When is the right time to give feedback to an employee?” A manager asked me this last week during a workshop I gave at the Business of Software Conference.

He elaborated:

“Sometimes, I want to give feedback but I’m worried it’s going to come across as too petty, or that I’m nitpicking. Should I wait until there’s a time when it’s about something a bit bigger? Or should I give the feedback immediately to them, regardless? Is there ever a right time to give to feedback?”

I told him that he wasn’t going to like my answer: It depends.

Depending on who the person is, what the feedback is, what is going on in the work environment, and even what mental state you are in – all are factors in to when to give feedback to an employee. Choosing the timing well is important. It has big impact to how likely the person is going to change their behavior based on your feedback, going forward.

Keep reading “When to give feedback to an employee?”

How we shaped Basecamp 3

Here’s a common question that’s coming up about Shape Up, our new book on product development:

People in my book club love all the principles, but they had one question: How did they build Basecamp 3 doing this? It seems like all the practices are for adding features to an existing product.

There’s a new appendix in the book now to answer this question: How to Begin to Shape Up: New versus existing products.

We’re working on a new product right now, and we’re following the same approach we used to build Basecamp 3 and Basecamp 2 before it.

There are two phases of work when you start a new product. We call them “R&D mode” and “production mode.”

New products start in R&D mode. Instead of shaping and betting on a specific feature idea, we bet a block of time (a six-week cycle) on exploratory work with an extremely rough list of potential features. An experienced designer/programmer team will pair together skunkworks style to work out the basics of the overall architecture and some key interface elements. Instead of building features to completion, they build just enough to verify that the product hangs together and the architecture accommodates the functionality we’ll need. (The Pragmatic Programmers call this “firing tracer bullets.”)

R&D mode is messy and unpredictable. It’s common to pursue one approach for a couple weeks, realize it’s not working, scrap everything, and then try something else. That would be very unhealthy in production work. But for a new product, you need to get through this experimental phase to arrive at the basic design.

The R&D team integrates shaping and building in a blurry mix within the time box we’ve allocated. They’ll shape an approach, spike it out, learn something, and try something else. That’s why the team needs to be small and senior. There are lots of deep judgement calls to make and no existing code or interface constraints to guide their efforts.

Eventually the R&D team gets to a point where they’re willing to “pour concrete” on the fundamentals. With the key pieces of the architecture in place, constraints now exist for future work. It’s easier to see where new features will go and what they will be built upon. It can take the skunkworks team a few cycles of work before they get to this point. Once they do, we can shift to production mode.

There are still lots of unknowns and unbuilt features in production mode. What’s different is now the architecture is settled and the ground is firm, so we can make surer bets. All the detailed Shape Up methods apply at this point. We don’t know if we’ll like a new feature or if we’ll include it in the final cut of the product, but we can define our appetite for it, shape it, bet time on it, and give it to a team. Instead of building things half-way like in R&D mode, the team is expected to build a fully working version and deploy it by the end of the cycle.

In the case of Basecamp 3, David (co-founder and CTO) started by doing R&D work to define the access model and how data of many different kinds would belong to one project versus another. Extremely bare bones versions of the message board, comments, and to-do features validated the architecture. Those features weren’t anywhere near complete enough to ship, but the stubbed versions gave him confidence that the architecture would accommodate all the functionality we hoped to build later.

We still only made commitments one cycle at a time. We knew it would take multiple cycles to build BC3 — maybe a year’s worth or more. But we didn’t commit to any specific work further than six weeks ahead.

This split between R&D and production mode is also useful for existing products. Sometimes you need to do build a feature totally unlike anything you’ve done before or with unfamiliar technology. In that case, draw a boundary between the part of the app that has a settled architecture and the new area that’s unsettled. Bet time on exploratory work in the new area to firm up the ground. Then if that works out, shape a project with clearer expectations and a hard bet.

That’s how we handled Hill Charts in Basecamp 3. We had never built the kind of high fidelity interactions required to drag dots on the hill, and there were lots of open questions about the data model. For the first cycle, the team wasn’t expected to ship. They had a roughly shaped concept but lots of room for R&D work to figure out how to render the chart and store its history. Then, after we validated the approach, we were able to shape a subsequent project with clearer expectations and build the feature to completion in another cycle.

Haven’t heard of “shaping” or “betting”? All the details about how we work are in the book. You can read it online or download a free PDF here: Shape Up: Stop Running in Circles and Ship Work that Matters.

Heal the Internet (reprise)

The ongoing debate about Big Tech surveillance and consumer privacy has prompted a fair amount of internal discussion and policy changes at Basecamp over our own practices. We’ve stopped using tracking pixels in emails and no longer collect emails for people who download Getting Real, our free ebook. And in late August, David Heinemeier Hansson wrote a post called “You can heal the Internet,” about alternatives to Big Tech.

On the latest episode of the Rework podcast, DHH talks about institutional and personal stances on tech privacy—and why individual action can actually lead to change when it comes to the big problems of our time. (A transcript is also available on the episode page.)