I read Gichin Funakoshi's "The Twenty Guiding Principles of Karate". The book is a commentary on each of the Twenty Principles.
The first principle is translated as "Do not forget that Karate-do begins and ends with Rei".
This made me consider all the times that I’ve seen teams and projects fall apart due to role interaction issues:
- Programmers not valuing Testers
- Testers thinking Programmers are idiots for introducing bugs
- Managers blaming Testers for delays and finding defects
There is almost no relationship that you could imagine on a project where a lack of respect has led to conflict.
In my mind, the first place to start with Respect is with your own role. You have to study your craft, practice, and understand why your skills are important and how your role adds value to a project. When we develop Self-respect for ourselves and our primary Software Development discipline (Testing, Programming, Management, Product, Analysis, etc.), then we can expect respect from others.
I created a podcast episode and video covering the topic in detail:
https://youtu.be/TjN2Fw0XITk?embedable=true
Do you deserve respect?
The video might be relevant if you ever ask yourself:
- Do I get the respect I deserve in my role?
- Is testing seen as a lesser role when compared to programming?
- Is there a bigger respect problem running through the industry?
I think there is a respect problem in the industry, and that it is mostly systemic in an organization when the upper-level management does not respect its workforce. But it can happen that some people in roles do not respect other roles by default.
But, we might not be getting respect because we don't deserve it.
We need to make sure we understand the full value that we bring to the project, and interact with that value proposition in mind.
Is everyone equal?
If you’re on an Agile project, you may have been told that “everyone is a developer.”
That’s all nice and friendly, but we quickly see that the naming system causes confusion.
- Programmers are called Developers
- Testers are called QA
- Product Managers are called Product Owners
If everyone is a developer, then why is only one role referred to as a developer?
It could be that the naming is an issue.
But maybe it is because everyone has found a bug in a piece of software, so everyone thinks they know how to test. But people look at programming in awe; they can’t understand it, so they view the programming role with more respect.
If you do this, if you view programming with more respect than testing, then pair with a good tester and see how much work they do.
And, learn how to code. Programming is hard; you’ll find that out, but every role on the project has its complexities. All the roles are hard until you learn them and practice them.
Is lack of respect a system problem?
When respect is missing, it is not always about individuals.
Sometimes, the company or the management system doesn’t treat people well.
Signs to spot this:
- People in all roles in the organization do not feel appreciated for their work.
- Teams do not work together properly because they all have conflicting objectives and priorities.
- No one understands what other people do, because they don’t actually work together; they just work on the same team or in the same department.
- The stated aim is teamwork, but people are rewarded individually.
In these environments, respect is missing everywhere, not just for testers or junior staff.
There are things you can do here, and I’ll cover them later, but it is hard.
“Software Developer” is an Aspirational Role
I presented a talk at the Joy of Coding conference in 2019, where I said that “Software Developer is an Aspirational Role.”
https://www.eviltester.com/conference/joyofcoding2019_conference
To ‘be’ a software developer fully, you need to be proficient in:
- Product design
- Analysis and requirements
- Testing and quality
- Coding and refactoring
- Deployment and DevOps
- Security and risk
- Marketing and sales
Most people haven’t done ALL of those things. Most people bring a few pieces to the team. That’s why good teams are built by considering all the skills of all the people in them, and then teams work together to learn how to fill the gaps.
But people often view others in terms of their role, and not their personal skill set.
If you have been a manager or programmer (or any role) and move into a testing role (or any other role), some people might not take you seriously. They see you only as “the tester,” not the whole person with a wide range of experience.
Respect at the Human Level
Respect doesn’t happen because of job titles or technical skills. Respect happens when people recognize the unique value that each person brings as an individual and honor that in the work environment.
Respecting someone else means learning to value everything they can bring to the work, not just their role description.
Some classic myths you’ll hear:
- “Programmers don’t respect testers.”
- “Testing is the easy job.”
None of this is always true. Some programmers don’t respect testers, but equally, some testers don’t respect programmers.
Often, people are supported in maintaining these views by the system they work in, when roles are isolated, e.g., a development team and a testing Team.
There is no good reason why one group should not respect the other, but bad processes can create dissonance between them.
When work is handed off from programmers to testers and thrown over a virtual wall with no collaboration.
Teams may not respect each other much in this setup. Neither side sees what the other is doing, or how hard that work is.
But that can be fixed:
- Testers need to own their roles and improve their process.
- Testing needs to fit the overall organization, not stand alone as “the people who find bugs.”
- Push back when a testing process doesn’t match the development process.
People often offer too much respect for what they do not understand, e.g., the magic of programming.
Other times, they respect something too little because it looks simple from a distance, and they don’t understand what has gone into it.
We can solve this by ‘showing people’ what we do and how we do it. But I’ll cover that later when I describe knowledge sharing.
Layers of Respect
Respect doesn’t just mean respect for others.
You can respect:
- The Craft - the discipline itself (e.g., testing is important)
- The Skills - the techniques and approaches required to do the work.
- The Person - Does this person do the job well? Do they bring more skills to the work?
It is possible to respect the craft of testing, but not the way it’s practiced.
Maybe you don’t respect huge test cases, poorly automated test scripts, or waterfall approaches in an “agile” setting.
As individuals, and as teams, we need to make sure we are doing the right thing. And doing the right thing well.
Self-Respect
Before you can expect anyone else to respect your work, you have to respect it yourself.
- Do you respect the craft of testing?
- Are you studying related fields (like philosophy, psychology, or systems theory)?
- Are you pushing yourself to get better at testing?
You have to start from an attitude of “I have a craft that is worthy of respect, I have a set of skills that are worthy of respect, and I know why they are worthy, and I can tell you… I have self-respect and I am worthy.”
If you just accept what’s given to you and never try to advance your craft, you are not respecting the craft, so why should anyone else respect it? Same with skills. And the same with yourself.
Start by knowing your value, and then you can communicate it.
When You Don’t Respect Your Own Role
Some testers who feel undervalued and disrespected might look at programmers and think:
- “They get more respect. I should become a programmer.”
- “I’m just a tester. I want to be something else.”
If your own attitude is ‘just a tester’, why should anyone else treat what you do as valuable?
If you don’t see any value, maybe it’s time to move toward a role you do respect. And you can:
- You can put in the work to learn to code.
- You can practice and learn to design.
- You can develop experience and build production-ready systems.
But you could also do that as a tester. And I guarantee that if you still want to be a programmer, the skills you’ve developed as a tester will massively help you as a programmer. And you’ll have respect for the testers you work with.
If you switch over to being a programmer before gaining respect for testing, then you’ll probably never reach your full potential as a programmer because you are undervaluing the skills required to be a good developer.
I’ve switched around between a lot of roles in the software development process. I started as a programmer, moved into testing, and my programming and design skills helped. The skills I learned as a tester and programmer helped me when I moved into management. And I’ve jumped between all these roles, building and expanding my skills and experience.
Respect the Whole Team
Respect is not just limited to developers and testers:
- Do users get the respect they deserve?
- How about product owners, engineering managers, or test managers?
Usually, when respect is missing, it is missing everywhere.
The more you understand other people’s roles and challenges, the more respect you’ll feel towards them.
It is very hard to assume an “us vs them” attitude when you know what a product owner really goes through, or how tough management can be.
If you have ever moved between roles, then you will know that each role is harder than it looks, and every role deserves respect (provided the work is good).
Respect Is Not About Being Nice
Respect is not about being nice.
Respect is about doing the right things for the right reasons, and having the skill to do them well.
If you are covering for flaws in the process, then you are disrespecting the process.
If you are not pointing out issues in the process, then you are disrespecting that process.
Disrespect creeps in when:
- You keep your head down to avoid trouble, instead of raising important issues
- You don’t push for improvements because it is “not your place.”
- Management ignores problems, telling you to “bring solutions, not problems.”
A culture of “just be nice” is often a symptom of a culture of fear and disrespect, and it can prevent the kind of hard discussions you actually need to get better. The kind of discussions that people who respect each other have.
What Can YOU Do to Build Respect?
You can’t always fix a broken company, but you can build respect where you are.
Knowledge Sharing
Knowledge sharing is a phenomenal force for building respect, certainly on teams and between teams.
The most powerful thing you can do is share what you know:
- Show people what you actually do
- Help teammates learn your skills (as a side effect, they see how hard it can be)
- Encourage others to share what they know, too.
You might start to learn just how much work others put in, and how you can work with them and help them.
Make Roles and Processes Visible
If your work is invisible, don’t expect anyone to respect it by default:
- Make issues visible
- Share updates frequently
- Try to do other roles occasionally, and ask for help from the experts so you can improve.
Pairing
Don’t just work in a silo; pair with others.
- Pairing testers and programmers lets both see how the other thinks
- You might discover ways to improve each other’s work, or spot gaps neither side noticed alone.
When you directly observe the way someone else thinks and overcomes challenges, it is almost impossible not to respect their abilities.
Bring Your Whole Self to Work
If you don’t have enough self-respect to show what you can really do, you should not expect to get full respect from the team.
- Don’t hide your personality or your non-job skills
- Take pride in what only you can contribute
- Help the team see the full scope of what you offer as a Peer
Command, Control, and Real Leadership
Many organizations are run using command-and-control, where bosses give orders and everyone follows.
That often isn’t from respect. Sometimes, it is compliance, driven by fear or hierarchy, not genuine leadership.
A command structure can be built on respect. When leaders are respected for who they are, what they can do, and how they do it, not just where they sit.
If you are ever put into a position of management or leadership responsibility, then ask yourself:
- Are people following because they trust you and your judgment?
- Or just because they have to?
If they have to, then they can leave and do that anywhere. You might find you also have a staff retention problem.
As a leader and manager, you have to learn to respect the team and work with them, not just tell them what to do.
If you want to be respected by others, the great thing is to respect yourself. Only by that, only by self-respect, will you compel others to respect you.
Fyodor Dostoyevsk,
"The Insulted and the Injured"
Build Respect in Your Sphere of Influence
You cannot fix an entire dysfunctional system on your own. Not even when you are at the top.
But you can own your relationships and your interaction with the system around you.
- Foster real teamwork by bringing your full self and asking others about theirs.
- Balance strengths and weaknesses openly, without shame or posturing.
- Learn about other roles and their struggles so you can see their contributions.
Take charge of your sphere of influence and model the respect you want to see. That’s often the most you can do, but it is way more powerful than you think.
Respect is ultimately at a human level. Forget about job titles, roles, or hierarchy.
If you want others to respect you, your craft, or your team:
- Start by respecting yourself and your work
- Take pride in what you actually do
- Keep learning and improving, so you know your work is actually worthy of respect.
Only then can you truly offer respect to others as peers, not as people above or beneath you.
Respect yourself and others will respect you.
Confucius