Chemaclass - communication

Working With the Garage Door Open

2026-07-14T00:00:00+00:00

Most people work with the garage door closed. They work in private and raise it only when the car is polished and parked. The neighbors see a finished thing. Never the work.

The phrase comes from writer Robin Sloan. Researcher Andy Matuschak turned it into a practice: notes and half-baked ideas visible to anyone walking past.

Open the door.

It means showing the work while it’s still in progress. The draft with the ugly variable names. The experiment you’re halfway through. Not the demo. The middle.

Why we keep it closed #

Fear, mostly. A closed door protects you. Nobody judges a mess they can’t see.

So we hide the drafts. We only push code once it’s clean enough to survive review. By the time anyone sees the work, every real decision was made in private.

That instinct feels safe. It costs you the exact moments where help was still possible.

A finished result can only be admired. A work in progress can be shaped.

What the open door gives you #

When people see the middle, they can change it. A teammate spots the dead-end approach before you sink another day into it. A junior asks the “dumb” question that turns out to be the real problem. Pair programming is this at its purest: the door open, live.

The open door also kills the myth that seniors don’t struggle. When a junior watches you get stuck and google an error you “should” know, they learn what real work looks like. Not the highlight reel.

I lived this with bashunit, my bash testing library. I shipped it imperfect. Everyone who looked inside the garage shaped it: bug reports, feature requests, pull requests. Same with Phel and my public .claude folder. The open-source way.

But an open door isn’t enough #

Here’s the trap. You leave the door up, open a PR, write notes in a shared doc, and wait for help to arrive.

It doesn’t. Nobody wanders into your garage.

Visibility is passive. “Public by default” is the floor, not the goal.

Leaving the door open is not the same as inviting someone in.

The skill isn’t openness. It’s pushing the right signal to the right people, on purpose.

Push signal to the right room #

Every channel comes with an expectation of who reads it. Matching your update to it is the whole game. Post in the wrong room and you’re noise or invisible.

The whole company reads it. #general. Post only what matters to everyone.
The tech team reads it. #engineering. Where a work-in-progress update belongs.
Interested people opt in. #insights: industry news, customer signals. Useful, but nobody has to read it.
Nobody has to read it. #random. Say whatever.

Same update, four different outcomes depending on where it lands. Learn the map before you broadcast.

What a good signal looks like #

A good update is not “hey, I pushed something.” It carries enough context that a reader can engage without asking you a single question.

Say I’m halfway through a pilot: a new way to slice and review pull requests, tested on one team. I don’t wait for the end. A short update goes to #engineering: where I’m stuck, plus one explicit ask. “Has anyone tried this with a monorepo?” gets answers.

When the pilot ends, the result goes to the same room:

What I tried and why it mattered.
What worked, with a concrete before and after.
What didn’t, honestly. The failed part is the most useful part.
What you’d do to try it yourself.

Both are signals, not statuses. They turn one team’s experiment into something the whole org can copy or shoot down. This is Ship, Show, Ask applied past the pull request.

Start small #

Pick one thing this week. One experiment, one draft, one stuck moment. Do two things: leave the door open, then walk out and tell the right room it’s there.

You’ll get help you didn’t expect. You’ll teach someone without meaning to. And the fear that kept the door down will look smaller from the other side.

The polished result impresses people. The pushed signal is how the work gets better.

Open the door. Then point at it.

People Skills

2024-09-02T00:00:00+00:00

So, you’re a software developer, and you’ve mastered coding languages, algorithms, and all the tech stuff. That’s awesome! But here’s the deal: technical skills alone won’t get you as far as you might think.

If you can’t work well with others, it doesn’t matter how great your code is, nobody will want to work with you.

Why People Skills Matter in Software #

In software development, collaboration is everything. Projects aren’t just solo endeavors. You will be part of a team, with other developers, designers, or even non-tech folks like managers and clients. How you communicate, collaborate, and handle feedback can make or break your success.

The Brilliant but Difficult Teammate #

Think about it. Have you ever had that one teammate who’s brilliant but hard or nearly impossible to work with? Maybe they don’t listen, get all the credit, or make everything more complicated than it needs to be. No one likes working with that person, right? It’s the same for you. If you can’t get along with your team, it doesn’t matter how good your code is.

What Being a Good Team Player Means #

Being a good team player means listening to others, being open to feedback, sharing ideas, and, most importantly, being respectful and considerate. You want people to enjoy working with you, not avoid it.

Good people skills help you build strong working relationships, solve problems faster, and create a better work environment for everyone. Don’t just aim to be a coding expert, ensure you’re also great to work with.

The Long-Term Impact #

In the long run, your people skills can boost your success as much, if not more, than your technical abilities. They play a vital role in a team’s success and make the work experience enjoyable for everyone involved.

People skills are as necessary as technical skills. No one will want to work with you if you are not a good team player.

What are people skills? #

The competencies that enable you to interact effectively and smoothly with others.

Core Communication Skills #

Communication: The ability to clearly convey ideas, listen actively, and engage in meaningful conversations. This includes both verbal and non-verbal communication.
Empathy: Understanding and being sensitive to the feelings, thoughts, and experiences of others. It involves seeing things from someone else’s perspective.
Emotional intelligence: Recognizing and managing your own emotions and understanding and influencing the emotions of others.

Collaboration Skills #

Teamwork: Working well with others to achieve common goals. This includes collaboration, sharing responsibilities, and supporting colleagues.
Conflict resolution: The ability to handle disagreements and disputes constructively, finding solutions that satisfy all parties involved.
Negotiation: Finding mutually acceptable solutions or compromises during discussions or disagreements.

Growth and Influence #

Adaptability: Being flexible and open to change, adjusting your approach as needed to meet different situations or personalities.
Leadership: Inspiring and guiding others, providing direction, and fostering a positive environment.
Networking: Building and maintaining professional relationships that can provide support, opportunities, and resources.

These skills are essential in almost every job and help build strong relationships, enhance teamwork, and create a positive work environment.

Why They’re Harder Than You Think #

These are often called interpersonal or soft skills, but mastering them can be surprisingly challenging, perhaps even more so than many technical skills. Unlike “hard skills,” which are tangible and can often be learned through a few hours or days of study, people skills involve navigating the intricate web of human emotions, experiences, and expectations.

While technical skills might require you to dive into documentation, run experiments, and refine your approach, understanding and relating to people is far more complex.

Humans bring their feelings, backgrounds, and routines into interactions, adding layers of complexity beyond machines’ straightforward logic. These personal details shape the reality we perceive, making interpersonal skills an essential yet complex part of effective communication and collaboration.

Prisoner's Dilemma

2024-06-27T00:00:00+00:00

The Prisoner’s Dilemma is a hypothetical game set up showing a situation where people won’t want to work together even when it’s beneficial to do so.

It’s just a long way of saying people don’t like to be taken advantage of. It’s often game theory 101.

The Prisoner’s Dilemma illustrates the complexities of strategic decision-making, where individuals must choose between cooperation and betrayal, often revealing insights into human behavior and the consequences of self-interest versus collective benefit.

Premise #

Source: Wikipedia

Two members of a criminal gang are arrested and imprisoned. Each prisoner is in solitary confinement with no means of speaking to or exchanging messages with the other. The police admit they don’t have enough evidence to convict the pair on the principal charge.

They plan to sentence both to a year in prison on a lesser charge. Simultaneously, the police offer each prisoner a bargain. If he testifies against his partner, he will go free while the partner will get three years in prison on the main charge. Oh, yes, there is a catch …

If both prisoners testify against each other, both will be sentenced to two years in jail. The prisoners are given a little time to think this over, but in no case may either learn what the other has decided until he has irrevocably made his decision.

Each is informed that the other prisoner is being offered the very same deal. Each prisoner is concerned only with his own welfare, with minimizing his own prison sentence.

This leads to four different possible outcomes for prisoners A and B:

If A and B both remain silent,
- they will each serve one year in prison.
If A testifies against B but B remains silent,
- A will be set free while B serves three years in prison.
If A remains silent but B testifies against A,
- A will serve three years in prison and B will be set free.
If A and B testify against each other,
- they will each serve two years.

The Iterated Prisoner’s Dilemma #

It is just like the regular game except you play it multiple times with an opponent and add up the scores. But it can change the strategy and has more real world applications as it resembles a relationship.

This is closely related to trust, human behavior, and social constructs in relationships that impact us both individually and collectively.

In the Prisoner’s Dilemma, the best strategy is to start with cooperation, but then mimic the other player’s previous action in the following rounds, rewarding cooperation and punishing betrayal.

Don’t trust, verify.

What Kills Agility?

2024-05-30T00:00:00+00:00

Dozens of documents and spreadsheets, meetings over meetings, and yet without much impact, result in team misalignments, realized too late.

How we manage an organization defines its quality. Excellent management is crucial to avoid the Waterfall trap if we aim to build an Agile environment. But why would we want that? What’s wrong with the way we already work?

If you are already happy with how you and your team work together, that’s okay. However, what about reevaluating how you work to look for potential improvements?

I am referring to evaluating your system and how you and the people around you act within it. What worked months or years ago might differ from what we could discover today, as part of continuous improvement.

I dislike politics in the workplace, where each team looks out for themselves instead of having a bigger shared direction. This results in daily work filled with fear from above, passed down to the people below, maintaining an unhealthy working environment. Game of Thrones is great as a fictional series, but not something to deal with in daily business.

Agile was born precisely as a response to the excessive waste generated by politics and organizational micromanagement.

Controlling and “slow performance” needed a more flexible approach. When people adopt a fixed mindset, they resist change, fear failure, and prioritize rigid processes and hierarchies. This conflicts with Agile’s core ideas of embracing change, continuous delivery with iterative development, flexible planning, and fostering collaboration and innovation.

A fixed mindset leads to fear of experimentation and a reluctance to challenge the status quo, reducing progress and the potential for learning and growth.

What kills agility? #

Fixed mindset: Resistance to change, fear of failure, and prioritizing rigid processes over learning and adaptation strangle innovation and flexibility.
Excessive bureaucracy: Complex processes and excessive documentation slow down decision-making and responsiveness.
Micromanagement: Over-controlling leadership undermines team autonomy.
Lack of collaboration: Poor communication and teamwork hinder progress.
Ineffective feedback loops: Prevent adjustments and continuous improvement.
Fear of experimentation: A culture that punishes failure discourages experimentation and learning from mistakes.
Inflexible processes: Strict adherence without adapting to project needs.
Misaligned goals: Conflicting priorities reduce efficiency.
Lack of leadership’s support: Without backing from upper management, Agile initiatives can struggle to gain the necessary resources and commitment.
Poor technical practices: Neglecting technical excellence and good design can lead to a fragile codebase that is difficult to adapt and extend.

What can you do about it? #

Learn the basics of Extreme Programming (XP) and Lean Software Development.

XP: Focused on software development practices and technical excellence, with specific practices like pair programming and Test-Driven Development (TDD).
Lean: Takes a broader approach, focusing on removing waste, optimizing flow, and improving processes across the organization.

Radical Candor

2024-04-17T00:00:00+00:00

Radical Candor is a management philosophy developed by Kim Scott, a former Google leader. It’s a crash course on how to be a great manager, focusing on being empathetic and results-oriented. The core idea is to create a stress-free environment where people feel safe to speak their minds, get their jobs done, and feel respected.

Key Insights #

Command and control can hinder innovation and harm a team’s efficiency. Collaboration and innovation flourish when human relationships replace bullying and bureaucracy.
The goal of Radical Candor is to help managers and leaders achieve collaboratively what they cannot achieve individually, by caring about the people they work with.
Radical Candor is about being radically honest and open, while still being kind and respectful.

The Two Dimensions of Radical Candor #

Care Personally: This dimension involves showing genuine interest in people’s lives, well-being, and goals. It’s about being human and empathetic.
Challenge Directly: This dimension involves giving specific, timely, and actionable feedback that is both kind and clear. It’s about being straightforward and results-oriented.

Avoiding the Three Behaviors #

Obnoxious Aggression: Being overly critical or aggressive.
Ruinous Empathy: Being overly sympathetic or enabling.
Manipulative Insincerity: Being insincere or manipulative in your feedback.

Radical Candor in Action #

Give specific and sincere praise and kind and clear criticism.
Create a stress-free environment where people feel safe to speak their minds.
Focus on collaboration and innovation, rather than command and control.
Care about the people you work with and challenge them to do their best work.

By applying Radical Candor, managers and leaders can build strong relationships, motivate their teams, and achieve better results.

Effective Pair Programming

2024-03-28T00:00:00+00:00

What is pair programming? Two people working together on the same problem, at the same time.

It is not about one person showing off their skills in front of another, nor one person afraid of making mistakes due to an impostor syndrome.

Each person will have a role:

Navigator: he will pay attention to the bigger picture; eg: architecture, relation between collaborators, object design, etc.
Driver: she will pay attention to the small details; eg: naming, code conventions, writing syntax, object design, etc.

The pair could, and should, switch roles occasionally; eg: every X commits pushed, every 10 mins, … up to them.

Pair programming should not be considered a practice only for “seniors” to juniors, but regardless of the team members’ experience level.

It is about the collaboration flow, the quality communication, the absence of feeling judged, and the idea of welcoming vulnerability with your peers, knowing they will support and help you.

It is about constantly challenging each other, seeking the most pragmatic solution while keeping it simple. Always looking for quick feedback when speaking to each other, but also on the solution you agreed to implement and its direction.

It is about the short, quick, and immediate feedback loop while talking to your partner, who reviews your code on the fly. You can guide as a navigator or help the driver validate their ideas in a broader picture.

It is about the constant sharing of knowledge atmosphere by default, reducing bus-factors and silo-knowledge areas to the maximum. Increasing the focus by having two minds working on the same task simultaneously.

It is about team cohesion and sharpening the feeling that we belong. When we understand each other’s strengths and weaknesses, we will realize how much we can help each other grow.

How can you practice pair programming? #

Pair programming can be done in different ways:

You can start and finish a task with pairing. You can time-box it to 30, 60, 90 minutes. Either way, it is recommended to have pauses in the middle - Pomodoro.
You can start the task together and stop when one of your peers feels confident enough to continue alone.

It is up to the team, and the task in context, to decide when and how to apply pairing to get the best out of it.

This does not mean you must constantly work “no matter what” in pair. This is not about creating rules; on the contrary, it is about embracing this practice to the point you feel confident to choose when and how to use it to get the best out of it.

Pair programming might become one of the best tools in your team toolbox for daily interactions. Not because you read it somewhere but because of the benefits you and your team will find.

Common Patterns #

Different strategies for effective pairing #

Driver-Navigator: One person is driving the code (with the keyboard), focusing on the detail aspect of the task itself. The other is a navigator (no keyboard), having a more abstract picture of the task in mind.
Ping-Pong: Frequent switching driver-navigator roles in small interactions, e.g., every N minutes, every N commits, etc.
Backseat driver: The navigator engages actively with the driver.
Tourist guide: The navigator passively learns with the driver.

Anti-patterns while pairing #

The silent partner: The navigator is not participating, and they are being silent.
The solo act: The driver ignores all inputs from the navigator.
Distracted pair: The pair does not focus on the problem to solve.
The Dictator: One person is telling what to do, ignoring the input from the other.
Philosophical pair: The pair is bikeshedding into irrelevant topics.
The code war: The pair does not reach an agreement and starts an unnecessary war, which wastes time and effort.

Want more? Check this out: Learning Through KATAS

The takeaway #

Pairing is not a rule to enforce, it is a tool to reach for. Use it when the task is complex, the knowledge is siloed, or the stakes are high. Skip it when the work is trivial. The goal is never “always pair”, it is better software and a stronger team. Pick one real task this week, pair on it, and switch roles often. The benefits show up faster than you expect.

Great Engineering

2023-12-30T00:00:00+00:00

Coding is not just another job. Writing software can be really fun and, even more, it can be your personal hobby as well! You might be focused on coding, coding and more coding to level up your own career skills.

That itself is not bad at all! Practice makes the master, so a lot of coding will inevitably help you improve your coding skills… but there are other aspects that you need to keep in mind in order to help you grow into a great engineer.

As a software engineer, your job is not “just to write software” for its own sake, but to use software to solve actual business problems. To make that happen there are plenty of different methodologies out there, for sure. However, we must agree that you need to identify and understand your customer’s needs in order to know what to actually build.

You need to know your product, at least until certain level, so you can design your software using a similar language closer to the business, which will help its evolution and overall quality. This will be beneficial for the future (and present) maintenance of the product.

IT, Software, Product and People topics are highly interconnected, and having at least a common ground of understanding the relation between these can help the overall goal of every single individual.

The result of a great team work is not equal as the sum of the individual parts, as it’s multiplying the created value among their peers. To that, great communication skills are a key part of it in order to create as much clarity as possible from any different abstraction level.

That’s why a great engineer is a knowledgeable person about business, customer, product, and coding. Understanding these points have a strong impact on your daily work as it creates a difference between the average and the great engineer.

Image original by Nicola Ballotta.

Forming, Storming, Norming and Performing

2023-11-25T00:00:00+00:00

In 1965, psychologist Bruce Tuckman developed a model (Tuckman’s Model) that describes the stages of group development, forming and maturing into a cohesive and effective team.

The model initially consisted of four stages: “forming, storming, norming, and performing,” adding one additional “adjourning” in 1977.

It’s important to note that teams may not always progress through these stages linearly, and they might revert to a previous stage under certain circumstances.

Forming #

In this initial stage, team members are polite, tentative, and unsure about their roles. There is a reliance on the leader for guidance.

Goal: Members are getting to know each other, and there is a focus on defining the team’s purpose, goals, and roles.

Leadership approach #

Provide clear direction and guidance
Clearly define team goals, roles, and expectations
Act as a facilitator, encouraging open communication and helping team members get to know each other.

Storming #

Conflict and disagreement emerge as team members start to express their individuality. There may be power struggles and challenges to the leader’s authority.

Goal: The team clarifies its goals, members learn to resolve conflicts and address differences constructively.

