u/damonflowers

I used to think a busy Slack meant the team was productive.

More messages, more activity, more things moving.

But the bigger the team got, the more I realized the opposite was true.

If your Slack is constantly going off, it usually means something is broken underneath.

People are asking questions that shouldn’t need to be asked. Clarifying things that should already be clear. Looping in others just to move simple tasks forward.

It feels like work, but it’s mostly coordination overhead.

At one point, our Slack was nonstop. Every small decision, every clarification, every “quick question” had to go through it. And without realizing it, I became the central node. Everything flowed through me or needed my input.

That’s when it clicked.

Slack wasn’t the problem. It was exposing the lack of a real system.

So we flipped how we operate.

Instead of using Slack as the place where work gets figured out, we built a system where work is already defined before it starts.

Every team has a clear lane. Clear outcomes they own. Clear boundaries on what they decide vs escalate. We defined what “good” looks like so people aren’t guessing. And most importantly, we created a single source of truth for how things are done.

https://preview.redd.it/195kycmrcrvg1.png?width=1083&format=png&auto=webp&s=7d9602b9a01cba8075c2e6ce64bebc3c50883167

We built all of that in Notion.

Then we layered AI agents on top of it, so when someone needs context, process, or past decisions, they don’t have to ask in Slack. They can just query the system and get an answer instantly.

If it’s useful, I can share how the Notion setup actually works behind the scenes in a separate post since this one is already about Slack, just lmk in the comments.

But the real shift was simple. Slack became the exception, not the default.

Now it’s mostly used for edge cases, real collaboration, or things that actually require human discussion.

The result is fewer messages, but way more output.

New hires ramp faster because they’re not piecing things together through conversations. They plug into something that already exists.

And it changed how I think about productivity completely.

A noisy Slack feels productive, but a quiet one usually means your system is doing its job.

Curious how others are seeing this in their teams. What’s actually working for you?

I’ve been thinking about this after seeing more founders complain about hiring quality lately.

The common assumption is simple. If a new hire isn’t delivering, they were the wrong person.

But I’m starting to think that’s wrong most of the time.

I read a study from McKinsey yesterday that said it can take anywhere from 3 to 6 months for a new hire to reach full productivity in most companies. In more complex roles it can stretch even longer.

That sounds normal on the surface.

But when you look closer, that timeline isn’t just about the person learning the job. A huge part of it is them trying to figure out what the job actually is.

And that’s where the real problem starts.

Most founder-led businesses hire into ambiguity.

There is no clear definition of what winning looks like. No documented steps. No real SOPs. No consistent daily or weekly cadence. Just a rough expectation and a lot of moving parts.

So the new hire spends their first few months guessing.

They try something, get partial feedback, adjust, and try again. Meanwhile, the founder is watching and slowly losing confidence, thinking they made a bad hire.

But the reality is different.

You didn’t hire someone to execute a system, you hired someone and expected them to build the system while executing it.

Those are two completely different jobs.

This simple mistake slowly kills a business, because as a small company you can’t afford to pay a $100K salary and only get a fraction of the output from someone who should be driving your revenue forward.

Let's see it this way instead 

If someone knows exactly what to do, how to do it, and what good looks like, they can actually focus on performing instead of guessing.

In that environment, a great hire can start contributing in weeks, not months.

So I think the takeaway is uncomfortable but useful.

A large percentage of “bad hires” are actually good people placed in bad systems.

If you define the role clearly, document the steps, set a cadence, and make outcomes obvious, you probably unlock 80 percent more output from the same person.

Curious how others think about this.

When a hire doesn’t work out, do you default to blaming the person or do you look at the system they walked into first?

I’ve been thinking about this after seeing more founders complain about hiring quality lately.

The common assumption is simple. If a new hire isn’t delivering, they were the wrong person.

But I’m starting to think that’s wrong most of the time.

I read a study from McKinsey yesterday that said it can take anywhere from 3 to 6 months for a new hire to reach full productivity in most companies. In more complex roles it can stretch even longer.

That sounds normal on the surface.

But when you look closer, that timeline isn’t just about the person learning the job. A huge part of it is them trying to figure out what the job actually is.

And that’s where the real problem starts.

Most founder-led businesses hire into ambiguity.

There is no clear definition of what winning looks like. No documented steps. No real SOPs. No consistent daily or weekly cadence. Just a rough expectation and a lot of moving parts.

So the new hire spends their first few months guessing.

They try something, get partial feedback, adjust, and try again. Meanwhile, the founder is watching and slowly losing confidence, thinking they made a bad hire.

But the reality is different.

You didn’t hire someone to execute a system, you hired someone and expected them to build the system while executing it.

Those are two completely different jobs.

This simple mistake slowly kills a business, because as a small company you can’t afford to pay a $100K salary and only get a fraction of the output from someone who should be driving your revenue forward.

Let's see it this way instead 

If someone knows exactly what to do, how to do it, and what good looks like, they can actually focus on performing instead of guessing.

In that environment, a great hire can start contributing in weeks, not months.

So I think the takeaway is uncomfortable but useful.

A large percentage of “bad hires” are actually good people placed in bad systems.

If you define the role clearly, document the steps, set a cadence, and make outcomes obvious, you probably unlock 80 percent more output from the same person.

Curious how others think about this.

When a hire doesn’t work out, do you default to blaming the person or do you look at the system they walked into first?