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.)

Slow Fashion

“Dreams shouldn’t be sensible.” In 2011, David and Clare Hieatt launched Hiut Denim in a small Welsh town that had been home to a jeans factory for 40 years. The Hieatts saw an opportunity to restore those lost jobs—and to do it in a way that fit with their ideas about building a sustainable business. In this episode of the Rework podcast, David Hieatt talks about taking the slow money; what it’s like when a mega celebrity endorses your brand; and his efforts to reduce the environmental impact of a ubiquitous item of clothing.

Farewell, Happy Camper

Basecamp has a new website and a new logo. If this is the first you’re hearing about it, it’s because we opted out of the big rebranding announcement that many companies undertake. There should be a post from Jason Fried forthcoming here on Signal v. Noise, but in the meantime, check out the latest episode of the Rework podcast. Jason and marketing designer Adam Stoddard talk about what prompted the new look and the laidback way it came together.

How to motivate employees? Don’t.

Do this instead. Here are 6 ways to motivate your team that doesn’t undermine their intrinsic employee motivation that they already have.

I need to figure out how to motivate my employees.” When was the last time thought that to yourself? It could’ve been the other week, when you noticed one of your direct reports dragging his feet on a project that’s critical to the company. Or, perhaps it was the other month when you felt frustrated that your team wasn’t being proactive about addressing customer issues.

If either of these situations feel even remotely familiar, you’re not alone. I hear this sentiment of “how to motivate employees” frequently from managers we work with who use Know Your Team, and I often am asked countless questions about it.

Keep reading “How to motivate employees? Don’t.”