Leadership approach #

Facilitate conflict resolution
Acknowledge and address conflicts constructively
Encourage open and honest communication while guiding the team through the process of understanding and appreciating diverse perspectives

Norming #

Cohesion begins to develop, and team members establish norms and values. Roles become clearer, and there is a sense of unity.

Goal: The team strives to establish norms, values, and a shared understanding. Members learn to appreciate each other’s strengths and weaknesses.

Leadership approach #

Foster collaboration and inclusivity
Encourage team members to establish norms and values collectively
Recognize and celebrate individual strengths, fostering a sense of unity and mutual respect

Performing #

The team is highly functional, with a focus on achieving its goals. Members work collaboratively, trust each other, and are mutually supportive.

Goal: The team is committed to its common purpose and operates at a high level of efficiency and effectiveness.

Leadership approach #

Empower autonomy and trust
Provide opportunities for team members to take ownership of tasks and projects
Foster an environment where individuals feel confident in their abilities and can collaborate seamlessly

Adjourning (or Mourning) #

This stage involves the completion of the task or project. Team members may experience a sense of loss as the group disbands.

Goal: Acknowledge and celebrate the team’s achievements, provide closure, and reflect on the overall experience.

Leadership approach #

Acknowledge achievements and provide closure
Recognize the team’s accomplishments and express gratitude for individual contributions
Facilitate a reflective session to capture lessons learned and create a positive closure experience

To develop a team to a high-performance level using Tuckman’s Model, leaders should be aware of the stages and adapt their leadership style accordingly.

This involves providing guidance and structure during the forming stage, facilitating conflict resolution during storming, fostering collaboration and communication during norming, empowering autonomy during performing, and recognizing achievements during adjourning.

Regular communication, team-building activities, and constructively addressing conflicts are crucial throughout the process.

Video summary #

Crucial Conversations

2023-10-31T00:00:00+00:00

When stakes are high, opinions vary, and emotions run strong, you have three choices: Avoid a crucial conversation and suffer the consequences; handle the conversation badly and suffer the consequences; or read Crucial Conversations and discover how to communicate best when it matters most.

If you don’t talk it out, then you’ll act it out.

Chapters #

Know your heart
Ensure safety
Beware of reverting to your style under stress
Make the content safe
Control your emotions
Share your stories
Move from conversation to results

Key takeaways #

A crucial conversation is a confrontation you need to handle with care, which usually is characterized by three factors:

Stakes are high
Opinions vary
The parties involved have strong emotions

Examples:

Calling a client who didn’t pay their invoices
Talk to your boss about a promised promotion that is being delayed
Confronting a teammate who is not doing their share of the project
Talking to your siblings about your parent’s inheritance

Navigating through a crucial conversation is like defusing a bomb. Touch the wrong button or hit the wrong wire, and you create an explosion of emotions. The key is to have an honest and productive dialog to work out the situation.

These are unplanned conversations, and we tend to avoid them because we believe that we are going to make it worse. We tend to react negatively because we are humans, and human beings “behave their worst at the most critical moments.”

The “Story” #

Everybody walks into a crucial conversation with a story. Examples:

My mate doesn’t care about the project because they don’t come to the meetings
My boss doesn’t care about my career because they haven’t given me a promotion

If you approach a crucial conversation with a story in mind, there is no room for dialog, because your mind already made it up.

When… I… framework #

To create the space for a dialog, you need to start assuming you don’t know the whole story, and that you need the help of the person you are talking to. You can use: When... I... Example:

When [you don’t show up to team meetings], I [fear you don’t care about this project].

Invite them to share their own When...I..., so you can discover together what might be the issue, misunderstanding, or misalignment between you two.

The key is to avoid being passive/aggressive, but rather assertive, and honest with facts. This will help reduce the chance of being defensive and willing to help clarify the situation.

Common goal #

To avoid a confronting hit and get back to a productive dialog, you need to convince the person you’re talking to that you’re not their opponent or enemy, you are on the same side. To do this, you must communicate a common goal, value, or purpose.

I don’t want to fight. I just want to find a way for both of us to get [common goal/purpose].

I know we both care about [common value], let’s see if we can both get what we want.

Make a good-faith guess. The more you engage in productive dialog, the more chance you have to find agreements, and the more luckily you will work together to resolve the problem at the heart of a crucial conversation.

Keynote: Mastering The Art of Crucial Conversations #

Video Summary #

Unhealthy Working Environment

2023-10-11T00:00:00+00:00

An unhealthy working environment can have various symptoms that negatively impact employees’ physical and mental well-being.

While writing about The Peter Principle, I mentioned: “Talk to each other. If you feel you can’t, that’s a symptom of a non-healthy working environment, and that’s something more significant to deal with.” But what are those symptoms?

Symptoms #

From all possible symptoms, these are the ones that I would highlight: High stress, poor communication, lack of recognition, micromanagement, lack of work-life balance, unfair treatment, lack of growth opportunities, unhealthy conflicts among colleagues, lack of clear goals and expectations, high turnover rates, low morale and motivation, and constant physical or emotional tiredness.

Let’s go one by one.

High stress #

Excessive stress and pressure. This can be due to heavy workloads, unrealistic expectations, or a lack of support.

Poor communication #

Ineffective communication, whether it’s between colleagues, teams, or between management and employees, can lead to misunderstandings, frustration, and unhealthy conflicts.

Lack of recognition #

When employees feel that their efforts are not acknowledged or rewarded, it can lead to feelings of demotivation and reduced job satisfaction.

Micromanagement #

Overly controlling management styles can stifle creativity and autonomy, leading to frustration and decreased job satisfaction.

Lack of work-life balance #

A healthy work-life balance is essential for employee well-being. Long working hours, excessive overtime, or unrealistic expectations can lead to burnout and reduced productivity.

Unfair treatment #

Discrimination, favoritism, or unequal opportunities can create a toxic and divisive atmosphere among employees.

Lack of growth opportunities #

When employees feel that there is no room for advancement or professional growth, they may become disengaged and unfulfilled in their roles.

Unhealthy conflicts among colleagues #

Constant disagreements, conflicts, or a hostile atmosphere among colleagues can create a toxic working environment.

Lack of clear goals and expectations #

Employees need clear guidance on their roles, responsibilities, and performance expectations. Unclear or constantly changing goals can lead to confusion and frustration.

High turnover rates #

If there is a constant stream of employees leaving the company, it may be a sign that the working environment is not conducive to long-term employment.

Low morale and motivation #

When employees are consistently demotivated or have low morale, it can lead to decreased productivity and a negative atmosphere.

Constant physical or emotional tiredness #

Prolonged exposure to a non-healthy work environment can lead to physical and emotional exhaustion or even mental health issues.

It’s important to note that these symptoms can vary from one workplace to another. Addressing these issues promptly and effectively is crucial to create a healthy and productive environment.

What can you do about it? #

Yourself #

Embrace the change Who moved my cheese?
The process itself is the goal How to focus and have self-discipline
Have you always been like this? How to find a balance of growth and happiness

Your managers and leaders #

Great leadership Leadership starts within your own life and behaviour
Understanding people Misunderstandings, effective communication, and self-reflection

It's Your Ship

2023-09-20T00:00:00+00:00

“It’s Your Ship” is a leadership book written by D. Michael Abrashoff, a former commander of the USS Benfold, a guided missile destroyer. The book focuses on Abrashoff’s experiences and the leadership principles he applied to transform the performance and culture of his ship.

Key takeaways #

Empowerment: Abrashoff emphasizes the importance of empowering team members. He believes that when people feel trusted and empowered, they take ownership of their work and perform at a higher level.
Listen and Communicate: He highlights the significance of active listening and open communication. He made an effort to listen to his crew members, seek their input, and address their concerns. This helped build trust and fostered a culture of open dialogue.
Lead by Example: Leaders should set the standard through their own actions. He worked hard to be a positive role model for his crew, demonstrating the behavior and work ethic he expected from them.
Delegate Responsibility: Abrashoff encourages leaders to delegate authority and responsibility. By giving his crew members more control over their areas of expertise, he allowed them to take ownership of their roles.
Foster a Culture of Innovation: Abrashoff promoted a culture of continuous improvement and innovation. He encouraged his crew to suggest and implement changes that would enhance efficiency and effectiveness.
Celebrate Achievements: It is important to recognize and celebrate the achievements and contributions of team members. This recognition serves as positive reinforcement and motivates individuals to continue performing at a high level.
Take Calculated Risks: Abrashoff was not afraid to take calculated risks in order to achieve better results. He was willing to challenge established procedures and norms when he believed it would lead to improvements.
Build Trust and Respect: Trust and respect are foundational elements of effective leadership. Abrashoff worked to build strong relationships with his crew members, which created a sense of camaraderie and mutual trust.
Adaptability and Flexibility: In a rapidly changing environment, leaders need to be adaptable and flexible. Being able to adjust to new circumstances and make quick decisions is crucial for success.
Continuous Learning and Improvement: A mindset of continuous learning and improvement is crucial. He encouraged his crew to seek out opportunities for professional development and to always strive for excellence.

Overall, “It’s Your Ship” provides valuable insights into leadership principles that can be applied in various organizational settings.

Abrashoff’s approach emphasizes the importance of empowering and valuing team members, fostering open communication, and constantly seeking ways to improve performance.

How Do You Get Everyone on Board?

2023-08-02T00:00:00+00:00

I was invited to the WeAreDevelopers World Congress to give a tech talk about my experience with XP and the profound benefits of embracing change in your work and life.

With more than 12k attendees, 300 speakers, and ~10 tracks in parallel, I was invited to give not one but two talks. One is about my experience with Extreme Programming and the profound benefits of embracing change in your work and life.

I especially enjoyed the audience engagement and feedback they gave me after each talk. In particular, a question I had faced many times during my career: “How do you deal with people reluctant to change?”

This is one of the most complex topics affecting any team, regardless of their profession. But, especially in our constantly changing software industry, if you are reluctant to embrace change, you will do more harm than good to your team, career, and yourself.

As stated in Peopleware, “our software profession is less about computers and more about humans and their interactions”. This is usually the root problem for people; it’s a human problem first.

To become truly agile, you must have a good foundation of trust among your peers. Without trust, there is no team, and the primary responsibility of a good leader is to help create a trusted environment without fear of healthy conflicts. Everyone feels they can speak and express freely in a safe environment.

A safe environment means you don’t need to carry on armor the whole day to protect yourself from others, so you will have more energy to drive excellence in your workplace.

But still, despite your effort to create a trustable and safe environment, you might encounter people reluctant to change. For those, you might need to try different approaches. How can you help create trust among everyone?

Don’t be afraid of failure; instead, think that everything you do is an experiment from which you will learn something. And anything that brings you closer to a better state is better than nothing.

The key here is to find a way to connect with people by understanding how they understand their potential so you can empower them and help them grow.

Grant time for reading #

1:1 meetings are ideal for establishing personal connections with your peers. However, you might feel that the situation requires an additional push, especially if you have someone who doesn’t like to speak about themselves, and it is hard to know what they think about what’s happening.

Here is an idea you could try:

Give them a book containing ideas or knowledge that could benefit the whole.
Allow reading this book during work time, eg: on Fridays after lunch. This is a company investment for the development of your team.
The book should be read in 3-4 hours, or a couple of Fridays, depending on the number of pages.
Don’t wait until the book is finished to talk about it. Follow the progress.
You will have great topics to discuss during your next 1:1.

You could use any book for this exercise #

Any book would be fine. Still, if you are looking for great examples, these are my favourite three to start thriving a conversation:

Who moved my cheese? is a metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change.
Extreme Programming Explained contains a compilation of values, principles, and practices highly related to the human touch in our software industry. Focusing on the team aspect, collaboration with your peers, and creating a sense of mastery and purpose in our craft.
Start with Why addresses the importance of starting with “Why?” in order to define a purpose for anything we do.

Experiment with any book, timeframe, person, or group to create a shared understanding of the team’s foundational values and motivations. The goal is to engage in active knowledge-sharing while cultivating a team that feels they belong, fostering passion at work. This will help create trust, and you can start building on top of it.

If you are looking for books to help scale up your leadership skills, there you go: “Great Leadership”.

You cannot force people to change. On the contrary, the more you try to force it, the harder they will make it for you. Instead, focus on understanding them by acknowledging what they feel and thinking about what they do to create a common ground of understanding each other.

Photos from me at WeAreDevelopers World Congress, Berlin 2023.

Agile Project Management

2023-05-31T00:00:00+00:00

A basic and straightforward overview of what Agile is, presenting some framework examples that are well known today, such as Scrum or Kanban, everything condensed in a 100’s pages book that you can read in a couple of hours.

Chapters #

The fluid manifesto
Being agile
Agile process
Planning for success
Agile communication
Scrum basics
Introduction to Kanban
Building an adaptive team
Leadership and collaborative management
Common errors behind agile failure
Final words: agile is adaptation

“The benefits of Agile projects extend no only to the team using it, but also to the customer receiving the final product.”

“There is an underlying critical metric that consistently leads to the success of an Agile project: communication. Miscommunication, under-communication, or poor communication of any type leads to the collapse and failure of said project.”

Key takeaways #

Projects that followed a Waterfall methodology tended to exceed their expenses over time, while the product delivered was below standard and difficult to use.

That situation originated that a group of developers signed a brief, 68-word manifesto in 2001.

A brief background #

During the 1960s, software got into a big crisis; creating software was complex but changing it later became pure chaos. Waterfall to the rescue.

Waterfall outlined a simple, logical set of processes that a company would need to follow for a project to be successful. Its name comes from the metaphor of water gently cascading down a predictable, steady, incremental stream. Its life cycle of software development would be in six simple steps.

Requirements
Analysis
Design
Code
Testing
Operations

For 10 years, Waterfall was the standard methodology in the software universe. And for 10 more years, chaos persisted. Although the intention was good, the reality is that the ever-changing set of constraints does not cope very well with this methodology because each step is dependent on the previous one.

86% of the time a company uses the Waterfall method for project management, the customer receives inadequate or useless software. A lot of software projects were unused or never finished.

During the 70’ and 80’, Iterations and Incremental Development (IID) proved to be a viable option. In the 90’ surges an Evolutionary Delivery (ED), which changes the situation. The developer is responsible for listening to the user’s reactions early and often. The user starts playing a direct role in the development process.

A few years later, a new method surged Rapid Iterative Production Prototyping (RIPP), later called Rapid Application Development (RAD), which they claimed “Working software in 90 days… or your money back.”

Lastly, during the 90’ Extreme Programming (XP), Scrum, and Crystal were defined in detail.

These distinct yet similar solutions were decentralized, working independently of one another. This realization led to that night in Utag the unification of these ideas under one banner, in one document.

Agile became the definitive standard for software development.

The Agile Manifesto #

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the rights, we value the items on the left more.

Effective Remote Work

2023-04-17T00:00:00+00:00

An effective remote work environment is about treating everyone as remote, with everyone in mind having the same level, equality, and information.

Part 1 - Getting oriented for remote work #

It covers the foundation for a possible remote work environment. It seems a bit common sense nowadays, especially after the covid hit, where we had no choice but to work remotely for more than a year. But I think it’s still good to see this foundational knowledge written to polish assumptions in the following chapters of the book.

Chapters #

A remote future: A brief history of the future. Lockdown. Remote is here to stay. Time to get set up.
Getting set up: The office: what we want and what we don’t. The basics, briefly. In the real world. Installing mental scaffolding. The golden rule.

Part 2 - Building effective remote teams #

Most likely, we all had the experience of casual remote work (before remote work was even a trend) when we felt that we were apart from the team dynamics when we were doing remote work for some reason. This is precisely why “treat everyone as remote” is so important - when at least one person works remotely.

There are different ways to communicate depending on the urgency, intention, and how long and easy that message should be accessible. It’s about sync/async communication with our peers.

Highly related to the previous paragraph, the quality of our messages should be considered when aiming for effective communication. We need to consider the right tools. A phone call is different from a chat message or an email. Use the right tools for the right messages within the proper context.

Chapters #

Treat everyone as remote: Out of sight, out of mind. A principle for cultural change. Taking practical action. Let’s build a model!
The spectrum of synchronousness: Synchronousness. Permanence. Restoring your humanity. Onward to Hyrule.
The same but different: A normal day in the office. Through the magic mirror. Conquering the dark world. Let’s discover some artifacts.
Artifacts for a better future: Comparing artifacts. Written artifacts. Codebase and recorded artifacts. Getting on board with onboarding.
Onboarding and orientation: The contribution curve. The onboarding equation. And here’s the trick. Considering communication.
Effective communication techniques: Why humans communicate. Principles for better remote communication. Techniques to improve interactions. The right tools and when to use them. Turning inwards.
Managing yourself: An organizational bedrock. On being unobserved. Riding peaks and troughs. From yourself to teams.
Managing teams: The output equation revisited. Shrinking the scale factor. Supercharging the scale factor. Time to take it up a level.

Part 3 - Creating a world-class remote culture #

Even though a fully remote company might not be possible for some reasons out of our control, if the company claims to be remote-friendly, there are some aspects that we can consider:

Do you treat everyone as remote?
Do you provide a remote work-space setup?
Do you spend money equally on in-office and remote staff?
Do you optimize for asynchronous communication?
Do you create artifacts from synchronous interactions?
Do you measure staff by their impact?
Do you allow staff to choose flexible hours?
Are the members of the executive team remote workers?
Do you use the best collaborative tools that money can buy?
Do you hire staff anywhere in the world?
Do you support families as well as employees?
Do you give back to an employee’s local community?

This is a “Joel Test version for a remote working environment”. The Joel Test originated in the year 2000, during the dot-com bubble; a test to rate the quality of teams with “yes/no” questions. If a team can answer each question wit a yes, they’re likely a productive team. Read more about the original Joel Test.

Chapters #

