Introducing the book

11 years of experience
8 companies
3 teams led…

and still, one book can shock me by showing how discouraging some workplaces can be. Having immersed myself in the tech world for over a decade, I was under the impression that passion was a default setting for software engineers. I extrapolated that knowledge to other companies and jobs, thinking a similar amount of engagement, creativity, and drive toward success was present everywhere. I’ve recently finished reading “Corporate Rebels” by Pim de Morree and Joost Minnaar, and this book presented the results of research that surprisingly showed that only a small fraction of people actually care about their work.

What can you learn from the book?

It’s all about redefining how people have worked for decades, how companies have organized processes, and how managers have managed people. It shows progressive organizations that dropped the old, outdated hierarchical environment and introduced a modern, flexible, and decentralized style that empowers employees to take action, make decisions, and actually feel like part of the overall success.

One thing though…

Can we - software engineers, tech leaders, software architects - learn anything from the book? That’s a question I asked myself before deciding to write this blog post. I used to work for great companies that already had this modern mindset, and in general, IT companies tend to have that mindset, so does it make sense to read the book?

Definitely!

Even though you won’t be absolutely shocked by everything in the book, you will still note down a few ideas on what improvements to introduce to the team.

In this post, I’ll share my key take-aways from the book. Let’s get started!

The Myth of Cultural Fit

When I started my career, I always laughed at all those “cultural fit” interviews. I joked with my friends “Hey! You just need to tell them that you learn a lot, and you’re really committed.” I always passed those interviews with flying colors. Little did I know that I was just plain lucky!

A few years later, I became a team leader and learned that I was wrong the whole time… and I learned it the hard way.

It was a warm summer day. I was sitting in the office, looking through the window at people wandering around Planty Park in Cracow, still feeling some chills and adrenaline after a recent promotion to a team leader role. Suddenly my manager entered the room with a smile and said that we had a strong candidate for my team. He had just passed the tech interview with no trouble, so I should prepare for the cultural fit interview in the following days.

Well, no biggie! Everyone passes the cultural fit, right? I’ll just meet with the guy, ask a few simple questions, hear the answer “Yeah, obviously I’m learning a lot, I’m fully devoted to the company,” and greet a new teammate!

I searched for all internal materials about this “cultural fit” interview, read them all, and started to get some vague thoughts that it might not be as easy as I thought. The questions were detailed; they dove deep down into the subjects, asked for examples, and detailed explanations.

Then came the day of the interview. I greeted the candidate, praised him for his good results after the tech interview, and started a chit-chat, just to know the guy. I was surprised that the conversation was not going well… It was really hard to get a response from the candidate. Well, I’m hiring for a software engineer role, so obviously, software engineers might not be the talkative type. So I decided to drop the chit-chat and start asking more concrete questions.

“You know, as software engineers, we have to constantly learn to keep up with current knowledge. What are your favorite sources of knowledge? Books? Blogs? Conferences?”

“No, I don’t have any. I don’t read books or blogs, and I don’t attend conferences. I just close my laptop at 5 PM and call it a day.”

“I see… So if you’re faced with a problem you don’t know the answer to, do you reach out to your teammates? What would you do if your teammate asked for your help?”

“Well, I’m being paid for results. If someone can’t deliver the results, it’s their problem. I’m not helping them because I’ll get my results worse, and I’ll have to explain myself.”

I was shocked! 🤯

I appreciated the honesty but, unfortunately, I decided not to proceed with the offer. The whole team consisted of passionate individuals, keen on learning and sharing knowledge, helping each other, so hiring somebody who did not fit that picture would destroy the good relations in the team. It was really hard to reject a candidate with good tech interview results just because he didn’t fit into the team.

The book “Corporate Rebels” suggested that we should hire based on a culture fit and then teach employees to align the knowledge levels in the team, not the other way around. It’s really hard to change the mindset of people, it’s way easier to just equip them with proper knowledge.

