diff --git a/docs/about.md b/docs/about.md
index 84b68102..191ede01 100644
--- a/docs/about.md
+++ b/docs/about.md
@@ -14,7 +14,7 @@ Suggesting improvements and best practices or applying quality standards and aut
 
 In a service driven IT sector (with ambiguities and many hidden interests) the product is the hours billed by the consultant, being almost irrelevant the content of the job and the delivered quality. It is thus difficult not to find technical solutions under the policy of applying "the most difficult, non-standard, slowest and most obfuscated way possible" as a competitive element (the hard way and doing weird things). This does not scale. Being ambiguous in JDs (not to say dishonest) without clarifying the real content of the job is easy and very well paid. 
 
-**Ambiguities about DevOps term**. Developing new ad-hoc devops tools and ad-hoc monitoring solutions should not be the role of the devops specialist. A DevOps specialist develops IaC and CI/CD pipelines with standard tools and code, ideally with GitOps patterns & kubernetes and with other responsabilities such as application monitoring. The development of devops tools for kubernetes with i.e. client-go should be clearly mentioned in a JD as "software development of devops tools for kubernetes with client-go" (suitable for a software engineer with client-go skills, a developer of devops/kubernetes/monitoring tools). Likewise, a DevOps specialist should not be a fullstack developer who occasionally does QA + DevOps + Cloud Design/Ops. Avoid confusing terms to justify these different backgrounds by creating two roles like DevOps Software Developer and DevOps SysAdmin.
+**Ambiguities about DevOps term**. Developing new ad-hoc devops tools and ad-hoc monitoring solutions should not be the role of the devops specialist. A DevOps specialist develops IaC and CI/CD pipelines with standard tools and code, ideally with GitOps patterns & kubernetes and with other responsabilities such as application monitoring. The development of devops tools for kubernetes with i.e. client-go should be clearly mentioned in a JD as "software development of devops tools for kubernetes with client-go" (suitable for a software engineer with client-go skills, a developer of devops/kubernetes/monitoring tools). Likewise, a DevOps specialist should not be a fullstack developer who occasionally does QA + DevOps + Cloud Design/Ops. Likewise, avoid confusing terms to justify these different backgrounds by creating two roles like DevOps Software Developer and DevOps SysAdmin.
 
 A tech stack is not relevant compared to the way technology is managed. You could have the best tool and run into trouble by taking the risk of applying an unsupported or not recommended approach. **DevOps principles: People, processes, technology.**