No More: It’s The People

“Half of the people at this company should be fired. They’re not productive, don’t care about anything, and show zero sign of ownership. We should never have hired them.”

This was what I heard from my new boss on my very first day. Welcome to the company indeed. For the record, this was not at my current job, but some unspecified number of years ago, at some company that shall remain anonymous.

While extreme, unfortunately it is representative of a feeling that is more common: we do not always see the level of care, engagement and performance that we would hope for from (other) people. And in the absence of any reasonable explanation, we conclude it must be the people that are the problem. We probably hired the wrong ones.

Time to clean house, I suppose?

Before taking drastic action that we may later regret, let’s see if we can come up with some quasi-scientific way to test this it’s the people hypothesis.

As we all agree, science is always the way.

Alright then. Anybody any ideas?

🤚

“We can run a hackathon!”

Thanks dr. Joe. That doesn’t sound related in any way. On the other hand, we haven’t run a hackathon for some time, so sure, it’s summer, whatever, let’s do it.

Anybody willing to organize?

“Wow, that was pretty amazing! We haven’t seen this level of participation in a long time. So much energy. So much commitment. So much creativity. So much cross-company collaboration. Incredible amounts of work done in a short amount of time!”

“It was pretty insane. Funny story: I had a lunch planned with one of the teams, because I was in town for a few days. And they canceled on me last minute, because they wanted to continue working on their project. Free lunch. With me. Canceled. Can you believe it?”

“Right! I got a call late at night, asking for permission on something. Even though I said no, they decided to proceed anyway and figure out a way to make it happen. They simply wouldn’t take no for an answer.”

“Hell yes! Hackathons only from this day forward, I decree!”

🤚

“Oh it’s dr. Joe again. What do you have for us?”

“A few weeks ago you said: we’re not seeing the performance that we would like.”

“Yes, and?”

“After this hackathon, you’re saying: we’re getting better performance than we could ever have hoped for.”

“Yes, and?”

“It’s the same people. So it can’t be the people that are the problem! As we say in science: Quod Erat Demonstrandum. The less elitist thing would be for me to drop my mic, but it broke the last time I did, and the new one hasn’t shipped yet. So now I’m using this built-in laptop mic, which is is actually of surprisingly good quality, but is hard to drop without killing my entire machine. Anyway, my work here is done. Carpe diem, bitchez! dr. Joe out.”

“Ok. That was weird.”

If you have any resemblance of the word “manager” in your title, a big part of the role is to create the right context for people to do their job.

It’s context, and only context that makes a hackathon different from the organization’s day to day. It’s the same company. It’s all the same people.

So if we like what we see during a hackathon, “all” we have to do is adjust the context so that it leads to similar results. A hackathon shows the potential, it’s up to us to figure out how to reach it.

It’s not the people. It’s us. It’s all management.

Just saying.

So, this is an experience worth exploring. What is this context that makes a hackathon different than your typical organization’s day to day, and what can we learn from it?

Here are a few things that come to mind.

Autonomy: Generally a hackathon has a theme or high level goal. This gives some direction, but is not overly restrictive. People have a lot of space for creativity and can make a lot of decisions themselves without being blocked by anything or anybody.

Is that the case in people’s regular day to day?

Focus: During a hackathon, there’s only the hackathon. Calendars are cleared, there are no distractions. There’s just one priority: build awesome stuff.

Is that the case in people’s regular day to day?

Urgency: A hackathon is strictly time bound. A few days; a week; then it’s done. Everybody understands this and adapts plans accordingly, constantly. If you want to see “agile” in action, this is it. On the other hand, people also understand that this urgency is temporary and not sustained, and distribute their energy accordingly.

Is that the case in people’s regular day to day?

Risk tolerance: Hackathon projects can fail and nobody will be upset (except for the intensely competitive types). Something doesn’t work, you pivot. No big deal. Nothing comes out of it? Even though I wouldn’t buy that’s ever the case, that’s still ok. Just a few days wasted.

Is that the case in people’s regular day to day?

Sadly, we cannot realistically start to run the company in hackathon4evah mode (although this is the default mode for many early stage start-ups, and why they tend to be so productive). That said, it can give hints on where the blockers are to be addressed.

More importantly (to me), hackathons confirm that it’s not the people that are the problem. Perhaps, hardly ever.

It’s all context. It’s all management.