The remote working test: The joel test. Twelve questions about remote working. Making changes in your company. Something to guide us.
Creating a handbook: The GitLab handbook. Creating a handbook for your team. A handbook for the company. Fully making the shift.
Becoming fully remote: The spectrum of remoteness. The challenge of retrofitting fully remote culture. The triangle of transition. Learning from trailblazers. Now the difficult stuff.
The hard parts: Walking the curves. The physical and mental impact of working remotely. Supporting other remotely.
The path to equality is remote: Diversity and inclusion. Remote: The great leveler. This is just the beginning.

Book summary #

Introducing a New Tech Stack

2023-04-14T00:00:00+00:00

To introduce a new tech stack for the entire team, it’s important to bring “why?” and a strategy to make it happen among the team because it will affect everyone.

Why that new tech stack? #

To decide whether to use a new tech stack or not, remember that it is a team decision, according to the standardization and maintainability of the project when introducing such a new tech stack. But, most importantly, what problem do you want to solve by introducing it? Is it because it is “cool”? Or is there an actual “necessity” that this tech helps you with?

The direction of the technology #

When proposing adopting a new library, framework, or entire new technology, an important aspect to consider is to be aware of its background and the direction where they are moving forward.

What is the motivation for that tech, and why are you considering introducing it in your current stack?

Coupling and dependencies #

When adopting new technologies in our daily business, it’s not rare that we tend to couple ourselves with them. This makes it harder later to roll back if, after a while, we regret that decision.

Don’t get me wrong, learning and experimenting with new technologies is great, but introducing it in your daily work is another story because it will affect the whole team. So we need to be more careful with this.

The focus of the conversation #

What does this new tech contribute to the project?
What problem do we want to solve by introducing it?
Can we solve that problem with our current tech?
If we already have a similar tech, do we want to have a mix of both?
What are the tradeoffs when using it vs. not using it?
Is it worth the incremental complexity over time?
What is the team strategy to onboard everyone if we aim to use it?

Architectural Decision Records (ADRs) #

Whatever the outcome, you should write it down as an ADR to revisit it as time passes. An ADR will record your team’s decisions regarding the pros and cons, among any other arguments you have found together, to decide what to do and why.

ADRs are useful to understand old decisions and keep them in the version control, in the same project if possible. They are helpful for the current team, but also for new joiners.

Great Leadership

2023-02-27T00:00:00+00:00

As business scales, the leaders’ primary focus must shift from customers to employees. Therefore, I would like to share what I consider critical points that any leader should address and focus on regularly.

For each key point, you will have book recommendations that go deeper into the matter, giving you references from real experts behind them.

I already wrote about the beauty of leadership, and as a quick recap, to become a leader, you need specific skills:

Excellent communication, giving support, and enabling your people
Leading by example, especially to become a better self
Passion for sharing your leadership skills, so you build other leaders

To extend the previous post providing resources and examples, in this one, you will find books about the following topics:

Motivation
Leading through change
Empowering your people
Effective communication
Persuasion
Team dysfunctions
Management principles
CEO Mindset
Engineering leadership

For “starting” leaders #

Motivation #

First of all, you need to define a purpose for your leadership. I would recommend “Start with Why”, as this can help you clarify the difference between great leaders and those who are not.

“The ability to inspire those around you and to achieve remarkable things starts with WHY.” - Start with Why

You need to be aware that leadership is not about being the boss of anyone but serving others. It would help if you were a role example that your people would copy and follow, especially in hard times. This is a leadership philosophy in which the leader aims to serve. “Leaders Eat Last” goes deeper into this topic.

After reading the previous two books, if you are looking for more, the cherry on top is “The infinite game”, which is the third and last book (so far) by Simon Sinek. This book questions our daily mindset when confronting (business) problems. It’s about the need of a just cause, courageous leadership, trusting teams, and a worthy rival.

“There is no such thing as the one “right” organization. There are only organizations, each of which has distinct strengths, distinct limitations, and specific applications. An organization is not absolute. It is a tool for making people productive in working together.“ - The infinite game

Leading through change #

Leading through change is something you have to face in many moments in your life, whether you like it or not. “Who moved my cheese?” is a tale about the different attitudes people adopt as part of their identity when confronting change.

How do you eliminate bad habits and start creating good ones? “The Power of Habit” and “Atomic Habits” are great books that help you understand that habits are like a muscle. You can train them.

“Change how you identify yourself. The environment is more important than being motivated. Reduce friction for good habits and increase friction for bad habits.” - Atomic Habits

Empowering your people #

It would be best if you empowered your people to become leaders themselves. A great book I recommend is “Turn the ship around!”, in which the author challenges the commonly accepted leaders vs. followers model into a leaders-to-leaders relationship.

“Leadership is communicating to people their worth so clearly that they are inspired to see it in themselves.” - Turn the ship around!

Effective communication #

Communication is one of the most challenging skills you need because you constantly communicate with other people; with different backgrounds, experiences, expectations, and even understanding of life. And the important key aspect is not just what you say but how you say it to ensure your desired message is correctly delivered to the receiver.

“Leadership is Language” challenges the industrial-age playbook (where leaders give commands and employees follow them), giving you strategies that can help you such as: control the clock, collaborate, commit, complete, and improve.

“Your words matter more than you think.” - Leadership is Language

It is important to recognize our emotions and not let them control our actions. Creating an open, honest, and safe environment is crucial to create trust among your peers.

“Dare to lead” addresses that leaders need to be more vulnerable. It shows that solid values guide you to do what is correct rather than easy. The importance of trust and difficult conversations even when they make you uncomfortable.

“Great leaders must be brave and always dare to provide constructive feedback, speak the truth, and be clear about their expectations.” - Dare to lead

Persuasion #

Regarding communication, you might need some good persuasion skills to convince others about your ideas. “Never split the difference” is a book about negotiation (from one FBI’s lead international kidnapping negotiator) that gives you great insides into how to negotiate effectively: negotiation begins with listening, using mirrors to encourage the other side to empathise, tactical empathy to getting an agreement, labelling emotions, among others.

“Negotiation begins with listening, making it about the other people, validating their emotions, and creating enough trust and safety for a real conversation to begin.” - Never split the difference

For “experienced” leaders #

Assuming you have read the books above (for “starting leaders”) I can give you more recommendations.

Team dysfunctions #

One of the most difficult areas from the communication layer is dealing effectively with conflicts; so “The Five Dysfunctions of a Team” is a great book which addresses the “absence of trust, fear of conflict, lack of commitment, avoidance of accountability and inattention to results” as a pyramid of dysfunctions that you need to pay attention.

Management principles #

Although leadership is not the same as management, I find it quite useful knowing some theory behind management, and for this “High Output Management” is a great starting point.

After that one, if you want more, I can recommend something more advance with “The Essential Drucker”, which addresses the essential principles of management.

“Management is about humans.” - The Essential Drucker

CEO Mindset #

Although not every leader might want to be a CEO, I find “The Great CEO Within” a great book because this can help you understand the responsibilities from any organization’s most abstract point of view.

Similarly, “Adapt or Die” is a great book that covers the fundamental aspects of overall responsibilities and capabilities to thrive in any business, addressing aspects such as Product, Strategy, Growth Engine, Financial Model, People, Operations, Process, and Leadership.

“Leadership is about helping people adapt and leading through change so the business and its people can thrive.” - Adapt or die

Engineering leadership #

Related to engineering and growing, I also recommend “The Manager Path”, and “The Art of Leadership”, both great books; easy to read and full of wisdom.

“Managers tell you where you are; leaders tell you where you are going.” - The Art of Leadership

I hope I got enough attention to create awareness about the key areas you must work on. I am aware that many other books could be included in this list. You might have others on your shelf. These are just a reference, not necessarily better or worse than others.

I still have many other books I want/will read over time. Still, I thought it would be interesting to compile these already, aiming to create value, sharing especially for those who don’t know where to start or how to become better leaders themselves.

However, these are the essential points to remember:

You need to have passion for your work and share this passion with the people around you. You cannot expect passion from your peers if you don’t have passion for what you do.
You need to empower your people, creating leaders instead of folks who follow orders from their superiors.
You need to learn how to create a safe environment, which is crucial for trust and honest relationships.
You need to help create agreements when dealing with conflict resolutions. Avoiding healthy conflicts doesn’t help long-term relationships.
You have to look for opportunities to grow everywhere and help our team grow with you.

Your primary responsibility is to help others improve, and this is only possible if you embrace the change and start with yourself.

All mentioned authors #

Simon Sinek: Start with Why, Leaders Eat Last, The infinite game
Spencer Johnson: Who moved my cheese?
Charles Duhigg: The Power of Habit
James Clear: Atomic Habits
L. David Marquet: Turn the ship around!, Leadership is Language
Brené Brown: Dare to lead
Chris Voss: Never split the difference
Patrick M. Lencioni: The Five Dysfunctions of a Team
Andrew S. Grove: High Output Management
Peter F. Drucker: The Essential Drucker
Matt Mochary: The Great CEO Within
Thomas H. Douglas: Adapt or Die
Camille Fournier: The Manager Path
Michael Lopp: The Art of Leadership

Extra: Leadership Guide for the Reluctant Leader #

Especially if you are a software developer, this video is for you.

“Leadership is for everybody. It is for all y’all.”

Adapt or die

2023-02-26T00:00:00+00:00

Told through the story of one bold company (People First IT), Adapt or Die takes readers through the unparalleled business system known as The Algorithm of Success that has the potential to inspire, ignite, and affect change for all aspects of an organization.

Each chapter reveals more of the winning formula that all small and midsize businesses absolutely must have to succeed. Through real examples, research, and practical tools, Adapt or Die unpacks exactly how to create innovation, solve people puzzles, and win in business.

“Leadership is about helping people adapt and leading through change so the business and its people can thrive.”

Why businesses fail? #

Businesses fail because they…

are unable or unwilling to have courageous conversations
focus on money too much or too soon instead of on people
can provide the value themselves but can’t make it scale
fail to focus on people as their primary responsibility
focus on people, but don’t have the necessary skills to make a difference
listen to respond instead of listening to hear
think that because their idea is unique and specific, so are their issues
live in the business and fail to spend time on the business
expect thing to happen without truly leading through change
fail to fall in love with the truth and fight the truth instead

How to help growing your teamwork #

“As a business scales, the primary focus of the owner and the leadership must shift from focusing on customers to focusing on employees.”

By having courageous conversions about the full spectrum of skills required to go to the next level, focusing on improving the personal and professional career experience for that person and the people around them.

These are the main points that everyone could develop:

Good communications
Focus & achieve goals & results
Everyone contributes
Offer each other support
Good leadership
Clear and good organization
Constructive conflict drives innovation

“People is not usually the root problem. The taxonomy is 3Ps: product, process, or people. And “people” is the final step because leaders need to look at product and process first. In other words, “people first” when it comes to values, but “people last” when it comes to blame.“

The Algorithm of Success #

As you can see in the diagram, all of this comes under leadership. If leadership is about helping others adapt to change, then it must be core to our organizations.

Product #

Promises
Solve a problem or need
Cash release triggers
The way we create value
Pain or Pleasure
Innovation
Connections: Logical, emotional and competitive

Strategy #

Target customer profile (Who)
Value Creation Strategy (VCS)
Core Values
Shared vision
Value loop
Key processes

The Growth Engine #

Unique selling proposition
Targeted marketing
Sales channels
Sales steps
Measuring the Growth Engine
Funnel & opportunity management
Return on Sales

The Financial Model #

Revenue management
Cost of goods sold (COGS)
Sales and marketing costs
General administration
EBITDA, ITDA, NOI
Categorization
Reporting

People #

Alignment
People elevators
Problem solving
People banks
Leadership code of conduct
Career plans
One-on-one’s
Income managements

Operations #

Identify the core operations
Responsibilities
Cadence management
Meetings
GSD (Get Shit Done)

Process #

Promises Kept
Downstream / Upstream
Accountability
Repeatable
Efficiencies

You can find the book in https://www.adaptordie.com/the-book/.

The infinite game

2023-01-29T00:00:00+00:00

How do we win a game that has no end? Finite games, like football or chess, have known players, fixed rules and a clear endpoint. The winners and losers are easily identified. Infinite games, games with no finish line, like business or politics, or life itself, have players who come and go. The rules of an infinite game are changeable while infinite games have no defined endpoint. There are no winners or losers: only ahead and behind.

Infinite-minded leaders understand that “best” is not a permanent state. Instead, they strive to be “better”. “Better” suggests a journey of constant improvement and makes us feel like we are being invited to contribute our talents and energies to make progress in that journey.

The question is, how do we play to succeed in the game we’re in? In this book, Simon Sinek offers a framework for leading with an infinite mindset:

Just Cause
Courageous leadership
Trusting teams
Worthy rival

#1 You have to have a Just Cause #

A Just Cause is the answer of Why your organization exists?

A cause so just that people will be willing to sacrifice themselves to see the advancement of that cause. Eg: working more hours, giving your best ideas, or rejecting another job offer and staying here because you believe in what you are doing.

In order to be happy, we need a sense of purpose or meaning; businesses are no different. When we look at developing a Just Cause, there are a few things that we need to articulate. Firstly, we must stand for something that’s inclusive, and exists primarily for the benefit of others.

In short, a Just Cause is a vision of a compelling future, making people want to be part of building this future, although they may never see it completed.

#2 You have to have courageous leadership #

Courageous leaders are the ones that are willing to sacrifice the sort term in order to advance the long term.

Leadership is the acceptance of the responsibility to create an environment in which people can work on their natural best.

The senior most people in an organisation are not responsible for the result. They are responsible for the people that are responsible for the result.

#3 You have to have trusting teams #

A trusting team is an environment in which people feel safe to raise their hand and say “I made a mistake. I don’t feel qualify to do the job you asked me to do, and I need more training. I need help. I am scared.” Without any fear of humiliation or punishment, whatsoever.

If you don’t have trusting teams, you have a group of people that work together lying and faking, and you’re forcing them to. It’s not their fault. You’re creating an environment in which people will not share mistakes because they think it will make them in trouble. Which means eventually things will compound and break.

It’s the responsibility of the leader to get the environment right. Get the environment right, you’ll get trusted teams. Get the environment wrong, you are forcing people to protect themselves from you.

#4 You have to have a worthy rival #

Although the only true competitor in an infinite game is yourself, what competition does is help to reveal your weaknesses.

The goal is not to be number one in the infinite game, because there is no such thing. It’s about building a strong foundation. It’s about looking long term.

Money is a result, not a purpose.

There is no such thing as the one “right” organization. There are only organizations, each of which has distinct strengths, distinct limitations, and specific applications. An organization is not absolute. It is a tool for making people productive in working together.

Leaders who embrace an infinite mindset build stronger, more innovative, more inspiring organizations. Ultimately, they are the ones who lead us into the future.

Interview About XP and Agile

2023-01-09T00:00:00+00:00

My interview with devm.io regarding Agile and Extreme Programming.

devm.io: We talked to Chema, a software developer and an Extreme Programming expert, about his favourite topic and his upcoming live event Update Your Team To Be More Extreme.

Could you tell us a little about yourself, who you are, and what you do? #

Chema: My name is Jose Maria Valera Reales, but everyone calls me Chema. I’m originally from Spain but have lived in Berlin since 2015. I’ve been working as a software developer since 2013. In recent years, I have focused on achieving excellence and figuring out how to help my peers and, with them, the entire software community to improve in our profession.

I am currently a Tech Lead at Lautsprecher Teufel GmbH, where I work with the e-commerce webshop team. I also enjoy open-source software, so I enjoy creating pull requests for other repositories, and I also love when I receive pull requests from others.

How would you describe Extreme Programming? What makes it so “extreme?” #

Extreme Programming is the most straightforward and pragmatic approach to embracing Agile in your software team. It incorporates solutions based on values, principles, and practices. You don’t have to use or do everything, but rather whatever fits you and your team in your context. However, these are helpful general solutions that work better when combined.

From my experience, the word “extreme” can be misleading, but I see it as an opportunity to emphasise the difficulty of the fundamentals behind it. The critical point is realising that our “common sense” is not as “common” as we tend to think, nor the best practices for practical teamwork. Therefore, this is about pushing ourselves to extreme effectiveness, collaboration, and satisfaction while working with others.

You will host a live event on devm.io on the topic on January 19th. Could you give us a sneak peek of what your audience can expect? #

We will explore how a software team works nowadays, the common issues we encounter, and what solutions we could apply to improve our team routines. We will look for the real meaning of Agile, focusing on Extreme Programming ideas.

In addition, I will share some ideas to help your team create learning opportunities with concrete examples that any team can incorporate into their current work.

During the event, you will also tell us something about Katas. What exactly are Katas? #

The term “kata” comes from the repetitive movements done in karate that help you improve your fighting skills.

Why “code katas?” Because as a group, we need to practice more. Most of our learning takes place on the job, so most of our mistakes are also made there. And because we want to keep PROD, we’re reluctant to try new things.

Katas exist to help developers get the same benefits you would get from practice in any other profession. These simple, simulation exercises let you experiment and learn without the pressure of PROD. There are no right or wrong answers in any software kata: the benefit comes from the process, not the result.

There are katas to help you improve your refactoring skills (such as Gilded Rose Refactoring Kata by Emily Bache) or your testing skills (easy ones like Fizz Buzz or Roman Numerals, or more advanced ones like the Bank Kata by Sandro Mancuso). They’re also great for building confidence when programming with others, watching and practising different roles collaboratively, fostering team cohesion, etc.

What role do Agile methods play in software development for you? #

The very first question here is to define what Agile methods are. In the end, everyone communicates somehow, provides feedback to others, and simplifies to some level. Sometimes people have the courage to speak their minds and sometimes they do not, and usually, they try to respect their peers. So, for me, Agile is more about “how” you do certain things rather than “what” things you do.

Agile is a highly collaborative working process at any level, which might have a challenging learning curve at the beginning, but it pays off sooner than you might expect.

Which topic in the area of agile should receive more attention? #

Team building and embracing agility, starting with asking “why?” We need to challenge the status quo more often and ask ourselves why we work the way we do and how and what we could do differently to keep improving and never stop learning.

You can also read the interview from the original link: https://devm.io/agile/extreme-programming-agile.