I couldn’t agree more with the book on that! Especially after several “cultural fit” interviews where I didn’t decide to proceed with the offer even though the candidates had the experience of a senior, just to finally hire a junior for that role just because I saw a spark in his eyes after I described the projects, challenges and learning opportunities.

I simply knew this junior would rock his way up to the top in no time!

Leader should make all the decisions… right?

I think we all agree that nothing prepares you to become a team leader. Usually, everyone is just promoted to this role and learns as they go. We all have some vague understanding what are the responsibilities of a team leader role. I’ve always imagined that a team leader is a person who makes all the decisions for the team and should be knowledgeable in every part of the project, have answers to every question, and be able to quickly make decisions in every circumstance.

Little did I know that this mindset is the simplest strategy to get you overwhelmed by all the problems, become a bottleneck for the whole team, and make your teammates feel disengaged. In no time, all my teammates were dropping me questions to make decisions.

“How big do we expect our database to be? How many GBs?”

“What should be a TTL for this new token?”

“Do we want to create a new microservice or include that logic in the existing one?”

My team looked to me, the supposed beacon of knowledge, but inside I was drowning in the unknown, and the only thing I could say was - I don’t know!

I felt disastrous. I should have known the answers! I’m the team leader here! My teammates also felt like I should know the answers and at the same time didn’t feel empowered enough to make decisions by themselves.

According to the book “Corporate Rebels”, people have higher job satisfaction when they feel that they can make decisions and make an actual impact in their work. At that particular moment, I realized I was actually sabotaging their engagement by making all decisions go through me!

So, my decision-making had to change… I’ve committed to making as few decisions as possible while coaching people to step up and become microleaders of many small initiatives in the team. What did that look like?

“How big do we expect our database to be? How many GBs?”

“I don’t know. What can we do to calculate that?”

“Well we could take the current traffic, multiply that by the average document size we already have, multiply that by our retention period, and maybe add something like 20-30% of breathing space?”

“That sounds like a great idea! What if we make a mistake?”

“Well, if we find out that we need more space, we can always increase it, we’ll just receive an alert that we’re almost out of space. If it turns out that we don’t need that many GBs, nothing really happens, as the disk space is cheap.”

“Great! Let’s do that! Go ahead and calculate the size of the DB. If you decide to change the calculation formula, go ahead and do it as well. As long as we don’t exceed 100GB because that’s the threshold above which we’ll need to contact our database team.”

See? We’ve discovered the process of how to get the answer. I didn’t have to spend 2 hours searching for needed data, calculating, checking if I didn’t make a mistake, etc. At the same time, my teammate felt proud that he would make the decision. Am I lazy? Not at all, I spent those 2 hours thinking about the roadmap, vision, and high-level architecture for the next projects.

After a few weeks full of discussions like the one above, my teammates learned to make decisions by themselves, they felt that they were responsible for the whole process of designing, implementing, and testing projects. There’s even more to that! 2 years later 2 of my teammates became team leaders and the rest became highly paid senior engineers and architects because they were able to drive huge projects by themselves.

Can we take it even further?

From the managerial books, I’ve learned that delegating decision-making can take two forms.

• Allow teammates to make a decision, but ask them to get back to you before implementing it.
• Allow teammates to make a decision and implement it and ask them to just inform you after the fact what was decided.

The first one is the best option when you’re dealing with a junior or a new hire. The second one is usually a good fit for experienced people, whom you trust they’ll make a good choice. Are there any other options?

“Corporate Rebels” suggests a third, fascinating approach. Allow the teammates to make decisions, but first, they have to consult at least 2 people from the team. They don’t need to reach a consensus, not everyone has to agree on a single option. The decision is the responsibility of one particular teammate, and we trust that this person, after hearing the opinions of others will make the best decision possible.

That’s something that coincidentally sparked in my current team. We’re a remote-first team, and everyone greatly values the remote part of that. We refrain from synchronization as much as possible, but that comes with a cost. How to make decisions with the whole team, when people don’t like synchronous meetings?

