The first part of the book is a business fable. If you read I am a Software Engineer and I am in Charge, you know that I love the genre. I love it because it helps me identify with the characters and with the story and better imagine what could be the outcome if I were to apply the same concepts and ideas.
The second part provides the lessons from the fable starting with the two leadership motives:
Reward-centered leadership,
Responsibility-centered leadership.
As mentioned by Patrick Lencioni, no leader is purely on one side, but the one that will be predominant will have huge impact on the success of the leader and his team.
Responsibility-centered leadership is preferred to get to success, and struggle is expected along the way.
Lencioni then covers the five omissions of Reward-centered leaders:
Developing the leadership team
Managing subordinates (and making manage theirs)
Having difficult and uncomfortable conversations
Running great team meetings
Communicating constantly and repetitively to employees
The book is a very short read. I believe that the point 3, 4 and 5 are easy to observe symptoms that 1 and 2 are not happening properly.
The Culture Map is an excellent book by Erin Meyer. As my current team evolves in an international context, I had the idea to use the culture map as an icebreaker to start one of our quarterly meetings.
The team is composed of people from France, Germany, Spain, Sweden, and The Netherlands. The team has to interact daily with a lot of people from the US, and nearly all countries in the EMEA area.
We used a Miro board and one of the culture map provided in Erin’s book (reproduced below).
I gave a short explanation of the first scale: Communicating. Either you are in a Low-Context culture where the communication is precise, simple, and clear, or you are in a High-Context culture where the communication is sophisticated, nuanced, and layered (you are expected to read between the lines).
Then, I asked one question: Where the US would be?
All the team members connected to the Miro board can see the cursors of the others, and so I asked them to move their cursors to the position they thought the right answer would be.
After some discussion, people started to position the US in comparison with other countries. Of course, we covered the fact that a country cannot be a point on a scale but more a range on the scale. We also covered that all people are different and that the more you know a country, the more you can appreciate the subtle differences of the different regions.
We continued to iterate with the next scales:
Evaluating: How people give direct or indirect negative feedback.
Persuading: How people are trained to begin with the theory or to begin with facts or statements.
Leading: How people are used to an Egalitarian or a Hierarchical model.
Deciding: How people are used to decisions made in a Consensual way or Top-down.
Trusting: How trust could be built either though business related activities or through sharing meals and drinks.
Disagreeing: How people are used to see debates and confrontation as positive for the team, or as negative for the team and inappropriate.
Scheduling: How people see the time as linear (everything is scheduled and you stick to it) or flexible (everything can be approached in a flexible manner.
It was a very good opportunity for the team members to express their preferences, and a good reminder that wherever you are on the scale, you have to accept that others could be at another position because they value that position more. They are no “good” position or “bad” position.
A very good starting point to appreciate the diversity of the strengths of the team.
Ranjith Reddy Varakantam, Principal Agile Coach, wrote what we thought was a pretty epic review of I am a Software Engineer and I am in Charge on amazon.in and goodreads.com.
He called it “a lean book” that “conveys new learnings with every chapter.” Ultimately describing it as “Aesop’s Fables in an enterprise setting.”
His words piqued our interest so we reached out to Ranjith to learn more about what he’s up to and how the book helped him. Here’s what he had to say.
—
As a Principle Agile Coach, one of my responsibilities is to ensure that the Developer Group, which consists of around 28 teams, is continuously working on small improvements.
One high priority project that we are working on right now is to create a 100% automated workflow that will allow Operator based Containers to be released with zero manual intervention. This will only succeed if we can get multiple groups to work together to deliver the tooling and functionality.
This is quite challenging as it is a complex project that needs people to solve not just hard technical issues but also cultural ones. The interdependencies between multiple teams and the competing priorities raises the table stakes.
Working with this many people and priorities can at times make me feel that some people are “difficult” and don’t seem to be contributing how I’d like them to be. I was feeling this frustration when I picked up the book. Skimming through the first chapter, to my surprise found the main character was in exactly the same position!
“I’ve done my best,” she says. “Maybe this isn’t the job for me. Maybe I should be in a different company. I just wish everyone around me would do more, be better somehow.” These were exactly the same thoughts going through my head. I became riveted to the book. I wanted to find out more.
By the end of the first chapter, the main character realized her folly by talking things through with her wise colleague. The colleague shows her that instead of ‘venting’, she would make more progress if she spent her time ‘inquiring’.
That changed my state of mind and I started to think about what I could do to ensure that gaps were filled and make things crystal clear for people to improve their efficiency.
As I continued to read chapter after chapter, I realized that the challenges that I face or the thoughts that go through my head are common in organizations. The people are not so different from each other and mostly it’s the same kind of situations that we all find ourselves in.
By the end of the story, I realized that I needed to be more attentive and mindful. To be willing to view the situation from a different perspective. With a little bit of work on ourselves, we are actually capable of making a big difference.
After reading this book, I’m now more interested in looking at the problem from various angles without prejudging people. Instead, I try to see what we can do to solve the problem or challenge at hand.
I’ve also found this book to be a handy reference that I can revisit again and again as there are many things that can be picked up. The best part is that each chapter has a clear set of guidelines and additional reading that I can catch up on.
This book has motivated me to look within myself for answers and realized that most often by working a bit on ourselves, we give birth to new powers and greater degrees of effectiveness.
—
Thanks, Ranjith for sharing your story on how the book helped you. From time to time Ranjith publishes articles on Linkedin and Opensource.com. If you’d like to reach out to Ranjith, the best way is via his Linkedin profile.
Editor’s note: This article is written from the perspective of a fictional character, Sandrine, the protagonist of I am a Software Engineer and I am in Charge. You can learn more about the book at https://iamincharge.club
This story is a sequel to Confinement, published in April 2020.
Sandrine has now been working at home for seven weeks. So many things have adapted during this time that in some ways it all feels normal to her now, but from time to time she is reminded that this is not the permanent reality. Like when Gaspar, the team’s manager, announced during the virtual hot chocolate that the team would continue to work from home for at least another four weeks.
Sandrine remembers how Mary encouraged her to hop on the first virtual hot chocolate call just a month ago. She laughs to herself as she sees how different her mindset was back then.
During that first call, she heard about some of her colleagues who were struggling with homeschooling their kids. She could feel their frustration but it was difficult for her to relate to as she doesn’t have any kids of her own. However, it did remind her how good she was when tutoring younger kids when she was in high school, and so she offered to teach maths every day for three kids that happened to be in the same class.
Sandrine now has a card on the team board for teaching maths. If it sounds weird to you, it also sounded weird to her when Gaspar suggested putting it on there. She resisted the idea at first, but she was convinced when Gaspar reasoned, “By doing this you’ll be helping Julian and Jenny, and therefore you are helping the team. It is logical that this important work should be on the team board.”
Sandrine remembers her promise to Mary to let her know how the virtual hot chocolate calls were going. She fires up the messaging app on her phone.
Sandrine finishes preparing her virgin mojito just in time for the video call.
She sees Mary joining and is stunned to see her in sunglasses, big earrings, and crazy make-up.
“Umm. Hi Mary. That, that’s an interesting look you have there.”
“I just thought I’d fabulize myself for the meeting daaarling.” Mary responds, before turning off the video filter.
“Hahaha, oh I get it now. Phew, it was just a video filter. For a moment there I thought that isolation had really gotten to you.”
Mary and Sandrine enjoy a good laugh before Mary continues, “You should have seen their faces when I joined the team call with that filter on this week.”
“Good to see you spreading the fun.”
“Well, I believe it’s a shared responsibility. Now, tell me, what have you been learning from your virtual hot chocolate calls?”
“Well there was certainly something there that I didn’t see.”
“Which was?”
“I’m now homeschooling maths to some of the other team members’ kids each day.”
“What?”
“Two of my colleagues were struggling with homeschooling their kids who happened to be in the same class and I offered to help out. My 45 minute investment frees up two other team members giving an hour and a half back to the team. But there’s more to it than that.”
“Go on.”
“Well besides being a good distraction in the day for me, as it reminds me when I tutored maths to some of the younger students in high school, it’s also taken on a life of its own.”
“What do you mean?”
“Well, the kids started enjoying it so much that they invited some friends, we now have a group of six. And they gave themselves a team name, the VVs.”
“What does that stand for?”
“I don’t know.” Sandrine laughs, “I guess they want to have their secrets. Anyway, it gets even better.”
Mary sips her drink, eyes locked on the screen in a state of disbelief.
“Salman, he’s a designer from another team in our company, well when he heard about this he decided he wanted to join the movement and is now teaching the kids English. They love his style, especially when he dresses up in a costume on Fridays.”
“Way to go! You are doing a great service to all those parents, and the kids too. Your impact is greater than you think you know.”
“All thanks to you for encouraging me to attend something I was just going to blow off. It’s amazing how a little shift in mindset can provoke such a big impact.”
“Indeed. Thanks for sharing that update with me. I’m definitely going to look at my team mocktail meeting a little differently now.”
Sandrine and Mary go on to catch up about other things. At the end of the call, Sandrine reflects on her experiences over the last few weeks.
“Wow, so much has changed and everyone has adapted in so many new and different ways. If it’s possible to change this quickly in reaction to something, I wonder what’s really possible if I take a more proactive approach.”
Ever felt like Sandrine, where a small step made a big impact?
How has your mindset shifted since Sandrine’s last article? What experiment would you like to try next to add some fun to your team or take some pressure off your colleagues?
Read about Sandrine’s biggest transformation in I am a Software Engineer and I am in Charge, available on Amazon now.
Emilien Macchi is a Senior Principal Software Engineer at Red Hat. He’s been a contributor to OpenStack since almost its inception as an open-source project.
I had the pleasure of having Emilien on Le Podcast to discuss how learning and sharing were essential ways of growing his career in Software Engineering.
We covered many topics including; peer reviews, pair programming, remote work, and I also asked what he thinks are the most important things to develop as a coder—spoiler alert, it is not just technical skills.
As Emilien is also one of the first people who left a review of our book on Goodreads, I asked him what he thought about the book and how it has helped him. Here’s what he had to say.
Right before reading the book, I was, and still am, working on a refreshed Vision and Mission statement for my team. It has been a long time since we last reflected on this and we wanted to understand who we are now, who we want to be, and what we want to achieve in the future. This is a strategic team effort; which requires patience and team interactions.
At the same time, on the technical side, I’ve been working on the simplification roadmap for our product, OpenStack TripleO, where there is a long-term goal to make management of OpenStack clouds simpler and more consistent across the Red Hat portfolio. It involves a cross-team effort, and very often the biggest challenge isn’t technical but a human one.
So I was looking for a book which would “refresh” things I’ve learned before but in a new way. I was eager to read I am a Software Engineer and I am in Charge to learn some new concepts, update my knowledge, and find some inspiration for these challenges.
I’ve known Alexis for a while and I read his first book, Changing Your Team From the Inside, which I really liked and shared with people around me. So for me, it was a natural step to read this new book as I was sure this book would give me the inspiration I was looking for.
I read the book two times.
The first time was just a quick read through as I found that the first part, the story, very intriguing and difficult to put down.
On the second read I tried all the experiments. It was difficult not to rush through this part, as it required more work from me, but when I remembered to be patient I was delighted to realize that the second part was in fact what I was waiting for from the book.
Doing the work for myself gave me access to insights that answered a lot of my questions and gave me new ideas to implement in the work I was currently doing.
It wasn’t all easy going. Some experiments that I tried are still difficult for me in the real world. For example retrospectives. I have a hard time to stimulate the other team members so we can have productive retrospectives. The book gives concrete steps on how to do it with a list of actions but the “do it” is in my opinion the real challenge. The provided links are useful so I just need to spend more time rethinking how we can make people more involved in that exercise.
When I finished the book, I felt that I got another great tool in my library; which I’ll certainly share and re-use for my personal career. The fact that the book is easily written and not that long made me think I could re-read some chapters while experimenting on some exercises again with my team.
I’m very happy to have the book on my desk as something I can reopen from time to time to remind myself about something I learnt before when I need another “refresh”.
The next step is to share this book with my peers. Having this knowledge has helped me, but we could have an even bigger impact if they can also learn some of the described techniques and we start using them within the team when we work together.
Thanks so much Emilien for sharing your story with the book and how it has helped you.
You can learn more about Emilien on his blog: my1.fr/blog And you can follow him on Twitter at: @EmilienMacchi
The trouble with successful people is that they tend to believe that their “bad” habits are not so “bad.” They have proof of that. They are successful. So, what could they do, or more precisely, what could they stop doing to be more successful?
The book presents The Twenty Habits That Hold You Back From The Top:
Winning too much: The need to win at all costs and in all situations – when it matters, when it doesn’t, and when it’s totally beside the point.
Adding too much value: The overwhelming desire to add our two cents to every discussion.
Passing judgment: The need to rate others and impose our standards on them
Making destructive comments: The needless sarcasm and cutting remarks that we think make us sound sharp and witty.
Starting with “No,” “But,” or “However”: The overuse of these negative qualifiers which secretly say to everyone, “I’m right. You’re wrong.”
Telling the world how smart we are: The need to show people we’re smarter than they think we are.
Speaking when angry: Using emotional volatility as a management tool.
Negativity, or “Let me explain why that won’t work”: The need to share our negative thoughts even when we weren’t asked.
Withholding information: The refusal to share information in order to maintain an advantage over others.
Failing to give proper recognition: The inability to praise and reward.
Claiming credit that we don’t deserve: The most annoying way to overestimate our contribution to any success.
Making excuses: The need to reposition our annoying behavior as a permanent fixture so people excuse us for it.
Clinging to the past: The need to deflect blame away from ourselves and onto events and people from our past; a subset of blaming everyone else.
Playing favorites: Failing to see that we are treating someone unfairly.
Refusing to express regret: The inability to take responsibility for our actions, admit when we’re wrong, or recognize how our actions affect others.
Not listening: The most passive-aggressive form of disrespect for colleagues.
Failing to express gratitude: The most basic form of bad manners.
Punishing the messenger: The misguided need to attack the innocent who are usually trying to help us.
Passing the buck: The need to blame everyone but ourselves.
An excessive need to be “me”: Exalting our faults as virtues simply because they’re who we are.
The “twenty-first” habit is goal obsession.
The idea that being obsessed with a high-level goal makes you forget the here and now. The present in which you are, indeed, destroying all your chances of reaching your goals.
I decided to use the twenty habits with a leadership team I just met.
The first part of the session was reviewing and discussing the habits. Listening to the questions and discussions can teach a lot about the people in the room.
The second part was for the team members to identify for each other, through an anonymous survey, what habit they thought the others in the team should focus on removing.
The third part was for the team members to discover the results, and pick the habit they will want to work on during the next quarter.
The last part was to select their accountability partner to work with to achieve the goal.
I am happy with the results so far. If you try the practice, let me know through the usual means: email or Linkedin.
Career growth in software engineering is often described as a matter of accumulating technical skills, mastering new tools, or moving into more complex systems.
In reality, the journey is more nuanced.
In this episode of Le Podcast on Emerging Leadership, I had the pleasure of welcoming Emilien Macchi, Senior Principal Software Engineer at Red Hat, to discuss how learning and sharing have shaped his career.
Learning as a continuous practice
Emilien is a long-time contributor to OpenStack, having been involved nearly since the inception of the project. Originally from France and now based in Canada, he has built his career in distributed, open-source environments.
A recurring theme in our conversation is that learning never stops. And more importantly, learning rarely happens alone.
We discuss how practices such as:
peer reviews
pair programming
open discussions
and shared problem-solving
contribute not only to better code, but to better engineers.
Collaboration, including remote work
Emilien shares a perspective that may surprise some: he believes that collaboration can be easier and better in remote contexts.
We explore why remote work, when supported by the right practices, can:
improve focus
encourage clearer communication
and create more inclusive collaboration
This naturally connects with earlier conversations on distributed teams and asynchronous work.
Growing beyond technical skills
Of course, I also asked Emilien what he believes are the most important things to develop as a software engineer.
The answer goes beyond technical skills.
We talk about:
communication
curiosity
responsibility
and the ability to learn with others
These capabilities shape long-term impact far more than any specific technology.
A reflection on practitioner leadership
As Emilien was also one of the first people to leave a written review on Goodreads, I asked him what he thought of I am a Software Engineer and I am in Charge.
This led to a broader reflection on responsibility, ownership, and how engineers can increase both their impact and satisfaction at work.
A final thought
If you are a software engineer wondering how to grow without chasing titles or hype, this episode offers a grounded and inspiring perspective.
Growth, as Emilien shows, is less about standing out and more about learning, sharing, and contributing over time.
A day takes a long time to travel around the world.
So, we set the book to go live on Amazon on May 1, and here in Australia, and over where Alexis is in France it’s May 1 and the book is available on amazon.com.au and amazon.fr.
But amazon.com isn’t quite at May 1 yet, although by the time you read this it might be.
Anyhow. As soon as it’s May 1 in your part of the world (hope the weather’s good there btw) head over to your country’s amazon site and search for:
“I am a Software Engineer and I am in Charge”
We hope you buy it. We hope you read it. We hope you enjoy it. But most importantly, we hope you do something with it.
Amazon reviews are most welcome.
And of course, feel free to reach out to Alexis and me if you’d like to discuss it—authors@iamincharge.club
Great teams are not defined by talent alone. They are shaped by clear expectations, shared responsibility, and leadership that shows up consistently.
In this episode of Le Podcast on Emerging Leadership, I had the great pleasure of welcoming Jason McKerr, Engineering Leader for Management and Automation at Red Hat, to discuss his Thirteen Rules of a Team.
A practical leadership framework
I first encountered these rules during a mentoring conversation with a member of Jason’s team. What struck me immediately was how practical and grounded they were.
They are not aspirational slogans. They are decision rules — principles leaders and team members can rely on when things get difficult.
My objective for this episode was simple: to have Jason explain where these rules come from and how he uses them in practice.
The Thirteen Rules of a Team
Here are Jason’s thirteen rules for team members and team leaders:
Have fun.
Do good work. Make some money.
Take care of the people who work for and with you. The team comes first.
Take care of the user or customer.
Take care of the people you work for. Rules 3 and 4 will do most of the work here. The boss always comes last.
It is the team’s obligation to challenge its leader. You won’t get smacked down, you’ll get more respect. Do it appropriately and respectfully. In private.
Once the leader has made a decision, even if a team member disagreed before, it is now their responsibility to support that decision externally as if it were their own.
There is no such thing as a bad team, only bad team leaders. If the team is struggling, it is still the leader’s responsibility to make it better.
It is the team leader’s job to protect the team from the outside so they can do their work.
Don’t ever say, “That’s not my job.”
Passing knowledge on is a core part of leadership. Teach others. Share what you know.
It is a leader’s job to push power and loyalty down, not up.
See rule number one.
Rules that guide everyday leadership
What makes these rules powerful is not their originality, but their consistency.
They:
clarify responsibility
make expectations explicit
remove ambiguity when tensions arise
Jason also explains how he reviews these rules with new team members during onboarding, using them as a shared reference point from day one.
A final thought
Frameworks don’t replace leadership. But the right framework can support it.
If you are leading a team and looking for principles that are both demanding and humane, this episode offers a clear, actionable reference.
Listen to the episode to hear Jason walk through the rules, explain how they play out in real situations, and share how they support strong, self-managing teams.
As always, I would love to hear what resonates with you.
“This is an excellent publication if you are ready to rewire your brain to take charge of your development rather than enduring your work.”
— Julien Danjou, Staff Engineer.
“While targeted for Software Engineering, a lot of (if not all) concepts described in the book can be applied in nearly any job. It’s inspiring, and honestly, I wish I had this book when I started my career!”
— Emilien Macchi, Senior Principal Software Engineer.
“This book completely changed how I viewed my work and how I work with other people.”
— You. (Well, this could be you, once you’ve read the book of course.)
OKRs are often presented as a goal-setting framework. Something to roll out, track, and review.
Used well, OKRs are something else entirely: a learning practice that helps individuals, teams, and organizations focus on what really matters.
In this episode of Le Podcast on Emerging Leadership, I had the pleasure of welcoming Bart den Haak to explore OKRs from a very practical perspective.
From startup practice to long-term learning
Bart is a software engineer who first encountered OKRs more than ten years ago in a startup context. Since then, he has continued to use OKRs across different environments and now advises companies on how to adopt them meaningfully.
This long-term perspective makes the conversation especially grounded. We talk less about theory and more about what actually works.
Revisiting the foundations of OKRs
Building on a previous episode where I shared an approach to creating great goals using OKRs and Impact Mapping, this conversation goes deeper into the fundamentals:
what OKRs really are
how they differ from other goal-setting approaches such as MBOs, Balanced Scorecard, Hoshin Kanri, or 4DX
who can use OKRs: individuals, teams, or entire organizations
where to start when introducing OKRs
Rather than treating OKRs as a one-size-fits-all solution, we explore how context matters.
Learning zones and common pitfalls
A key part of the discussion focuses on learning.
Bart explains how OKRs can help teams:
step out of their comfort zone
enter a learning zone
while avoiding the danger zone where pressure and fear take over
We also discuss common pitfalls:
turning OKRs into performance evaluation tools
confusing activity with impact
setting goals that are either too safe or too vague
Resonance with practitioner leadership
Bart’s approach resonates strongly with me and aligns closely with the ideas I explore in Changing Your Team From The Inside and I am a Software Engineer and I am in Charge.
In all cases, the underlying idea is the same: leadership is a practice, and tools only work when they support responsibility and learning.
Julien Danjou is a Staff Engineer at Datadog, where he’s in charge of building a production profiler for Python. Their goal is to provide performance analysis of their customers’ applications by understanding how their production systems behave and then optimize them.
His other hat is Mergify, building a workflow automation system for GitHub. You define rules, e.g., “merge this pull request when the CI passes and the code has been reviewed” and their bot does the merge for you. Simple.
Julien was sketching out his next Python article for his personal site when he received my email request to be an early reviewer of I am a Software Engineer and I am in Charge. I thought of him because he was always interested in reading professional development books that we talked about as much as he enjoyed continuing to develop his own technical chops.
Of course, Julien and I had worked together at eNovance and Red Hat so I’m sure he was keen to see what Michael and I had written in I am a Software Engineer and I am in Charge just out of curiosity, but he was also keen to understand if this book could genuinely push his leadership skills further.
Despite his unsureness, and his own priorities, the book looked like a quick enough read and his curiosity to learn what was in it tipped him over the edge.
Immediately the book challenged the way he thought about how he interacted with other people, but the book was written in a way that reminded him of The Phoenix Project, which he really enjoyed reading, and gave him the confidence to keep going. Reading Sandrine’s story pointed out many situations he witnessed or encountered directly in the past. He became inquisitive about how she would handle the situation.
At the end of each chapter is a summary of what we learn from the story and Julien found this section particularly helpful to pull out and internalize the key points he was learning. The real test, where the rubber meets the road so to speak, was being able to choose an experiment to validate his findings for himself. It was only then that he knew this book could help develop his skills because he’d actually be able to prove it to himself by doing the experiments.
Julien told me that he did have one regret about the book though.
Julien would be happy to connect with you if you share common interests and are entrepreneurial minded. Right now, that would cover working on Python performance, building a SaaS startup, or cooking. 🙂
You can reach him through email at julien@danjou.info or on Twitter @juldanjou.