Ignoring Scrum to Get More Agile?

2022-12-06T00:00:00+00:00

Talking to a friend about agile, he asked me a fascinating question remarking how badly sometimes Agile and Scrum fit together, especially regarding meetings. These are my thoughts about this topic.

“Do you think it would make sense to just use agile and ignore scrum (sprints) completely in a product based development company. I feel it’s hard to be agile when you have 10 hours of meetings per week.” Filip G.

That is related to the essence core of Extreme Programming, which is the first value: Effective Communication.

“Probably some companies just don’t know how to properly use meetings and just have them out of habit.” Filip G.

I wouldn’t say completely ignore Scrum. Scrum (when done well) is a great “Product Management” Framework. To improve your understanding of Scrum I recommend reading: Scrum: The Art of Doing Twice the Work in Half the Time.

The main issue with scrum nowadays is that management took control over the whole thing, and developers are not really educated about how to practice Scrum properly (in a real Agile way), and that’s where the problem starts. For this, I recommend a book that addresses pretty well the common issues that most Scrum teams face in a fun and easy-reading book Zombie Scrum Survival Guide: A Journey to Recovery.

It’s not about Agile yes, and Scrum no. They are totally compatible. The issue is to create awareness about how to focus the team processes from an agile point of view.

Agile in a nutshell #

I recently wrote a blog post about agile fundamentals, which I recommend you to read to get into the details: Working agile with non-agile teams. But, the tl;dr: Agile is about quick feedback. It’s about effective communication and reducing waste while aiming for simplicity.

Agile is about keeping these values always present:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

While there is value in the items on the right, we value the items on the left more.

Scrum in a nutshell #

Scrum is a framework for project management emphasizing software development, although it is used in other fields like sales, marketing, and more. It’s designed for teams of 5 to 9 people (see Dunbar number) who are totally autonomous and responsible for breaking down their work into small chunks that can be completed in a time-boxed iteration, called sprints, usually 1, 2, or 4 weeks.

It’s common to find certain ceremonies/meetings like:

Stand-up: 15 min (or less) to keep everyone in the team sync and updated about the work and call out for action when anyone is blocked or needs special attention or help.
Refinement: 2h? meeting to make sure the tickets are in a good shape before planning them to be worked on in the next sprint.
Planning: 2h? meeting to plan the work to be done in the next sprint.
Demo/Review: 2h? meeting to show the work done for the whole team, stakeholders and other interested people.
Retrospective: 2h? meeting intended to enable the team to reflect and improve.

The critical question is how your team organizes these meetings and, most important of all, how effective these are. These above are just some of the important meetings you have in any “Scrum Team” nowadays.

Still, apart from those, you might encounter a lot of additional meetings that pile up, and suddenly your entire working day is gone, and you feel you didn’t produce the value you expected. Unless your job is being in meetings every time, like coordinating projects and talking to people all the time, it seems something is wrong.

Boring meetings #

Have you ever been in any of those meetings and thought, “This is boring, what a waste of time…”. Well, I’ve experienced that more than once. Who’s to blame? That would be the very first question that could come to your mind. Followed by, “My boss, obviously, because he/she organized that meeting, to which I got invited, therefore I am forced to attend, and this wasting time is their fault.”

This is a tricky question, and I don’t think it is an honest answer. However, there is an easy explanation for this answer: pushing away responsibilities and blaming others rather than yourself is way easier.

“I am forced to attend, and this wasting time is their fault” it could be that that’s actually the actual fact. You were really forced, and you’re wasting your time, and there is no other way… but is there no way to act on it, really?

When something doesn’t work the way I expect (e.g., I don’t like the outcome, or I think something is off), before blaming and pushing away responsibilities to others, I want to reflect on it and identify the root of the issue. What could I do to make the situation better?

What can you do about it? #

Coming back to this context of “many meetings”, if you see yourself in a meeting again that feels off or boring, try asking yourself:

Am I feeling bored? Why so? Is it possible that I am not participating in the desired outcome of the meeting? And if so, is my presence here in this meeting really necessary? Could I simply ask for a summary afterward and jump outside the meeting to do something more productive?

Contrarily, is it OK to feel bored in this meeting? Or should I participate and engage with my peers to contribute to the outcome of the meeting?

In these situations, I encounter a pattern such as:

If the meeting is not boring, it is productive and will produce a rich outcome for you and, hopefully, all participants.
If the meeting is boring, then either A) it is OK to be boring, politely ask to leave, and you will get the summary afterward, or B) it is not OK to be boring. Your participation is necessary for the outcome of the meeting. Try being more engaging with your peers, and the meeting won’t be boring.

In the end, there are a lot of strategies, and it’s up to you to act on them whenever you see something that could be improved.

It’s OK to point out the “elephant in the room” and ask for help to improve any situation you think (or feel) is not working as it should.

Working Agile with Non-Agile Teams

2022-11-11T00:00:00+00:00

Let’s assume you already know what the agile manifesto is. Let’s consider that you apply most of the “extreme programming” values, principles, and practices. How can you work with other teams that aren’t agile?

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

You’re using short feedback loops, where things are constantly changing. You can feel that the team is alive and every one is essential.

You embrace the change to the point that you enjoy going out of your comfort zone whenever needed. Seeking to create value for your team and its dynamics, and always considering personal growth.

But sure, let’s assume all that, and everything else I might have missed regarding “agility,” how could you work with an external team that is not agile? How could your “perfectly agile team” work with another group of people with nothing to do with software? For example, a doctor.

A doctor has no time to learn about your “agile values and principles for software development.” A doctor has no time to learn about “extreme programming.” Similarly, they don’t have time to learn about testing, design, architecture, and good practices related to software in general.

How could you create a bridge between that doctor and your software team?

How could you work agile with that doctor? #

If you need to work with that doctor is because he/she should be a domain expert. I suggest getting one or two of your team members to meet with that expert for 30/60 min, so they can talk and share their impressions. And then repeat this as much as possible to shorten the feedback loop. For example, once a week.

Collecting those requirements and impressions from the experts and then driving the design of your software according to that is Domain-Driven Design. You can find a lot of documentation about DDD in books (like Domain-Driven Design Distilled) or in many blogs on the Internet.

However, the critical aspect here is not what requirements or impressions are being resolved but how. How could you work agile with that doctor?

Agile is about quick feedback. It’s about effective communication and reducing waste while aiming for simplicity.

By truly applying these five values, you’re already acting agile #

Communication
Feedback
Simplicity
Courage
Respect

These abstract goals apply to any profession, and even life, not just software.

Continuous communication helps shorten the feedback loop, which simplifies the tasks. Always with the courage to address the truth and respect for each other.

Practices are the things that you do #

Sit Together
Pair Programming
Test First
Incremental Design
and many more

And despite having a technical name, they might apply to any profession:

Sit Together & Pair Programming: think and do with other peers

Test First: verify your assumptions first, then solve the problem

Incremental Design: whatever you do, make it better incrementally

Principles guide and motivate the practices to the values #

Mutual Benefit
Diversity
Failure
Opportunity
Baby Steps
Quality
and many more

Mutual benefit is the most important because it’s about finding practices that benefit us now, us later, and the customer too.

Other principles include the diversity of ideas. Don’t be afraid of failure. Look at everything you do as an opportunity for learning. Avoid giant steps because they have a higher risk of failing. Aim for a high-quality system because they are more predictable and easier to change.

The question remains: are you agile? #

I truly believe an agile team is the one who can cope with change at team level. Therefore, you must first master agile within your team, and then you can collaborate with other teams in an “agile way”.

Once you have internalized these points above, you can apply them while working with anyone from any team.

While these isolated ideas are good, they are even more powerful when combined. They create an atmosphere of curiosity and active learning. It might even wake up some passion for your profession that builds an aura of team cohesion, and just like that, the team breathes on its own.

Everyone cares and takes full responsibility for keeping the team healthy by building trust. There is no fear of healthy conflicts. They feel empowered and accountable to their commitments. The team celebrates their results and learns from their mistakes; there is no need for masks anymore.

That’s when the magic starts to happen, and suddenly you can work agile with any team, especially yours.

Different Beliefs About Software Quality

2022-10-08T00:00:00+00:00

I recently got a great question on Twitter which got me thinking for a while and I decided to share my thoughts about it.

The tweet that started this #

But first, some context: I am feeling great because the codebase where I work is getting better and better, so I am tweeting this:

“As software improves with time, you can feel you’re doing right.”

And then I got a question asking for suggestions:

So there we go…

My answer #

Create agreements #

The first thing is to create agreements about what quality software means for your team and yourself. This helps clarify what software culture you want to establish and work towards that direction. Leaving your company should be the last resort once you have no other option.

Before thinking about leaving your company, I would ask you:

Why do you think you cannot improve the working codebase of your company?
What can you do to reduce the friction between your different beliefs regarding what quality means for software?

There is no perfect codebase to work on because software is a living entity and constantly changes. So, at least for me, quality software is the one that can cope with change smoothly.

Once you have agreed on that goal, and while there are multiple ways to achieve that result, my favorite way of working is keeping an agile mindset with doses of extreme programming values, principles, and practices in mind.

Software is about people #

Software is not just about writing clean and solid code. This is indeed desired, and we should aim for that, but we must first understand why we want that. The “why” is based on the values that you have as a team.

If you don’t share the same purpose, the same “why,” then you won’t enjoy working together, and in such a case, I would advise looking for another company that shares your values. But, before that, I would strongly suggest fixing the deeper issue and helping your team improve.

Understanding your why #

You first need to deeply understand your “why” so you can transmit this to your peers and the people around you. Have you tried all you can to create awareness about your “why”?

Some ideas include encouraging collaborative programming (pair/mob), presenting some internal tech talks, creating a culture of sharing knowledge on a regular daily basis, creating awareness about the current status quo, and looking for opportunities to improve everywhere.

Your career path #

If, after several months of (really) trying these ideas, none of them work, look for a new company that shares your beliefs. After all, you’re the first and primary responsible person for taking care of your career path.

Original twitter thread.

Extra thoughts #

If you want something to be different, don’t wait till it’s changed automatically. Try to change it; if it’s not working, leave it. Maybe you don’t belong in that place.

On the other hand, it’s crucial to reflect if you see that pattern often repeating (changing companies too quickly). In such a case, maybe the problem isn’t the companies but yourself.

Software development is not just about code but business. It’s essential to be aware of finding a fair trade-off between speed, costs, and quality, depending on the situation. You might want to use some tech debt to conquer the market as soon as possible.

It doesn’t make sense to have “low quality” as part of the identity of any team. Every team has certain quality expectations. Therefore, the key here is to agree on what good quality is.

Dare to lead

2022-09-30T00:00:00+00:00

Leadership is not about titles, status, and power over people. Leaders are people who hold themselves accountable for recognising the potential in people and ideas and developing that potential. This book is for everyone ready to choose courage over comfort, make a difference, and lead.

Courage and vulnerability #

Leaders need to be more vulnerable #

The problem is that most people associate that vulnerability as a synonym for weakness, but that’s not true.

“Vulnerability is the universal human emotion we feel when we expose ourselves to others during times of risk or uncertainty.”

And this is what the core of leadership is about: the courage to act how we should despite fear, uncertainty, or danger in our way.

Values #

The modern workplace might feel like a “gladiator arena.” While it might not be a matter of a life-dead situation, it still requires bravery, and plenty of sweetness and tears, to the point that we can feel so overwhelmed that we are tempted to leave. So, according to Brené:

“One of the most significant sources of motivation for sticking it out is to be crystal clear about our core values.”

Values are the ideals that we have that bring purpose to what we do in our life. They guide us and give us something to hold on to during dark and difficult times. Strong values guide us to do what is correct rather than easy.

Honesty #

A great leader encourages potential in people and possesses the courage to guide this potential as it develops. One of the critical skills for doing this is courage and the ability to deliver honest and open feedback.

Unfortunately, many leaders are afraid to give tuff feedback and leave their employees in the dark. Yes, sometimes the truth hurts, but we often avoid difficult conversations because they make us uncomfortable.

“Great leaders must be brave and always dare to provide constructive feedback, speak the truth, and be clear about their expectations.”

In the long run, this is kinder and more productive.

Trust #

“Trust is an essential aspect of our working relationships.”

7 behaviours that encourage trust #

Expressed together with the acronym: BRAVING

Setting Boundaries - respect one another’s boundaries
Reliability - which means to follow-up words with actions
Accountability - being responsible and acknowledging mistakes
Vault - the ability to keep confidential information private
Integrity - choosing courage over comfort
Non-judgment - talk to one another without judgment
Generosity - assuming that people meet you with the best intentions

Failure #

The ability to fail and recover from it is an essential skill for any great leader. Fear of failure holds us back and stops us from achieving true greatness.

It is crucial to take off the armor of perfectionism and jump into the uncertainty of life. Only this way do we indeed gain the courage to succeed and lead.

Summary #

The Beauty of Leadership

2022-09-25T00:00:00+00:00

Leadership is not a synonym for management, it has nothing to do with titles or personal attributes. So, what is it? How can we become leaders? And most importantly, why?

While researching this topic, I found “What is leadership” by Kevin Kruse, which I liked particularly. I thought about sharing the key takeaways from that blog post as it expresses very well the general points about what is and what is not leadership.

What is not leadership? #

Leadership has nothing to do with titles. Just because you have a C-level title, doesn’t automatically make you a “leader”. You don’t need a leading title to become a leader.

Leadership has nothing to do with your personal attributes. Leadership is not an adjective. You don’t have to be an extroverted charismatic person to practice leadership.

Leadership and management are not synonymous. Management needs to plan, measure, monitor, coordinate, solve, hire, fire, etc. Managers manage things. Leaders lead people.

What is leadership? #

“A leader is someone who has followers.” Peter Drucker.

This definition is too simplistic and can be dangerous. Just because you have “under you” some people that do what you say simply “following orders” doesn’t mean that you are a leader. You might be a commander, but not necessarily a leader.

“The capacity to translate vision into reality.” Warren Bennis.

Every sprint, you envision fruits in your garden. And you work towards it and make that happen. This makes you a gardener, not a leader.

“Leaders will be those who empower others.” Bill Gates.

Empowering others is essential, but it’s missing the vision or common goal.

“Leadership is influence.” John Maxwell.

A manager has the power to fire team members, which provides a lot of influence. Same as a robber with a gun who has “influence” over their victims. We are missing the source of influence.

So, what about combining them all? #

“Leadership is a process of social influence, which maximizes the efforts of others toward the achievement of a goal.” Kevin Kruse

Key elements of this definition:

Leadership starts from social influence, not authority or power
Leadership requires others, not necessarily direct reports
It includes a goal
No mention of a title or attributes of any kind

End from the key takeaways by “What is leadership” by Kevin Kruse.

Why would anyone want to become a leader? #

We need to make clear that there are two different conceptions when asking that question, and we need to separate them from the beginning.

There is the “leader title” aspect, which is usually attached to the management position. I am not talking about that one. You can be a great manager and an appalling leader.

A leader is a person with the multiplier factor attitude that wants to develop specific skills (related to their social influence) to boost even more the value they produce.

So, can anyone become a leader? What are those skills that you need to be a leader?

Can everyone become a leader? #

Now that we found a definition of leadership, we can agree that this definition could have different degrees applied depending on the type of person and responsibilities they want.

However, to become a leader, you need specific skills. These are the ones I find the most important:

Excellent communication, giving support, and enabling the people around you
Leading by example, especially to become a better self
Passion for sharing your leadership skills, so you build other leaders

Leadership starts within your own life and behaviour.

I am aware that not everyone might want to accept the necessary changes to become a leader, but I truly believe everyone can grow certain leadership skills to some extent, which also means inspiring the people around you.

How to become a better leader? #

You can get inspiration from a lot of different sources. While it’s true that you can learn a lot from your own mistakes and successes, and even from the people around you, I think it’s very optimal to listen to the wisdom from other people’s experiences outside your circle. For example listening to podcasts, ted-talks, books, or even audiobooks.

The beauty of leadership is that it asks for no permission. No title, no promotion, no org chart. It begins the moment you decide to lift the people around you.

Understanding People

2022-08-22T00:00:00+00:00

One of the most complicated challenges for everyone is avoiding misunderstandings and being aware that other people don’t think the same way as you do.

Different perceptions #

People have different experiences and backgrounds, and we all have different perceptions of reality. This is the first thing we need to be aware of if we want to create self-awareness of our role in communication with others or empathy.

Very often, the real issue behind friction in a team is due to miscommunication. Sometimes no one knows how or why two or more team members don’t like each other anymore, but the conflict is obvious.

This can be a problem because it prevents the team from working as effectively as possible. Often, the reason for that friction is because of their inability to understand each other’s motivation and problems.

And this misfunction often leads to misunderstandings.

Misunderstandings #

Our understanding of a conversation might differ from what the other person perceives, which could (and often will) cause a problem. This can become a serious problem related to the relationship’s direction between both parties.

How to solve this? #

Avoiding misunderstandings is not always easy, but by improving your communication skills, you can get better at this step by step.

Empathy #

Empathy is the ability to understand what other people feel, see things from their point of view, and imagine yourself in their place. Essentially, it is putting yourself in someone else’s position.

Effective communication #

In most cases, the solution does not start by fixing the other person. Instead, it helps to work on making yourself more explicit. For example:

Work on clarifying the expectations around the common goal
- Create an open and honest conversation about your expectations
- Assumptions are dangerous
Provide as much context as needed
- Even if it seems evident to you at first instance
Every little detail counts
- More information is always better than less

While aiming for effective communication, we need to reduce the risk of misunderstandings to the minimum.

Self-reflection #

Healthy conflicts are expected and acceptable. We shouldn’t be afraid of disagreements. It’s ok to change our minds when discovering new possibilities; the sooner, the better.

In my experience, understanding people is complicated for multiple reasons, but most especially because of misunderstandings we generate due to missing context, more than disagreements.

If something doesn’t work as expected, start looking at yourself, not blaming others when dealing with people. What could you have said to create more clarity? What would you do differently?

