Back in the 1960s, in the dorms at MIT, very young and brilliant people got their hands on the first user-programmable computers. This is where it all started, “The Hacker Way,” the culture of tinkering with computers and achieving limited but remarkable results. This culture is also not confined to the software domain. You could’ve been a hacker if you tinkered with hardware. If you found new ways to perform art, you could also be a hacker. It’s all about the mindset and not about the tools.

The core concept of this culture was in trying and failing and trying again — while sharing the knowledge with your fellow hackers so they can build upon your mistakes.

Nowadays, the word “hacker” is used negatively, portrayed by the media as villains who rob banks and spread ransomware. In this article, I’d like to go back to the term’s original meaning — bold enough to build something quickly, test the system’s boundaries, and learn from the failures. Putting experimentation and innovation at the front of the company and eventually embracing transformation and not running from it.

Companies start with a “hacker mentality” — they need to release the product as soon as possible and find the product-market fit before the money runs out. Eventually, though, as the company grows, internal bureaucracy and the desire to mitigate risk start to overshadow real innovation. The company becomes rigid, transformation becomes complicated, and experiments non-existing.

I think this is where the companies go wrong.

Being a software company means being agile and dramatically speeding up the feedback gathering. Back in the day, companies could only measure their performance four times per year — imagine how many users would leave Uber/Airbnb/Meta if they would evaluate user feedback every quarter instead of deploying several times per day with a/b testing and new insights from data.

For the companies that consider themselves digital natives — innovation means having holistic hacker structures with fast ideas and cheap customer experiments. Hacker culture came into the business world with design thinking and lean startup methodologies. As old and well-established companies are eyeing the methods of the hacker way, this culture is changing how we work and how we do innovation.

But the hacker culture is not only beneficial for big companies like Netflix or Meta, or Google. The concepts can be adapted to any size company. Let’s talk about how you can lead your in-house teams of hacker entrepreneurs.

The Hacker Way

As I mentioned before, being a hacker is a change in mentality and a change in the processes surrounding you. The culture is catalyzed through a symbiosis between the hacker mentality — “I will make it better and more useful” and the high-growth entrepreneurship attitude — “I will experiment and make it worth it.”

So what does it mean to have hacker innovation inside your company, and what kind of culture do you need to embrace as a technical manager?

Step up and do it

If you see that something, be it a process, a module, or a system, is not realizing its full potential — go and fix it. Hackers believe that everything can always be better, and nothing is ever finished. There are a million different ways to improve things and a million different ways it can go wrong. Change always involves risks, and even the best hackers don’t always build the right way. But the benefits of the risks far outweigh the negatives of stagnation.

From the management perspective, it should be clear to the employees that they should not be afraid of changing the status quo. Encourage your team to make bold decisions, and tell them it’s OK to be wrong sometimes in pursuit of a better future.

Only if they know that you have their back will they be comfortable stepping up without you supervising them. This is where the constant improvements come from, a 1% improvement here, a 3% improvement there, and eventually, you have a new system that is far more efficient than before.

One thing you need to keep in mind about middle management is that they are often there to control risk, control behavior, and control chaos. This contradicts the hacker culture where the goal is to set boundaries and goals and then give the hackers the autonomy to do as they see fit “for the best of the company.”

You might think this is too much and will bring only chaos to the structure, but that’s not true. For example, if there’s a Product Owner, who acts as middle management, they don’t just let the team build what they want; they guide them in the right direction, but without controlling it per se.

There must be both dark and light. I will do what I must to keep the balance, as the balance is what holds all life. There is no good without evil, but evil must not be allowed to flourish. There is passion, yet peace; serenity, yet emotion; chaos, yet order. I am a wielder of the flame; a champion of balance. I am a guardian of life. I am a Gray Jedi.
Leor Danal — The Gray Jedi

Balance is key. From the management perspective, the boundaries need to be neither too loose — which makes developers lose focus — nor too strict — which makes people unhappy. This makes the life of Product Owners and alike complicated — managing hacker innovation means keeping everyone aligned and focused on:

• Doing the right things means doing things relevant to the goal.
• Doing things that have an impact — meaning solving the most critical problems first.
• Not wasting resources — meaning doing stuff that moves the needle and not just playing around with the latest tech. Data beats opinion