We assign one person as the owner of the miniproject and the decision-making is the responsibility of this person. This microleader prepares the knowledge, works out possible solutions, and summarizes everything in one place - it’s either a description of a Jira issue, Github issue, video recording, etc. The rest of the team is asked to asynchronously give their opinion on the subject. After 2-3 days, the microleader is fully equipped with opinions to make a sound decision.

That’s how you do the remote and asynchronous decision-making!

Job crafting

The last thing from the book that resonated with me is the Job Crafting term.

I guess the average software engineering team consists of 4-5 software engineers. Do you think all those people in one team have exactly the same interests? Do they like doing the same tasks? It’s more than obvious that one engineer will be excited to do the frontend tasks, one will prefer backend ones. There might be a person who is more interested in designing the architecture but would be bored with actual coding. It might be the case that for some people, parts of the projects will be extremely boring and unfulfilling, while others might enjoy mundane tasks from time to time.

What can you do about it? How to prevent people from suffering from tasks that do not suit them?

Assign the tasks to people who will actually enjoy them! That’s what Job Crafting is about!

This term is used to describe the process of making your work more satisfying. Without knowing this phrase I did that several times. When I was working on a boring project I decided to participate in all company hackathons, in all side-projects, or even in brainstorming sessions to conceive the next invention and get a patent for that!

How do you actually leverage job crafting in your team?

“Corporate Rebels” suggests a workshop-like approach. Together with the team, write down all the tasks that people in the team have to do. After you have all of them, group similar tasks to form the role. After you have the roles, ask your teammates to assign themselves to the preferred roles. Extra note from me - invent funny or epic names for those roles!

In my teams, I had roles like:

• Cerberus - the person responsible for doing exploratory tests before deploying to production. We wanted every feature to go through the “cerberus” person that will try to intentionally break the thing, discovering any bugs possible.
• Microleader - an engineer that had the responsibility of leading one of the initiatives, making all the decisions, and attending meetings.
• Monitor - like in a classroom, the engineer who is responsible for doing all the maintenance work
• Maestro - a person who facilitates planning, daily, demo, and retro meetings. (We wanted to use orchestrator but that sounded too much like a technical term, so somebody thought that maestro was a good alternative. No idea why, but it got traction).

One thing though is that you should be cautious not to silo the knowledge. If there is specific knowledge connected to a task, be sure to have this knowledge shared among the teammates. If you don’t do that you’re at risk of experiencing a bus factor of 1, which means if one engineer goes on holiday, the whole project might come to a full stop, because of a lack of knowledge. You can prevent that by making some roles rotational.

Summary

In this blog post, we’ve explored my pivotal insights from “Corporate Rebels” by Pim de Morree and Joost Minnaar. The book shatters the illusion that passion is universal in workplaces, revealing the grim truth that only a minority truly care about their work. It advocates for a revolution in workplace dynamics, suggesting a shift from hierarchical to decentralized models that foster employee engagement and empowerment.

We delved into the controversial topic of ‘cultural fit’ and learned that a candidate’s alignment with team values often trumps technical prowess. This aligns with the book’s assertion that nurturing an employee’s mindset is more feasible than altering it.

Leadership styles were also scrutinized. The once common belief that leaders should make all decisions is debunked; instead, nurturing microleaders within the team leads to increased job satisfaction and responsibility. This empowerment allows for more dynamic and autonomous decision-making processes, even in remote settings.

Finally, we touched on Job Crafting, a method for enhancing job satisfaction by assigning tasks based on individual preferences and strengths, fostering both happiness and productivity within teams.

This book is a call to action for modernizing management approaches, advocating for environments where passion and innovation can thrive, profoundly impacting our understanding of what it means to lead and work in today’s world.

Photo by BAILEY MAHON on Unsplash

• ← Previous Post
• Next Post →