Self-reflection is essential to improve and correct your attitude, adapting to the evolution of the constant change we are surrounded by, especially when dealing with people.

Look over your reach area, share your thoughts, and don’t be ashamed of your mistakes as far as you take them as learning opportunities.

The Great CEO Within

2022-08-01T00:00:00+00:00

Matt Mochary coaches the CEOs of many of the fastest-scaling technology companies in Silicon Valley. He shares his highly effective leadership and business-operating tools with any CEO or manager in the world.

Learn how to efficiently scale your business from startup to corporation by implementing a system of accountability, effective problem-solving, and transparent feedback.

Reading, talking to other experts in a particular area, practicing, and teaching are the best ways to learn and improve yourself.

3 Key takeaways #

You need to learn how to manage yourself before you can manage your business.
Don’t ignore conflict. Be transparent, give and take feedback often, and be an active listener.
Be obsessed with learning about your customer. Do so by asking better questions.

Summary #

The team #

Do not create a 50/50 partnership, because despite it sounds ideal, it actually leads to real pain if there is no easy way to break a deadlock.
Find a partner who has complementary skills to yours. Give a large percentage of the company; it worth it.
Founding teams should never grow beyong six until there is a true product-market fit (PMF).
Metrics that PMF are important. For example revenue, renewal rates, …

Getting things done #

Read “Getting Things Done: The art of stress-free productivity”, by David Allen.

Inbox zero #

Keep your inbox clean as a single triage room at a hospital.
- It is important to distinguish the urgent cases from the ones that aren’t.

Top goal #

Schedule two hours each day to work on your top goal only.
The earlier in the day you schedule this top goal, the better.

On-time and present #

Don’t waste other people’s time.
If you know you’re going to be late, let the other people know as soon as possible.
Be present and focus on what’s being discussed.

When you say it twice write it down #

Write down all processes. In doubt, write everything.

Gratitude #

Focus on the positives.
We perform our best when we are having fun and feeling good.
Be appreciative. Tell people when they’ve done something good.

Energy audit #

Audit your time and figure out how much of it is spend on activities that energize you and what activities drain you.
- Delegate or outsouce the things that drain you as much as possible.

Health #

Your mental and physical health is the most important resource we all have.
- Take care of yourself and the people around you.

Decision-making #

Require that anyone who wants to discuss an issue write it up, along with the desired solution, ahead of time.
This method, thought time-consuming, yields extraordinarily thoughtful decisions in a very shrt amount of time.

Getting buy-in #

When people feel they are part of the decision and their input matters.
When people are given more influence, they feel more invested.

Issues and proposed solution #

Require that anyone who presents an issue at a team meeting do so in writing.
- It should include both a detailed description of the issue and their proposed solution. They cannot say “I don’t know.” They must at least present a guess.
All issues should be presented at the weekly team meeting.
Allow 5 min to discuss each proposed solution.
- If consensus is reached in that time - great.
- Otherwise, don’t spend more time debating, and use RAPID framework instead.

Loudest voice in the roomo #

Be aware of who is in the room when you have a group discussion.
Avoid influencing other people’s ideas by wriring down their vote or thoughts before you share your perspective.
Let juniors ask and speak first.

Sloppy agreements #

Sloppy agreements are when people don’t show up on time, or don’t complete the goals they declare.
The antidote is “impeccable agreements”:
- precisely defined
- fully agreed to by all relevant people
There must be consequences of breaking agreements.
If you can’t meet the agreement, then you have an obligation to let other members of the agreement circle know asap.

Transparency #

Don’t hide negative information.
Our imaginations are much more powerful than reality.
Share all relevant information with your team, both negative and positive.
- Let them adapt.

Conflict resolution #

Interpersonal conflict is almost due to people:
- Not fully sharing their thoughts and feelings
- Not feeling heard
Prove to people that you have heard them by summarizing what you just said back to you until they say “that’s right!”.

Issue identification #

Ask people to pretend they’re the CEO and answer:
- “What are the 3 most important issues for me to solve in the next 90 days?”
Ask people to write down their thoughts about the company when they feel their joy, excitement, sadness, anger and fear.

Conscious leadership #

Be more interested in learning than been right.

Customer obsession #

Focus on the outcome, not the output.
You are solving a customer problem, not just making a product.

Culture #

You don’t choose your values. You have them.
Use your values as a guide to who you hire and when you fire.
Don’t forget to celebrate. Make an effort to publicly acknowledge achievements.
Don’t measure hours. Measure output.
You prevent office politics by never allowing lobbying to be successful.

Company folder system and wiki #

Have a company wiki and make it mandatory that all new hires read it.
Whenever you find yourself doing something twice, write down exactly what it is that you did.
- Everyone on the team should contribute.

Goal tracking #

Never assign someone an action without them agreeing to it verbally or in writing.

Areas of responsibility #

When more than one person shares a responsibility, it often does not get done well, or at all.
One person is assigned to each function in the company.

No single point of failure #

Write down all processes.
Cross-train a second person for each role.

Key Performance Indicators (KPI) #

Known your 5-6 most significant KPIs and track them religiously. Make them visible to the entire team.

Collaboration #

Set vision and goals for the company, each dept, and each individual.
Communicate that vision and those goals to every team member.
Tracking and reporting progress towards those goals on a regular timetable (usually weekly).
Feedback on what’s going right and what needs to be adapted.

Objectives and Key Results (OKR) #

Target 3 objectives with 3 key results for each.
For the company, department, team, individual.
- Cascade them down so they are in alignment.
The objective = “where do we want to go?”. No necessarily measurable.
Key results = “how do we know that we’re getting there?”. It should be measurable.
Gather your leadership team and have everyone come to the meeting with their ideas for what the OKRs should be for the quarter.
- Let individuals come up with their own OKRs. They will be more invested.

Feedback #

Never give negative feedback using a one-way communication method
- Like email, text, or voicemail.

The problem with no giving feedback #

You won’t notice your company’s problems.
Communication will break down.
Your best talent will leave you.

4 A’s of seeking feedback #

Ask for it.
Acknowledge it - repeat what they said. Make them feel heard and understood.
Appreciate it.
Act on it.

How to give negative feedback #

Ask for permission.
State the behaviour (fact).
State how the behaviour makes you feel (feelings).
State your thoughts, opinions, and judgments around the situation (story).
Make a request - a change you’d lie to see in the future.
Ask if they accept the feedback.

Fundraising #

Pick a partner, not a enterprise.
When you need to speak to an investor, ask 3-5 people in your network who know that person to send an email of recommendation to them.
Stack the referrals close together (in the same week) so that you get noticed.
Talk about your company once you know that the investor likes and trust you.
Sell yourself, not the company.

Recruiting #

Spend as little time as possible with the candidates that you don’t hire, and as much time as possible with the candidates that you want to hire.
As the hiring manager, write out a 90 roadmap for the position you need to fill.

On-boarding #

Give onboarding even more attention, time and energy than you give to recruiting.
Assign each new team member a buddy with whom they’ll check in each day for 15 minutes for the first 2 weeks.

Firing #

Whe you make the announcement, praise the person’s contributions to the company, and take ownership yourself for the fact that you weren’t able to match their skills to the company’s needs.
Do not blame or criticise the person. Instead, take responsibility for the situation.

Effective sales #

Build trust.
Sell results, not features.
Identify customers’ pains.

Build trust #

Ask customers about them.
- Listen actively and reflect back what they say.
- At the second meeting show that you remember what they said at the first.
Be explicit about not talking about your company.
Ask for a limited amount of time.
Invite them to a purely social event.

Customer development #

Asking the right questions will help you identify customer’s specific challenges.
You need to understand their pain before presenting your solution.
1. What are their goals?
2. What are the challenges preventing them from reaching those goals?
3. What are their ideal solutions to overcoming those obstacles?

Sell results, not features #

Most people don’t care about your product functionality or features. They care about their business results.
Focus on the why.
Focus on painting the vision of a world where customer’s desires are fulfilled with the help of your product.

Building a sales team & pipeline #

Don’t hire sales people right away.
In most cases, sales people will never be able to sell better than the founders, and they won’t be able to sell the product if you are not able to.
Only hire a sales team if:
- You have found an initial version of product-market fit (this means that a significant proportion of your paying customers are renewing their contracts).
- You have figure out what you are selling and who you are selling to.

The structure of a sales team #

Generating leads and closing deals are distinct functions that must be split.
Senior salespeople are expensive, so their time is best spent focusing on the most high-value activity: closing deals.
Ideal sales team structure:
- Qualifiers - sales development reps: focus on generating leads.
- Closers - account executives: focus on closing leads.
- Farmers - customer success: focus on tending existing customers.

Lead generation #

Predictable leads is the first step to achieve predictable revenue.

Marketing #

Start by concentrating all of your efforts on the low-hanging fruit - the small customer segment that has a particular problem that your product solves 10x better than the competition.
Move on to the next customer segment only after you have the resources to do so.

Product market fit (PMF) #

Designing a significantly better solution to your target customers’ problem than existing in the marketplace.
How do you know when you have achieved PMF?
- Ask your customers. They will tell you by renewing their subscriptions, buying more product(s), etc.
B2B, PMF = long term contracts
B2C, PMF = second purchase, renewing subscription, sharing in social media.

Matt Mochary shares insights on developing his coaching method, understanding & overcoming primal fear, addressing imposter syndrome & more.

The Path to Seniority in Software

2022-06-08T00:00:00+00:00

We all have been junior developers at some point. This is easy to know because it sits at the very beginning of your career. Your responsibilities were narrowed down by other peers who were looking after you.

At some point, after months or years, you got your promotion or another job, where you weren’t a junior anymore, but an intermediate.

An intermediate (also known as middle) is something between junior and senior. You know now that you are not a junior anymore, you know how to deliver value but yet you also have mixed feelings about seniority. You want to be a senior, but you don’t know how. There is no clear path to achieving this goal.

Wait for a second… there are actually two easy ways to get the senior title! You can get promoted as such in your company, or you can start a new position as a “senior” in another company, easy right?

Marketing and politics #

Unfortunately, the “seniority” level is very much polluted by marketing and politics. First, what does it mean “senior” in this context? In all the companies where I have been working (if not all) I have always been surrounded by people who claimed to be “seniors” when in reality only a few I would consider such.

Our senior label is inflated by companies needing experts on paper more than in reality, and this is a problem we need to deal with and speak about.

Seniority generally means more experience, but how do you calculate this? It is easy from a company’s point of view: more years in the industry. But, is the number of years you have been working really relevant in an industry that is constantly changing and evolving? Actually, this wouldn’t be a big issue if you have the software fundamentals well interiorized, but funny enough, I have seen these fundamentals in only ~10% of the seniors I have met across many years and several companies.

The fact that you have been working for 10 or more years doesn’t necessarily mean you are a “senior” with software. What else can we measure in order to identify if you deserve indeed this title?

It is not all about the money #

Let us be honest, senior titles are better paid than junior or middle positions. If you have the chance to get a higher salary because you got the “senior” in your job title, well, it wouldn’t be clever to reject it. But, independently of politics and marketing, we must address some seniority fundamentals to understand better what the word “senior” means in this context.

It is not all about the money, but also about the responsibilities that come with seniority.

Seniority fundamentals #

Being senior in our software industry is not about “the number of years of experience” but:

How well do you transmit your knowledge to others? Sharing what you know is a core task for a senior person.
How well do you collaborate with other people, including the PM/PO and other teams? Collaboration is crucial to creating a constant feedback loop.
How well do you work together with your peers? Pair-programming builds team cohesion and helps everyone become better.
How strong are your testing skills? Testing is tied to the quality of your work, and a senior should aim for an incremental design.
How well do you understand delivering value constantly in small chunks? The sooner you deliver value, the sooner you get feedback about it.
How deep is your technical knowledge of quality software and the trade-offs to get there? SOLID principles, clean code, TDD, refactoring as part of your daily job, low coupling, high cohesion, appropriate data structures, and choosing the right solution (KISS, YAGNI…).
How well do you adapt and cope with change? Change is inevitable, so we must learn to deal with it, especially the parts we cannot control.
How developed is your entrepreneurial thinking? Always keeping the organization’s goals in mind.

As you can see, there is no mention of concrete technology or years of experience. Why? Because technology is just an “implementation detail”, and experience comes by practicing and attitude, not by letting the time pass by.

Attitude is important #

We’ve got two persons:

A) a person who is working for 15 years, doing relatively the same every day, and without caring about his own skills. He just does what others tell him to do.

B) a person who is working for 5 years, challenging herself every week, trying different approaches when dealing with problems, and sharpening her own skills constantly.

Can you see the main difference? No, it’s not the 10 years difference of “experience” between them, but their attitude.

We wrongly understand that a year of experience must come with learning and knowledge, so we tend to use time as a measurement of seniority. But I argue that the “attitude factor” is equal or even more important. I have been surrounded by many people who call themselves seniors with 3, 6, 10, and more years of “experience” but lacking attitude, and you could clearly see this problem on a daily basis.

You need this combination to build yourself as a truly senior developer; time, experience, and most importantly: attitude towards improving your own skills and the ones that surround you.

Where to start #

Seniority is not granted, it is practiced. You don’t wait for the title, you build the behavior until the title catches up. Start small, and start now:

Teach what you know. Pick one thing you understand and explain it to someone this week. If you can’t explain it, you don’t own it yet.
Seek the uncomfortable. Volunteer for the task slightly beyond you. Growth lives at the edge of what you can already do.
Reflect on purpose. After each project, ask what you would do differently. Experience without reflection is just repetition.

The path is not a promotion. It is the daily decision to improve yourself and the people around you. Do that long enough, and the title becomes a formality.

Bikeshedding

2022-05-27T00:00:00+00:00

The term was coined as a metaphor to illuminate Parkinson’s Law of triviality. People within an organization typically give disproportionate weight to trivial issues.

Bikeshed +-ing #

The concept was first presented as a corollary of his broader “Parkinson’s law” spoof of management. “Bikeshedding” is a dramatized form of the “Law of triviality”.

C. Northcote Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively. As he put it:

“The time spent on any item of the agenda will be in inverse proportion to the sum of money involved.”

People within an organization typically give disproportionate weight to trivial issues #

This has been true in all companies where I’ve been working. From time to time, when you have important mixed with not-so-important topics together (or even not important at all!), it’s pretty common to see yourself “bikeshedding” with your peers about the trivial topics instead of confronting the important things that will bring real value soon to the end customer/consumer.

This is more common than we think, and it can happen to everyone.

What can we do about it? #

Create awareness about this problem with your team. Honest communication and trust are crucial for the solution.

Break down steps:

You need to be aware of this problem.
You see value in changing this team behavior.
You are able to point to the problem when you see it occurring.
You expect the same from your team members.

References #

Dunbar Number

2022-04-02T00:00:00+00:00

A cognitive limit to the number of people with whom one can maintain stable social relationships, in which an individual knows who each person is and how each person relates to every other person.

The study shows that:

Close relationship: 5 people.
Share deep trust: 15 people.
Meaningful relations: 50 people.
Active contacts: 150 people.

Why is this limit 150? #

This is due to the limit of our cognitive ability. This is our ability to reason, solve problems, and comprehend complex ideas. As the team size increases, the cognitive load of the team does it as well and communication suffers, thereby breaking down the benefit of a large team.

Origin #

In the 1990s, the British anthropologist Robin Dunbar found a correlation between primate brain size and average social group size. By using the average human brain size and extrapolating from the results of primates, he proposed that humans can comfortably maintain 150 stable relationships. Dunbar theorised that:

“this limit is a direct function of relative neocortex size, and that this, in turn, limits group size […] the limit imposed by neocortical processing capacity is simply on the number of individuals with whom a stable inter-personal relationship can be maintained”.

The number also includes past colleagues, such as high school friends, with whom a person would want to reacquaint themselves if they met again.

Single teams: 5-9 people.
- There is a shared trust among the team members.
- The trust is built over time.
- Therefore, they must be a long term team.
Group: 50 people.
- They can have meaningful relationships.
- They share a domain or subdomain.
- They understand the challenges and help each other out.
Division: 150 people

References #

The Power of Authority and Obedience

2022-01-24T00:00:00+00:00

Milgram was interested in researching how far people would go in obeying an instruction if it involved harming another person, and how easily people could be influenced into committing atrocities. Eg: Germans in WWII.

The experiment #

During the 1960s, the psychologist Stanley Milgram conducted a series of obedience experiments directly related to the power of authority and obedience, even when they might end-up in fatal ending.

Milgram examined justifications for acts of genocide offered by those accused at the World War II, Nuremberg War Criminal trials. Their defence often was based on “obedience”, that they were just following orders from their superiors. Milgram came up with the experiment to answer this question:

Could it be that Eichmann and his million accomplices in the Holocaust were just following orders? Could we call them all accomplices?

The procedure #

The selected participants for his experiment were by newspaper advertising to take part in a study of learning at Yale University; 40 men were recruited, and in exchange for their participation, each person was paid $4.50.

The participant was paired with another person and they drew lots to find out who would be the “learner” and who would be the “teacher”. The draw was fixed, so that the participant was always the teacher, and the learner was one of Milgram’s confederate (pretending to be a real participant).

The learner was taken into a room and had electrodes attached to his arms, and the teacher and researcher went into a room next door that contained an electric shock generator and a row of switches marked from 15 volts (slight shock) to 300 volts (severe shock) to 450 volts (XXX).

The learner gave mainly wrong answers (on purpose), and for each of these, the teacher had to give him an electric shock. When the teacher refused to administer a shock, the researcher gave a series of orders to ensure they continued:

“Please continue.”
“The experiment requires that you continue.”
“It is absolutely essential that you continue.”
“You have no other choice; you must go on.”

Results #

65% of participants (teachers) continued to the highest level of 450 volts. All participants continued to 300 volts.

Milgram did more than just one experiment. He carried out 18 variations of this study. All he did was alter the situation to see how this affected obedience.

Conclusion #

The simple explanation would be that it was something about them as people that caused them to obey, but a more realistic explanation is that the situation they were in caused them to behave in the way that they did.