As Mark Zuckerberg wrote in 2012 when Facebook filed for IPO: “Code wins arguments.” And as my business partner Jean-Paul loves to say, “Data beats opinion.”

In a hacker-friendly environment, it’s better to build a prototype and test the idea on real users and see what sticks rather than hypothesize and discuss what the feature should look like in endless meetings. In the end, in big companies, this risk-free innovation method might be helpful to some people who prefer talking rather than doing because then they can never fail:

• If they talk and do extensive research and the project gets scrapped because it’s too much risk or hard to achieve — oh well, nothing lost, nothing won, no risk involved.
• If they talk and do extensive research and then talk some more with consultants/contractors, etc., only the risk-free projects will survive and be paraded as trophies of success.

Hacking is an inherently hands-on and proactive discipline. Instead of debating for weeks whether an idea is viable or what the best way to build something is, hackers would rather build a quick prototype, gather real data, and see what works.

From the management perspective, in a hacker-focused enterprise, this means actual data should also drive decision-making instead of status and seniority. The information flow should be free from subjective interpretation until such creativity is required. Don’t let opinions from C-Level executives influence or much-worse contradict decisions made based on data.

Complete Transparency

A hacker is always open about his intentions and actions. No hidden agenda, no taking it personally — I did X because of Y, and I failed when I performed Z because of Q. More information equals better-prepared colleagues who can help tackle the problem.

This goes both ways, as hackers should be transparent in their actions, so should the company be transparent in things around the people.

At our digital agency, we try to be open about the why and the how of any strategic decision the management makes. We hold monthly meetings where we do several things:

• First of all, we go through the decisions and our reasoning behind them. It doesn’t help if all your employees see — is the result of your reasoning without explanation. Share your thought process with them.

• We share our deepest darkest secret — current financials. We do that so that everyone is aligned on what we need to achieve.

I believe in the open world, open data, and open APIs (especially open banking APIs). The more open we are, the better decisions we make and the more significant an impact we make.

From the management perspective, transparency means not shooting the messenger when he brings you bad news. Two main information streams are important:

1. Bottom -> Up Communication. Mostly negative signals. Where are the risks? And what’s happening that you should know?
2. Up -> Bottom Communication. Mostly positive signals. What’s good that’s happening? Who should be praised? Whose experience needs to be shared across all teams?

You either accept that failures will happen and you will know about them first, or that failures will happen and you will know about them last. Nurture a trusting relationship with your peers, so you constantly receive signals from your hackers about the status quo.

It also works the other way — when something good is happening, make it known, send signals to your hackers that their work doesn’t go unnoticed, that they’re doing great. Or if the developer is struggling behind — talk with him early and openly, point out the things that need improvement, and if nothing changes and they are fired a few months down the road, it will not be a surprise for them.

Competence above all

Developers are the ones who actually create the software that powers the company. These hackers are inside the engine room shoveling the coal, keeping the whole ship running. They need proper tools, skills, and knowledge to make sure they can deal with everything that comes their way.

you should have a team that contributes proportionally

To maintain a proper pace, developers should have nothing distracting them other than the challenge they are currently facing. The tools, the hardware, the supplies — the management should provide everything.

In such an environment, it’s easy to distinguish people who are more “attitude” than “competence.” It’s also important to reward those with competence and punish those with “attitude” as that has no place inside the engine room.

Hackers are not kids who need babysitting, and you’re not a kindergarten teacher to deal with the drama. Hackers themselves value peers who prove themselves and distrust people who are dragging them down. As a manager, you’re doing a disservice by keeping people who are not performing to your team’s standards.

The hard work and dedication developers put into understanding and fixing bugs should be rewarded by having only the people who contribute proportionally to the team’s effort.

Conclusion

Times have changed a lot since the initial hacker term was introduced. Today software is not something that only a few companies have, and automation is not something only the big enterprises implement. Even the most conservative domains are switching to a software-based approach with innovation.

Software and general advancements in AI are unstoppable forces that will, with time, make any behemoth submit to them. To survive, enterprises must ride the wave of fast pace innovations — getting clever hackers on board and looking for new ways to solve problems.

There isn’t a company in the world that can live without software, and soon most companies will have their in-house software product. Instead of hiring people who only talk about building products, hire hackers that do and embrace the culture.

Read more essays by a veteran CTO at vadimkravcenko.com