Some of the aspects of the situation that may have influenced their behaviour included the location, the behaviour of the researcher and the fact that it was an experiment for which they had volunteered and been paid.

People tend to obey orders from other people if they recognise their authority. This response to legitimate authority is learned in a variety of situations, for example in the family, school, and work.

Milgrams’ agency theory #

Milgram explained the behaviour of the participants by suggesting that people have two states of behaviour when they are in a social situation:

The autonomous state: people direct their own actions, and they take responsibility for the results of those actions.
The agentic state: people allow others to direct their actions and then pass off the responsibility for the consequences to the person giving the orders. They act as agents for another person’s will.

Two things must be in place for a person to enter the agentic state:

The person giving the orders is perceived as legitimate for that.
The person being ordered believe that the authority will accept responsibility for what happens.

For example, when participants were reminded that they had responsibility for their own actions, almost none of them were prepared to obey. In contrast, many participants who refused to go on did so if the researcher said that he would take responsibility.

Milgram experiment variations #

Among many others, these are some of the variations:

Uniform #

When the role of the researcher was taken over by an “ordinary person without a uniform” (always a confederate), the obedience dropped to 20%.

Change of location #

Obedience dropped to 47.5% when the experiment was moved to a set of offices instead of the impressive Yale University.

Two other participants (confederates) were also teachers but refused to obey. One at 150 volts, and the other at 210 volts. The presence of others who are seen to disobey the authority figure reduces the level of obedience to 10%.

Absent experimenter condition #

When the researcher instructed and prompted the teacher by telephone from another room, obedience fell to 20.5%. Many participants cheated and missed out shocks or gave less voltage than ordered. The proximity of authority figure affects obedience.

The moral questions Milgram raised #

Why did so many of the participants in this experiment perform a seemingly sadistic act when instructed by an authority figure? According to Milgram, there are some situational factors that can explain such high levels of obedience:

The physical presence of an authority figure increased compliance.
The fact that Yale (a trusted academic institution) sponsored the study led many participants to believe that the experiment must be safe.
The selection of teacher and learner status seemed random.
Participants assumed that the researcher was a competent expert.
The shocks were said to be painful, not dangerous.

Milgram’s experiment has become a classic in psychology, demonstrating the dangers of obedience. The research suggested that situational variables have a stronger sway than personality factors in determining obedience.

Often it is not so much the kind of person a man is as the kind of situation in which he finds himself that determines how he will act.

Stanley Milgram, 1974.

Resources #

Modern CTO

2022-01-23T00:00:00+00:00

Developers are not CTOs, but developers can learn how to be CTOs.

In Modern CTO, Joel Beasley provides readers with an in-depth road map on how to successfully navigate the unexplored and jagged transition between these two roles. Drawing from personal experience, Joel gives a refreshing take on the challenges, lessons, and things to avoid on this journey.

These are the topics you’ll find in the book:

A Modern CTO knows… #

Developers are not CTOs
The spaghetti code MVP epidemic
Over-engineering is a problem
Whether to hire, buy, or out-build their competitor
How not to scale prematurely
How to solve any problem
How to work with programers when you aren’t one
UX mistakes to watch out for
When to speak up
When to hire & fire consultants
How to analyze failure
How to bounce back from unforeseen constraints
Answer the question: “How difficult is it to code…?”
How to avoid the “bottom of the ninth” guy
When to respond to feedback
How to validate an expert in any field
How to effectively communicate complex ideas

Favorite quotes #

If I rest on past achievements, I’ll never grow.

LEVERAGE OTHERS’ EXPERIENCE Books condense a lifetime of experience into a few hours’ read. Powerful right?

There are only two reasons you write bad code:

1)You know how to write good code, but you choose to write bad code. 2)You don’t know how to write good code. And both suck.

As the CTO, you must have a business focus.

Always return to your core goals. […] I make sure each core goal has a clearly defined “why?” behind it, this way if I ever get lost, I go back to my “why.”

Reference to “Start with Why” by Simon Sinek.

When you’re the boss, remember this golden rule: Ask people what they think instead of telling them what to do.

If I can’t asses the human component, I can’t lead a team. […] Team composition carries as much or perhaps even greater weight than programming expertise.

As CTO, if you can’t explain value simply, it means you don’t understand the business value behind your technology.

Leaders Eat Last

2022-01-16T00:00:00+00:00

A company’s biggest strength doesn’t lie in its products or services. It always lies in its people, and in their ability to cooperate closely and rally behind the organization, especially during a crisis.

However, loyalty and commitment must be earned. Today, work has become a contractual, transactional relationship in many organizations. Intense competition and layoffs are the norm. Hardly anyone believes in loyalty to a company anymore, much less lifetime employment.

The 4 Chemicals (E.D.S.O.) #

Each of us is an individual and a part of social groups. We make daily decisions that require us to weigh our self-interests against group interests. This dilemma also happens in our bodies via 4 key chemicals:

Endorphins and dopamine drive us to satisfy our personal needs, e.g. to find food, develop solutions and persevere through problems. They help us to get things done, so we can survive.
Serotonin and oxytocin encourage us to work together with others. They build feelings of trust, loyalty and camaraderie, strengthen our social bonds and increase our inclination to cooperate with others to achieve what we can’t on our own.

Circles of Safety #

Traditionally, our family provides a Circle of Safety where we feel safe and supported. Inside the circle, we have a healthy balance of E.D.S.O. and low Cortisol levels. In organizations, Circles of Safety provide people with a sense of belonging and security. This facilitates communication, cooperation, problem-solving and innovation, allowing people to direct their attention to external threats and opportunities. In contrast, when people feel threatened by internal politics and infighting, they turn their attention inward to focus on self-preservation, making the group more vulnerable as a whole.

Leaders must earn others’ respect and loyalty by making the most sacrifices and being willing to eat last. They must give trust to earn trust.

A Society that’s Out of Balance #

Each of the 4 E.D.S.O. chemicals play important roles in our survival. When they’re in balance, people prosper the way they’re designed to, and their groups/organizations prosper too. Unfortunately, the modern workplace tends to be overflowed with Cortisol and dopamine addiction. We lack Circles of Safety and have become dangerously imbalanced. How did we get here?

Abstraction and Dehumanization: how management via numbers, global systems and virtual interactions can be dangerous and lead to careless acts.
Destructive Abundance: how humans respond to shortage vs excess, and why/how leaders have become so blinded by the commercial interest that they’ve forgotten who they’re supposed to serve.
Social Changes: how our societal norms and values have changed with the post-WWII Boomer Generation, followed by Gen-Xers and Gen-Ys, to become increasingly dopamine-addicted and imbalanced.

Simon Sinek offers many detailed examples and stories of leaders in all walks from the military to politics and businesses.

TED Talk: Why Leaders Eat Last #

The Five Dysfunctions of a Team

2021-12-07T00:00:00+00:00

This book is a leadership fable about a tech company that is struggling to get more customers. The C level is not working as a team, and they have a hard time coming to any agreements which result in negative morale. Until the new CEO, Catherine Petersen, joins the team, and she is able to recognize the problems and help the team overcome them by understanding the situation.

This is the first book I read from the author Patrick Lencioni, who is an American writer who writes books on business management. He is the founder and president of the Table group, a management consulting focused on organizational health.

Book summary #

Kathryn Petersen, Decision Tech’s CEO, faces the ultimate leadership crisis: Uniting a team in such disarray that it threatens to bring down the entire company. Will she succeed? Will she be fired? Will the company fail?

Throughout the story, Lencioni reveals the five dysfunctions which go to the very heart of why teams even the best ones-often struggle. He outlines a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team.

The 5 dysfunction model #

1) Absence of trust #

The fear of being vulnerable prevents team members from building trust with each other.

This occurs when team members are reluctant to be vulnerable with one another and are unwilling to admit their mistakes, weaknesses or needs for help. Without a certain comfort level among team members, a foundation of trust is impossible.

2) Fear of conflict #

The desire to preserve artificial harmony stifles productive ideological conflict within the team.

Teams that are lacking on trust are incapable of engaging in unfiltered, passionate debate about key issues, causing situations where team conflict can easily turn into veiled discussions and back channel comments. In a work setting where team members do not openly air their opinions, inferior decisions are the result.

3) Lack of commitment #

The lack of clarity and/or buy-in prevents team members from making decisions they stick to.

Without conflict, it is difficult for team members to commit to decisions, creating an environment where ambiguity prevails. Lack of direction and commitment can make employees, particularly star employees, disgruntled.

4) Avoidance of accountability #

The need to avoid interpersonal discomfort prevents team members from holding each other accountable for their behaviors and performance.

When teams don’t commit to a clear plan of action, even the most focused and driven individuals hesitate to call their peers on actions and behaviors that may seem counterproductive to the overall good of the team.

5) Inattention to results #

The pursuit of individual goals and personal status erodes the team’s focus on collective success.

Team members naturally tend to put their own needs (ego, career development, recognition, etc.) ahead of the collective goals of the team when individuals aren’t held accountable. If a team has lost sight of the need for achievement, the business ultimately suffers.

Video Summary #

Start with Why

2021-11-28T00:00:00+00:00

Start with Why asks (and answers) the questions: why are some people and organizations more innovative, more influential, and more profitable than others? Why do some command greater loyalty from customers and employees alike? Even among the successful, why are so few able to repeat their success over and over?

The ability to inspire those around you and to achieve remarkable things starts with WHY. Those who start with WHY never manipulate, they inspire.

People like Martin Luther King Jr., Steve Jobs, and the Wright Brothers had little in common, but they all started with WHY. They realized that people won’t truly buy into a product, service, movement, or idea until they understand the WHY behind it.

The ability to inspire those around you and to achieve remarkable things starts with WHY.
Any organization can explain what it does; some can explain how they do it; but very few can clearly articulate why.
Your WHY is your purpose, cause or belief.
Every inspiring leader and organization, regardless of size or industry, starts with WHY.
When your WHY goes fuzzy, it becomes much more difficult to maintain the growth, loyalty, and inspiration that helped drive your original success.

People don’t buy WHAT you do, they buy WHY you do it.

Great leaders are able to inspire people to act. And those who are able to inspire give people a sense of purpose or belonging that has little to do with any external incentive or benefit to be gained.

Video Summary #

Leadership is Language

2021-10-22T00:00:00+00:00

A radical playbook to empower your people and put your team on a path to continuous improvement.

In this book, the former submarine commander Captain L. David Marquet dives deep into one of the most investigated marine disasters, the sinking of the El Faro, and surfaces with new ideas on leadership and language.

You might imagine that an effective leader is someone who makes quick, intelligent decisions, gives inspiring speeches, and issues clear orders to their team, so they can execute a plan to achieve your organization’s goals. Unfortunately, that’s an outdated model of leadership that just doesn’t work anymore.

Your words matter more than you think.

David gives six plays that all leaders should use to improve how their teams operate. He says a big problem with leaders today is that they are trapped in an industrial-age playbook. In the industrial age leaders gave commands and employees followed, and that was it. But that way of leading is no longer effective, it is outdated.

The six plays #

Control the clock, don’t obey the clock: pre-plan decision points and give your people the tools they need to hit pause on a plan of action if they notice something wrong.
Collaborate, don’t coerce: as the leader, you should be the last one to offer your opinion.
Commit, don’t comply: rather than expect your team to comply with specific directions, explain your overall goals, and get their commitment to achieving it one piece at a time.
Complete, not continue: if every day feels like a repetition of the last, you’re doing something wrong.
Improve, don’t prove: ask your people to improve on plans and processes, rather than prove that they can meet fixed goals or deadlines.
Connect, don’t conform: flatten hierarchies in your organization and connect with your people to encourage them to contribute to decision-making

Video Summary #

Turn the Ship Around!

2021-09-12T00:00:00+00:00

The book is about his leadership theories to how he implemented a fresh leadership model. Including the limitations of a hierarchical top-down model, why/how he failed to empower his team earlier in his career, and how the circumstances for Santa Fe were ideal for him to experiment with the new leader-leader approach.

Most people unconsciously divide the world into leaders vs followers, and make assumptions about what each group can/can’t do. Such assumptions influence our thoughts and actions that impact the performance of individual employees and the organization.

It is common for enthusiastic employees to suggest new ideas, and then they are told “it’s not your job” or “that won’t work”. People feel frustrated and eventually stop trying or leave the organization. Bosses also feel frustrated when their staff would rather do the minimum rather than to innovate or take responsibility.

The leader-leader model recognizes that everyone has the ability and potential to lead. It taps on individual potential at all levels, reduces dependency on a single leader and delivers sustained performance.

The 3 key components: Control, Competence and Clarity #

Control #

Control refers to the freedom and authority to make decisions about why, what and how you’re going to work. The goal is to delegate decision-making control as far as possible in the organization.

Find the genetic code for control and rewrite it.
Act your way to new thinking.
Short, early conversations make efficient work.
Use “I intend to…” to turn passive followers into active leaders.
Resist the urge to provide solutions.
Eliminate top-down monitoring systems.
Think out loud (both superiors and subordinates).

Competence #

People at every level must be technically competent to make the right decisions. If you give people additional responsibility without equipping them with the required knowledge and resources, things will fall apart.

Take deliberate action.
We learn (everywhere, all the time).
Don’t brief, certify.
Continually and consistently repeat the message.
Specify goals, not methods.

Clarity #

For people at all levels to make effective decisions, they must be fully aligned with the organization’s purpose, and thoroughly understand the organization’s goals and decision-making criteria.

Achieve excellence, don’t just avoid errors.
Build trust and take care of your people.
Use your legacy for inspiration.
Use guiding principles for decision criteria.
Use immediate recognition to reinforce desired behaviours.
Begin with the end in mind.
Encourage a questioning attitude over blind obedience.

Favourite quotes #

Leadership is communicating to people their worth and potential so clearly that they are inspired to see it in themselves.

Summary #

David Marquet talks about leadership that turns the ship around in his keynote at the Worldwebforum.

Responsibilities of a Tech Lead

2021-07-01T00:00:00+00:00

The Trident Career Model by Patrick Kua has three tracks. Each track represents where people spend most of their time or energy.

Archetypal Story #

Individual Contributor #

70-80% time spent on “Executing, doing”.
Designing. Testing. Coding.

Management #

70-80% time spent on “Managing the system”.
Planning. Organizing. Supporting. Budgeting.

Technical Leader #

70-80% time spent on “Leading Technical Topics & Teams”.
Aligning Team. Technical Vision. Growing Tech Knowledge. Tech Risk & Tech Debt Management.

What is a Tech Lead?

“A Tech Lead is a software engineer, responsible for leading a development team, and responsible for the quality of its technical deliverables.” (source)

A Tech Lead is a Developer who is a Leader #

A good leader is making sure that the team is moving in the same direction. The team moves further altogether, rather than simply people who are working “together”.

Leadership skills to invest in #

Empathy
Self-Awareness
Motivation
Conflict Resolution
Communication
Coaching
Feedback
Influencing
Delegation

The Tech Lead role is a leadership position, not necessarily a management position.

Surprises & Struggle #

Feeling Alone: “Outsider”. Different role. Shield/Filter.
Uncertainty: No right answer. Binary habit. Imperfect information.
People are puzzling: Unique. Different Strengths. Archetypes.

A Great Tech Lead #

A great Tech Leader is really focusing on developing others, so the team will get better capabilities.

Tell or Delegate? #

The goal is to reach a complete delegation, step by step. It’s about starting to shift responsibilities to other people, so they grow as well. It can also depend on the skills, motivations, and urgency of the task.

“Nobody is perfect, but a team can be.” - Meredith Belbin

Key points #

Tech Lead is a role change.
It requires leadership skills.
Others have been on this journey.
There are many resources available.
Move from maker mode to multiplier.

Recommended books on this field #

References #

Become an Effective Software Engineering Manager

2021-06-27T00:00:00+00:00

A great compilation of all topics that are important for management: 1:1s, performance reviews, hiring and laying off, workplace politics, remote work, and others.

The book is divided into 3 parts: the first part covers things a new manager should know, the second and third parts go into topics that all managers should master.

Although I kept nodding along with the bits of advice, I sometimes felt it was too “wordy” or going into too many details that I wasn’t interested in. That said, I kept moving forward, and I am glad that I finished it, gathering a lot of useful tips.

My takeaways from this book:

Part 1 - Getting Oriented #

Chapter 01: A New Adventure #

Practical advice on things to do the first week and finding misalignment signals on your first week.

Chapter 02: Manage Yourself First #

A good reminder of how getting your things an order comes first - this is a pre-requisite to you being efficient, as a manager.

“Your calendar it is both for you and other people to use. Keep it tidy and meaningful. It represents you. Making meetings public by default can help others reason better about how to schedule time with you.”

Part 2 - Working with Individuals #

Chapter 03: Interfacing with Humans #

This chapter covers a lot of ground on how to communicate with others.
Think twice before broadcasting information.
Be consistent in your communications style.

“Don’t communicate when you want to, but when you need to.”

Chapter 04: One-to-Ones #

It’s their meeting, not yours.

“Try to get your direct reports to do 70% of the talking. If you feel like solving their problem for them, don’t. Ask another question and let them arrive at the conclusion themselves. This is an art that takes some practice.”

Chapter 05: The Right Job for the Person #

Motivation and the hierarchy of needs. Developing skills with some practical examples on doing so.

“However, as their manager, you can work with them to place these career achievements at the bottom of their skill tree, and then plan out the milestones along the way that they can aim for to make measurable progress. Thus pushing the frontier of their zone of proximal development further and further.”

Chapter 06: The Most Wonderful Time of the Year (Performance Reviews) #

Preparing for performance reviews ahead of time. Getting peer feedback, and doing this via email, for example.

Chapter 07: Join Us! (Hiring) #

The case for not needing the most senior candidate.
Culture fit.
Setting up an interview process.

Chapter 08: Game Over (Attrition) #

People leaving is normal.
Voluntary resignations that are:
- “good reasons”, aka you could have not done much about it.
- “bad reasons”, that is you could have caught (and addressed) things early like coworker conflict, lack of challenge, compensation.

“As a manager, you are doomed to failure if you think that you are going to keep everyone in your current team indefinitely. […] You should never fight to keep staff if you cannot actually provide the conditions under which they can become happier than they already are. You’ll just defer their departure.”

Chapter 09: How to win friends and influence people (Being well-connected) #

Building your network . Making introductions, checking in with others.
Coaching and mentoring.

Part 3 - The Bigger Picture #

Chapter 10: Humans are Hard #

Working harder or faster isn’t what you should be focusing on. Instead, you should be creating the conditions that make your staff happy and productive through nurturing their autonomy, mastery, and purpose.

“At more senior levels, During bad times, you will get the fingers pointed at you as you are fundamentally accountable, even though it may have not been your fault.”

Chapter 11: Projects are Hard #

“The eye off Sauron” - working on high-stakes projects.
Things slowing down as the team is growing. More (legacy) code, more problems to deal with.
Scope, resources and time balance.

“Lead from the front: As a leader, you need to set the example for the rest of the team. Put in the work. The hardest projects can become career-defining moments. Own them and be there.”

Chapter 12: The Information Stock Exchange #

Spies and gatekeepers.

“As a manager, you will be required to make regular decisions about how much you should share with other staff and when.”

Workplace politics.

“In workplace politics, your network of peers is important as it allows you to be more broadly informed about how the wider business feels about your own initiatives and priorities.”

Chapter 13: Letting Go of Control #

Remove distractions and recharge properly outside work.
Use 10% of your time each week to do nothing and let your thoughts emerge.

“Let go of outcomes that you cannot control. Be accepting of trying your best, and encourage the same behavior in your staff. Unpredictable results are normal. Failure is acceptable. As long as you are trying your best, and you are enabling your team to try your best, then you have nothing to worry about.”

Chapter 14: Good Housekeeping #

Turn problems into learning opportunities.
Work on improving the team communication.

Chapter 15: Dual Ladders #

Designing an Individual Contributor and Manager track is vital to a healthy engineering organization culture.

Chapter 16: The Modern Workplace #

Diversity and inclusion.
Remote working.
Lead by example: work-life-balance.

Chapter 17: Startups #

Management doesn’t mean bureaucracy.
Good management is a light touch and continued collaboration.

“Remember that start-up experience is highly sought after because being impactful in that environment involves being enterprising, self-motivated, collaborative, and quick to learn. Even if the start-up itself doesn’t work out, your next gig will be all the better for it.”

Chapter 18: The Crystal Ball #

Your career vision. Looking back, looking ahead.

“An important part of a long and fulfilling life is purpose. Purpose is not about economic status or feeling well-being. It’s about a life worth living.”

Conformity Experiments

2021-06-01T00:00:00+00:00

To what extent do social forces alter people’s opinions? Which aspect of the group influence is most important: the size of the majority, or the unanimity of opinion?

The psychologist Solomon Asch #

During the early years of World War II, when Hitler was at the height of power, Solomon Asch began studying the impact of propaganda and indoctrination while he was a professor at Brooklyn College’s psychology department. He also was a professor for 19 years at Swarthmore College.

During the 1950s, Asch became famous for his series of experiments that demonstrated the effects of social pressure on conformity. How far would people go to conform to others in a group? Asch’s research demonstrated that participants were surprisingly likely to conform to a group, even when they personally believed that the group was incorrect.

Asch asked #

To what extent do social forces alter people’s opinions? Which aspect of the group influence is most important: the size of the majority, or the unanimity of opinion?

Asch believed that people behave according to how they perceive the world, not to how it actually is.

The Asch experiment #

Asch used an experiment to study conformity based on a “simple vision test”.

Using a line judgment task, Asch put a naive participant in a room with other confederates/stooges. The confederates had agreed in advance what their responses were going to be when presented with the line task. Giving intentionally the same wrong answer most of the time.

The real participant didn’t know this and was led to believe that the other people were also real participants like himself.

Each person in the room had to state aloud which comparison line (A, B, or C) was most like the target line. The answer was always obvious. The real participant sat at the end of the row and gave his answer last.

Asch was interested to see if the real participant would conform to the majority view. The confederates gave the wrong answer most of the time (known as critical trials).

Findings #

Nearly 75% of the participants in the conformity experiments went along with the rest of the group at least one time.

Asch also found that having one of the confederates give the correct answer while the rest of the confederates gave the incorrect answer dramatically lowered conformity, which means that having social support is an important tool in combating conformity.

After combining the trials, the results indicated that participants conformed to the incorrect group answer approximately one-third of the time.

Why people conform to a group they disagree with #

Why did the participants conform so easily? When they were interviewed after the experiment, most of them said that they did not really believe their conforming answers, but had gone along with the group for fear of being ridiculed.

A few of them said that they really did believe the group’s answers were correct.

Apparently, people conform for two main reasons: because they want to fit in with the group (normative influence) and because they believe the group is better informed than they are (informational influence).

Conformity can be influenced both by a need to fit in and a belief that other people are smarter or better informed.

Factors that influence conformity #

Asch went on to conduct further experiments in order to determine which factors influenced, and how and when people conform. He found that:

Conformity tends to increase when more people are present.
Conformity also increases when the task becomes more difficult.
Conformity increases when other members of the group are of a higher social status.
Conformity tends to decrease, however, when people are able to respond privately (i.e., when the group can’t know the naive participants’ answers).

Resources #

Solomon Asch | Wikipedia

Peopleware

2021-05-28T00:00:00+00:00

Software development is about people: when, how and where they can best work together. Not about programming languages or tools. Not about fast computers, networks or internet access.

Soft skills are truly important in IT, more than people tend to think.

Developing software is about people that communicate with their customers and stakeholders, are supported by their managers and collaborate in teams.

Some of my favourite quotes from this book #

Staying late or arriving early is a damaging indictment of the office environment.
Someone who can help a project to take solid form and progress is worth two people who just do work.
People should be asking and wondering why things are getting done the way they are being done.
There must be always a trade between quality and quantity.
Organisations tend to expand and create a “busy day”, creating a lot of meetings rather than trust their employees to self-organize.
The human elements are usually the bottleneck of a project.
People won’t work harder if you put them under pressure. They might work more for some time, but they will also get overburden and leave.
Managers’ real role is to make it possible for people to work, rather than forcing them to.
Anything you need to quantify can be measured in any way that it’s superior to not measuring at all.
The ultimate management sin is wasting people’s time.
Change won’t even get started unless people feel safe.
Change only has a chance of succeeding if failure (at least a little of failure) is also okay.
Experience gets turned into learning when an organization alters itself to take account of what experience has shown.

Professionals want to develop themselves, and want to be happy at work. This book provides ideas in what managers and developers can do to address these and other similar topics. If you are concerned with people, and looking for ways to improve how you collaboratively develop and deliver software, then this book is for you.

The Whole Is Greater Than the Sum of the Parts

We tend to use the word team fairly loosely in the business world, calling any group of people assigned to work together a “team.” But many of these groups just don’t seem like teams. They don’t have a common definition of success or any identifiable team spirit. Something is missing. What is missing is a phenomenon we call jell.

Concept of the Jelled Team

A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts. The production of such a team is greater than that of the same people working in unjelled form. Just as important, the enjoyment that people derive from their work is greater than what you’d expect given the nature of the work itself.

I found also a nice serie that shares some thoughts over each chapter of this book.

The Art of Leadership

2021-04-19T00:00:00+00:00

Some nice keynotes #

Leadership practices are small things done repetitively over time.
Empathy is a powerful skillset.
The practice of one on ones is important in connecting to a team.
Asking for feedback can build trust and relationships.
Respond to feedback with a thank you and follow up comprehension questions.
Feedback is a gift.
It’s not personal, it’s professional.
Leadership is an outfit that you choose to wear for others to see.
Managers tell you where you are, leaders tell you where you’re going.
Your peers become your allies.

97 Things Every Engineering Manager should know

2021-04-05T00:00:00+00:00

The main takeaway #

As a manager your work is to create clarity, clarity, and more clarity.

Key Insights #

As a manager, you need to fix your personal quirks.
Consider doing experiments instead of making decisions.
“Bad news test” - Given two tasks, which one would you rather be sharing bad news about? Delegate that task.
On a struggling team, start by answering two questions:
- How do I create clarity?
- How do I create capacity?
Ask for clarification.
To give constructive feedback, pay attention to how the person gets stuck, sidetracked or sloppy.
Management is not a promotion. It is a career change.
Most of the dysfunctions come from some lack of clarity goal.
For a fixed deadline, scope and quality are always negotiable.
Emotional contagion is real.
As a new manager, listen and understand before you try to change something.
Good interview questions:
- What have you learned in the past six months?
- Tell me about the time when you failed and what you learned from that?
- Do you have the skills, expertise and experience to perform the job?
Complains are good: they show that you are trusted.

Another blog post with way more detailed key insights: Danlebrero Blog ;)

Pull Requests vs Pair Programming

2021-04-01T00:00:00+00:00

Let’s talk about the benefits of Pull Requests and Pair Programming, and my thoughts on these after some years of experience with them.

Pull Requests #

A Pull Request (PR) is basically a way of showing your suggested code changes such that they are easily comparable with the existing source code. This is part of a workflow that helps developers to share knowledge about the changes that are being done within the system.

A Pull Request is the moment where you ask your peers to review and check out your code changes.

Usually, it’s also used:

For discussions about code style.
To spot potential bugs.
For architectural or design discussions once the solution is done.

Pull Requests aren’t the best tool for everything #

The main problem with these topics above is that PR’s are usually ready when the feature/bug is already being worked on and in the last stage of its development process. It [a PR] is an “already changed proposal [I have already worked on this change, here’s the code] to be merged into the current system [someone please look it over]”.

The concept of “Draft PR” exists to make explicit that a PR is not ready to be merged, so it’s still a “work in progress thing”, but that’s another topic.

Pull Requests are, indeed, one of the best tools that we have in our industry to share knowledge about the changes that we are doing in the system, but sometimes they might be misused, as for example:

Discussions about code style. Code style shouldn’t be discussed in a PR. There should be already a CI running a code style checker, that’s all. If you want to talk about code style, request a change in your code style checker, but not in a random PR.
Spot bugs. Bugs and desired behavior should be covered by automated tests. The developer is the first responsible person for this topic.
Architectural or design discussions. Once a particular solution is developed and ready for review, it is usually really hard to “rollback” that idea and rewrite it again. Because “why would you do that? For some subjective opinion? It’s done already. And it seems to work just fine.”

Having an extra person looking at the changes that we have done for “designing decisions” might be beneficial, but we could have addressed “potential disagreements” in a sooner stage.

What should the purpose of a Pull Request be? #

Sharing knowledge about the proposed changes with the team.
Ensuring the team aligns and agrees across the multiples changes that are getting submitted every day in order to keep a healthy direction for the project. Yes, this might include double-checking the outcome design, but… What if that is now too late? How could we solve all those issues?

Pair Programming #

The concept of “Pair Programming” can be understood from different points of view. Pair thinking and pair programming, driver-navigator roles concepts, or pure live coding from one side. Actually, this is way easier than it looks like at first instance:

Either you watch and help the other person to write code,
Or you type while getting another pair of eyes watching and helping you.

Pair Programming helps the team to work together.

Pair programming is the joy of working with an extra brain and another pair of eyes, where the key is to build a context where you two share the same goal in order to find the best possible solution. All of this while learning from each other every single second. Pair Programming is not about developing the best solution at the very beginning. It’s about making it work, sharing ideas, and finding a better solution together. After that, you can refactor and clean the code.

Pair Programming is a continuous code review #

Pull Requests are an asynchronous way to share code changes, while Pair Programming is totally synchronous because it happens at the same time.

That said, Pull Requests and Pair Programming aren’t mutually exclusive, they can coexist. They are tools, and we should wisely choose them in order to achieve our objectives.

The most common fear that I saw while encouraging to do Pair Programming is that some people are shy and they don’t like to have other eyes around them while they are coding because of:

Fear that they don’t know what to code or where to start.
Fear that others will laugh at their solutions.
Fear to not succeed in public.
Fear to not be able to develop the expected solution for multiple reasons: misunderstanding the task or lack of knowledge.
Fear to change your mind in front of others.
Fear to discuss and make decisions loud.
Fear of disagreeing with others.

After several years of experience on this topic #

The pattern which rejects Pair Programing is basically “fear”, and being out of your comfort zone. And this is due to the misunderstanding of the roots of the actual Pair Programming concept.

Pair Programming is not “to show off in front of your colleagues” or “to be screwed by your peers”, but to be transparent (showing your skills as they really are) and improve as a team lifting up each other.

Programming is an iterative process that needs a continuous refactoring of our way of thinking in order to achieve better solutions, day by day. Therefore, programming with another person next to you (with a different way of thinking) will help the team to get the best from each other while discarding the waste or bad habits if necessary.

Pair Programming doesn’t need to be always set for everything. As a tool, it’s flexible, and we can choose how, when and for what reason.

A personal rule of thumb, before starting tasks that might involve touching multiple modules or complex business rules, think about a quick Pair Thinking/Programming with another more experienced colleague in that field.

Everything depends on a particular context and people: the developers, the pairs, the tasks, the mood.

Still uncomfortable with Pair Programming? #

If you still feel uncomfortable having another person next to you while you write code, it might be because you aren’t particularly happy with your own code, or the process that you follow in order to achieve some result. My favorite way to work on this is by exercising on your own and working on improving your skills as a software developer.

Create and play around with your own pet projects.
Work on code katas on your own and with others.

Practice makes the master.

Keep pull requests, add pair programming #

Don’t get me wrong, Pull Requests are great. Keep doing them.
Team collaboration is essential. Pair Programming aims for this.
Pair Programming encourages the team to proactively work together.
Don’t be afraid of coding while having eyes around you. Ask questions when something is unclear. Ask for help when you don’t know how to solve something.

It’s totally ok not knowing everything. The most important thing is to know how to work together.

Sharing Your Git Patches

2020-12-01T00:00:00+00:00

Discover another way of sharing suggestions with your development team.

Imagine this situation #

You are reviewing a Pull Request (PR), and you see some minor improvements or suggestions that you would like to share with the author. You might write some comments, and usually, that would be sufficient.

Imagine that in order to transmit your “whole idea” you would need to change some files because just communicating the full picture will end up in a huge comment which might be not as clear as it could be.

What possibilities are there apart from just comments in a PR? #

Well, there are multiple options. The key is to be aware of them and use them wisely depending on the priority of the task and the changes themselves:

As already mentioned, writing a comment as feedback is a good idea by default, but not the only one.
We can always do some pair-thinking, talk at any time. Communication is always good in order to clarify the possible uncertainty.
Sharing your git patches is another good option.

Git diff to the rescue! #

What if you (as a reviewer) could share your idea without any single commit or comment in the PR, but sharing your changes directly with the author?

Well, that’s actually possible and really easy. As you already know, the git diff command gives you the differences between any two branches.

git diff origin develop > ../my-origin-develop.patch

What we are doing here is redirecting the output of the diff command into a file (aka: patch), so we can share that output with any other peer-team.

What now? #

Well, having that patch file, it’s pretty easy to apply those changes in your local machine without doing any commit:

git apply ../my-origin-develop.patch

Applying this patch will simply change your local system in the same way the patch was created.

“How to” by steps #

Let’s divide the responsibilities into two: the creator of the patch and its user:

The patch creator: the person who will create the patch #

# Checkout that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Do your suggestions and changes in the targeted branch
# Generate the patch file using the diff command
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Share the patch file with the author of the PR

The patch user: the person who will see the patch #

# Ensure you are in that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Apply the patch file
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

References #

Official documentation for “git apply”

Never split the difference

2020-06-12T00:00:00+00:00

From policing the rough streets of Kansas City, Missouri, to becoming the FBI’s lead international kidnapping negotiator to teaching negotiation at leading universities, Chris Voss has tested the techniques in Never Split the Difference across the full spectrum of human endeavor and proved their effectiveness.

Takeaways #

Negotiation begins with listening, making it about the other people, validating their emotions, and creating enough trust and safety for a real conversation to begin.
Use mirrors to encourage the other side to empathize and bond with you, keep people talking, buy your side time to regroup, and encourage your counterparts to reveal their strategy.
Tactical empathy brings our attention to both the emotional obstacles and the potential pathways to getting an agreement done.
Giving someone’s emotion a name, otherwise known as labeling, gets you close to someone without asking about external factors you know nothing about.
“No” provides a great opportunity for you, and the other party to clarify what you really want by eliminating what you don’t want.

Summary video #

The Manager Path

2020-03-26T00:00:00+00:00

Key lessons #

One-on-one meetings with your manager are an essential feature of a good working relationship.
A manager’s job involves making it easy for her employees to get things done by creating fertile environments in which work can happen.
Mentoring new hires is critical.
Feedback works best when you, as a manager, pair that feedback with coaching.
It’s unrealistic to think you can or should shield your team from everything.

Extreme Programming Explained

2020-03-05T00:00:00+00:00

Definition #

Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.

Values #

The five values of XP are communication, simplicity, feedback, courage, and respect and are described in more detail below.

Communication #

Software development is inherently a team sport that relies on communication to transfer knowledge from one team member to everyone else on the team. XP stresses the importance of the appropriate kind of communication: face to face discussion with the aid of a white board or other drawing mechanism.

Simplicity #

Simplicity means “what is the simplest thing that will work?” The purpose of this is to avoid waste and do only absolutely necessary things such as keep the design of the system as simple as possible so that it is easier to maintain, support, and revise. Simplicity also means address only the requirements that you know about; don’t try to predict the future.

Feedback #

Through constant feedback about their previous efforts, teams can identify areas for improvement and revise their practices. Feedback also supports simple design. Your team builds something, gathers feedback on your design and implementation, and then adjust your product going forward.

Courage #

Kent Beck defined courage as “effective action in the face of fear”. This definition shows a preference for action based on other principles so that the results aren’t harmful to the team. You need courage…

to raise organizational issues that reduce your team’s effectiveness.
to stop doing something that doesn’t work and try something else.
to accept and act on feedback, even when it’s difficult to accept.

Respect #

The members of your team need to respect each other in order to communicate with each other, provide and accept feedback that honors your relationship, and to work together to identify simple designs and solutions.

Principles #

Humanity #

Human beings are the ones developing software. It is a fact. The book mentions 5 points that are needed for developers to become good: basic safety, accomplishment, belonging, growth, and intimacy.

The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together.

Economics #

Software costs. Someone or multiple people paid or invested in it.

Make sure what you are doing has business value, meets business goals, and serves business needs. For example, solving the highest priority business need first maximizes the value of the project.

The earlier software makes money, the sooner the development is valuable.

Mutual Benefit #

Mutual benefit in XP is about activities benefitting all concerned. This principle is about finding practices that benefit me now, me later, and the customers as well.

The book brings up 3 points how XP mutually deals with communication-with-the-future problems:

I write automated tests that help me design and implement better today. I leave these tests for future programmers to use as well. This practice benefits me now and maintainers down the road.
I carefully refactor to remove accidental complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter it later.
I choose names from a coherent and explicit set of metaphors which speeds my development and makes the code clearer to new programmers.

Self-Similarity #

This principle is about copying the structure of one solution into a new context.

For example, the basic structure of development is that you write a failing test and then make it work. This structure operates at all different scales. Take into account, this principle is a good start, but it may not always work.

Improvement #

Do your best today but strive to do better tomorrow, strive to have a deeper understanding tomorrow. XP shines in this aspect, it is about always improving.

Put improvement to work by not waiting for perfection. Find a starting place, get started, and improve from there.

Diversity #

Teams need to bring in people from different backgrounds, with different experiences, attitudes, etc. In order for the team to have different ways of thinking and solving a problem.

The principle of diversity suggests that the programmers should work together on the problem and both opinions should be valued.

Reflection #

Good teams reflect after action, regularly. They think about why and how they are working.

Why did we succeed? What should we continue doing?
Why did we fail? What can we do better or differently?

Reflect and strive to improve. Even if everything seems perfect, know that there is always room for improvement and throw in the question:

Why do things seem perfect? What are we doing well? What can we do better in order to succeed even more?

Flow #

Flow in software development is delivering a steady flow of valuable software by engaging in all the activities of development simultaneously. Don’t deliver software in big portions. Deploy smaller increments of value more frequently.

Opportunity #

Learn to see problems as opportunities for learning and improving.

Part of being extreme is consciously choosing to transform each problem into an opportunity: an opportunity for personal growth, deepening relationships, and improved software.

Redundancy #

The difficult problems in software development should be solved in multiple ways.

The cost of the redundancy is more than paid for by the savings from not having a disaster.

Failure #

Sometimes it is extremely difficult to implement something, we don’t know which way or approach to take, try the ideas you have, even if they fail! Failure isn’t a waste, rather a learning experience.

Be aware of falling into the trap of discussing or thinking forever and not getting things done.

When you don’t know what to do though, risking failure can be the shortest, surest road to success.

Quality #

Projects don’t go faster by lowering the quality. Actually it’s often the other way around (if not always). It results in later and less predictable delivery, especially due to the amount of time spent on fixing bugs for example.

Pushing quality higher often results in faster delivery.

A concern for quality is no excuse for inaction. If you don’t know a clean way to do a job that has to be done, do it the best way you can. If you know a clean way but it would take too long, do the job as well as you have time for now. Resolve to finish doing it the clean way later.

Baby Steps #

Take baby steps. Making big changes in big steps is dangerous. People and teams can take many small steps so they appear to be moving forward rapidly.

Baby steps acknowledge that the overhead of small steps is much less than when a team wastefully recoils from aborted big changes.

Accepted Responsibility #

Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren’t.

Practices #

While it is possible to do these practices in isolation, many teams have found some practices reinforce the others and should be done in conjunction to fully eliminate the risks you often face in software development.

Sit Together #

Since communication is one of the five values of XP, have your team sit together in the same space without barriers to communication, such as cubicle walls.

Whole Team #

Include on the team people with all the skills and perspectives necessary for the project to succeed.

Informative Workspace #

Set up your team space to facilitate face to face communication, allow people to have some privacy when they need it, and make the work of the team transparent to each other and to interested parties outside the team.

Energized Work #

You are most effective at software development and all knowledge work when you are focused and free from distractions.

Pair Programming #

Pair Programming means all production software is developed by two people sitting at the same machine. The idea behind this practice is that two brains and four eyes are better than one brain and two eyes. You effectively get a continuous code review and quicker response to nagging problems that may stop one person dead in their tracks.

Teams that have used pair programming have found that it improves quality and does not actually take twice as long because they are able to work through problems quicker, and they stay more focused on the task at hand, thereby creating less code to accomplish the same thing.

Pair programmers:

Keep each other on task.
Brainstorm refinements to the system.
Clarify ideas.
Take initiative when their partner is stuck, thus lowering frustration.
Hold each other accountable to the team’s practices.

Pair programming is a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.

Though, if you need privacy and time to work on an idea, go ahead and do it. We need both companionship and privacy. Make sure to rotate pairs frequently and take frequent breaks, pairing can be tiring, but surely is rewarding.

Stories #

Describe what the product should do in terms meaningful to customers and users. These stories are intended to be short descriptions of things users want to be able to do with the product that can be used for planning and serve as reminders for more detailed conversations when the team gets around to realizing that particular story.

Give the stories a short title and a description. Write them on cards and put them on a wall that is often being passed.

In XP stories are estimated extremely early, which gets the team thinking about how to get the largest return from the tiny investment.

Weekly Cycle #

The Weekly Cycle is synonymous to an iteration. In the case of XP, the team meets on the first day of the week to reflect on progress to date, the customer picks the stories they would like delivered in that week, and the team determines how they will approach those stories.

The intent behind the time boxed delivery period is to produce something to show to the customer for feedback.

Ten-Minute Build #

The goal with the Ten-Minute Build is to automatically build the whole system and run all of the tests in ten minutes.

Continuous Integration #

Continuous Integration is a practice where code changes are immediately tested when they are added to a larger code base. The benefit of this practice is you can catch and fix integration issues sooner.

This practice requires some extra discipline and is highly dependent on Ten Minute Build and Test First Development.

Test-First Programming #

Write a failing automated test before changing any code.

The book mentions 4 problem Test-First Programming addresses at once:

Scope creep: It’s easy to get carried away programming and put in code “just in case.” By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding. If you really want to put that other code in, write another test after you’ve made this one work.
Coupling and cohesion: If it’s hard to write a test, it’s a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test.
Trust: It’s hard to trust the author of code that doesn’t work. By writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you.
Rhythm: It’s easy to get lost for hours when you are coding. When programming test-first, it’s clearer what to do next: either write another test or make the broken test work. Soon this develops into a natural and efficient rhythm: test, code, refactor, test, code, refactor.

Incremental Design #

Invest in the design of the system every day.

You do a little bit of work up front to understand the proper breadth-wise perspective of the system design, and then dive into the details of a particular aspect of that design when you deliver specific features.

This approach reduces the cost of changes and allows you to make design decisions when necessary based on the most current information available.

Roles #

Although XP specifies particular practices for your team to follow, it doesn’t really establish specific roles for the people on your team.

Depending on which source you read, there is either no guidance, or there is a description of how roles typically found in more traditional projects behave on XP projects.

The Customer #

The Customer role is responsible for making all of the business decisions regarding the project including:

The XP Customer is assumed to be a single person, however experience has shown that one person cannot adequately provide all of the business related information about a project.

The Developer #

Because XP does not have much need for role definition, everyone on the team (with the exception of the customer and a couple of secondary roles listed below) is labeled a developer. Developers are responsible for realizing the stories identified by the Customer.

The Tracker #

The main purpose of this role is to keep track of relevant metrics that the team feels necessary to track their progress and to identify areas for improvement.

The Coach #

This is usually an outside consultant (or someone from elsewhere in your organization) who has used XP before and is included in your team to help mentor the other team members on the XP Practices and to help your team maintain your self-discipline.

What is XP? (in 2 min) #

Tech Talk by kent Beck: XP 20 years later #

How to Improve Your Tech-Talk (or Any Other Presentation)

2019-11-18T00:00:00+00:00

We have found ourselves attending a meeting that felt like we were wasting our time with a “monologue” that is either hard to follow or doesn’t seem so interesting as it could. Let’s fix this.

Therefore, I was thinking about it, and I tried to get some keys to improving their general quality. It applies to all presentations but also tech-talks and other tech presentations in which engineers are usually involved.

Structure of the talk #

To explain how I think a good presentation should look like I will address three main topics that are relevant to structure and design your presentation.

Content of the presentation: what message do you want to convey to whom and how?
Design and Layout: how you can design an easy-to-follow presentation that supports your talk instead of taking away the attention from what you are actually trying to say.
Lastly, I think also the audience is responsible for making a tech talk successful, so I will also add a reminder about the role and responsibilities of the listeners.

Consider your audience #

When you prepare your presentation, ask yourself:

Who is attending the talk?
Which backgrounds do they have?
Which position do they have?
Which information is relevant to them?
Do they have to know all the keywords that you would like to use?

Introduce the topic #

Create some atmosphere. Try to answer these questions:

Why should they listen to you?
Why should they spend their time in another meeting?
What will they have learned by the end of the talk?
What is your main message?

Every meeting should have an output and an outcome. Keep it in mind.

Create a Storyline #

When preparing the main content of your talk, think about a storyline that connects your arguments. This makes it easier for the audience to follow.
Stick to the messages that are necessary to explain your idea or concept.
Leave out any unnecessary information that is not relevant to the core of your message.

Build a conclusion #

Summarize the main conclusion(s) in a concise way:

What is the conclusion of this meeting?
What are the learnings from this meeting?
What are the open questions or next steps?

Design and Layout #

Write less, talk more #

A tech-talk is about learning new ideas and concepts.
A presentation should support your talk, not replace or replicate what you have said.
The more words on the slide, the fewer they will be remembered.
Use visuals/graphics that support your talk instead of additional text.

Large fonts #

If you have some code to present, consider:

If it is a picture: use large fonts inside. I recommend using https://carbon.now.sh/ for simple snippets. Or just screenshots from your favorite IDE.
If you code in live: prepare your editor in advance. Use the Presentation Mode of your IDE.

Role of the Audience #

Responsibilities of the attendee #

No unnecessary phone usage, like Twitter, Instagram, Facebook, WhatsApp, Telegram, etc.
Keep your questions for the questions time, unless the presenter mentions at the very beginning that you can ask at any moment. Usually, it’s better not to interrupt the topic, so we can ask the questions at the end.
Show interest in the topic. The presenter should have spent some time preparing the slides for you.
Pair with the presenter the interest of the topic. This is also the responsibility of the presenter. You both should be eager to learn more about the topic.

Inner questions #

Was it worth the time that we all spent in this room?
Do we regret the attendance of this meeting?

At the end of the meeting, we should ask these questions in order to improve. Ask other people for their feedback, so we can grow further and together.

The Clean Coder

2016-08-01T00:00:00+00:00

Programmers who endure and succeed amidst swirling uncertainty and nonstop pressure share a common attribute: They care deeply about the practice of creating software. They treat it as a craft. They are professionals.

Readers will learn #

What it means to behave as a true software craftsman
How to deal with conflict, tight schedules, and unreasonable managers
How to get into the flow of coding, and get past writer’s block
How to handle unrelenting pressure and avoid burnout
How to combine enduring attitudes with new development paradigms
How to manage your time, and avoid blind alleys, marshes, bogs, and swamps
How to foster environments where programmers and teams can thrive
When to say No and how to say it
When to say Yes and what yes really means

Summary #

Chapter 1: Professionalism #

Being a professional means taking full responsibility for one’s actions.
First rule is not doing harm to the function nor the structure of the software.
You will always make occasional mistakes, but you must learn from each.
You should be certain about all code you release and firmly expect QA to find nothing wrong with it.
- Test it and test it again.
- Automate your tests.
- Design your code to be easy to test.
You should follow the Boy Scout rule and always leave a module a little cleaner than you found it so that it becomes easier to change over time, not harder.
Your career is your responsibility, not your boss nor your employers.
- Spending 20 hours a week beyond your normal work to improve your knowledge and skills.
- Read, experiment, practice (kata), talk to other, collaborate, look over the fence, mentor.
- It should be fun.
Also, know your domain, identify with your customer (no “us vs. them”, ever).

Chapter 2: Saying No #

Professionals have the courage to say no to their managers.
Managers and developers have roles that are often adversarial, because on the short term, their goals tend to conflict.
The higher the stakes, the more valuable a “no” becomes, and the harder to say.
Good teams will successfully work towards a yes, but only a right yes, that will later work out in practice.

Chapter 3: Saying Yes #

There are three parts to making a commitment:
- You say you will do it
- You mean it
- You actually do it
Your commitment must respect the limits of what you expect (based on your experience) you can and cannot do.
- If you recognize you will probably not be able to meet a commitment, you need to raise a red flag immediately.

Chapter 4: Coding #

Programming requires a level of focus that few other disciplines require.
“The zone” (or “flow”) is not as good as people think: you will be locally productive, but will often lose the bigger picture and possibly product not-so-good designs.
Interruptions are bad distractions.
- Pair programming is helpful to cope with them.
- TDD helps to make the pre-interruption context reproducible.
  - Minimize time spent debugging
Coding is a marathon, not a sprint, so conserve the energy and creativity.
Leave when it’s time, even in the middle of something important.
Continuously re-estimate your best/likely/worst completion time and speak up as soon as you recognize you will likely be late.
- Do not allow anyone to rush you.
- Use a proper definition of “done”, with sufficiently high quality requirements.
Programming is too hard for anyone, so get help and provide help to others, in particular (but not only) in mentoring style.
- Don’t be shy from asking.

Chapter 5: Test-Driven Development #

TDD is not a cure-all and is impractical or inappropriate in some (rare) cases.
TDD Cycle:
1. Add a test
2. Run all tests. The new test should fail for expected reasons
3. Write the simplest code that passes the new test
4. All tests should now pass
5. Refactor as needed
6. Repeat

Chapter 6: Practicing #

A programming Kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem.
- A Kata is about the process, not the solution.
- You aren’t solving the problem because you already know the solution.

Chapter 7: Acceptance Testings #

Avoid garbage in, garbage out. Make sure you understand the requirements.
- Creating this understanding means removing ambiguity.
The best way to do this is defining acceptance tests:
- All customer’s conditions need to be fulfilled by automated tests to prove the expected software behavior.
- Success of those tests constitutes the definition of “Done”.
Code implementation should start only when the tests are complete.
Unlike unit tests (which are only for programmers), the audience of acceptance tests are both: business and developers.
Run all tests in a continuous integration and immediately fix any failures.

Chapter 8: Test Strategies #

Consider QA part of the team. They act as specifiers: writing acceptance tests, including the failure cases and corner cases, and perform exploratory testing.
Testing pyramid:
- Most tests are unit tests. By developer and for developers.
- Many tests are component or integration tests. By QA or Business assisted by Developers. For Business and Developers.

Chapter 9: Time management #

Management roles in software development requires good time management.
Meeting are necessary but are also often huge time wasters, so avoid meeting that have no clear benefit <- this is a professional obligation.
Meeting must have an agenda and a clear goal.
- Agile stand up meetings can be an efficient format.
- Iteration planning should take 5% of the iteration.
Concentration (focus) is a scarce resource.
- Use it well when present and recharge with simpler tasks (meetings) and breaks in between.
- How to improve?
  - Sport.
  - Creative input.
  - Short breaks every 45 minutes.

Chapter 10: Estimation #

Estimation is the source of most distrust between business people and developers because the latter provide estimate which the former treats like commitments.
- Both are insufficiently aware that the estimate really is a probability distribution, not a fixed number.

Chapter 11: Pressure #

The professional developer is calm and decisive under pressure, adhering to his training and disciplines, knowing that they are the best way to meet pressing deadlines and commitments.
Avoid situations that cause pressure via:
- make only commitments you can fulfill
- keep your code clean
- work in such a way that you need not change it when in crisis
Don’t panic. Talk with your team. Don’t rush. Trust your disciplines.
Offer to pair to others in crisis.

Chapter 12: Collaboration #

Not all but most programmers like working alone. But we need to understand the goals of the surrounding people, including business folks.
- This requires communication.
Likewise, within the development team: only collective code ownership and pairing produce a good level of communication.
- Programming is all about communication.

Chapter 13: Teams and Projects #

Teams need time (months) to gel, to really get to know each other and learn to truly work together.
- Assigning fractional people to different projects is a bad idea, as is breaking up a good team at the end of a project.
- Instead, assigning several projects to one team can work well.

Chapter 14: Mentoring, Apprenticeship and Craftsmanship #

Young programmers need mentoring.
- Mentoring can be implicit or explicit.
Given that we entrust software with all aspects of our lives, a reasonable period of training and supervised practice would be appropriate.

In this lesson, Uncle Bob demonstrates the need to write a clean code and establishes the bases to achieve it, being these bases of a social and scientific nature. Making it clear that the future of programming is based on an ethical and polite code.

In this second lesson, Uncle Bob teaches us the purpose of comments in the code, breaking the paradigm that commenting is something “I have to do” for the simple fact that we mistakenly consider that commenting is a good practice. For Uncle Bob, writing a comment is a sign of failure, since a good code must be able explain by itself: Fewer Comments = Better Code.

In this third lesson, Uncle Bob focuses on raising awareness, given the need to increase the level of criteria in code production. Pointing to the lack of preparation in most programmers, as one of the main reasons for the inefficiency in software development today.

In this fourth lesson, Uncle Bob introduces us to a software development methodology oriented through testing. This is the Test-Driven Development (TDD), a practice with a long learning curve, but with significant results to generate a more robust, safer, more maintainable code and with greater development efficiency.