diff --git a/website/content/en/docs/_index.md b/website/content/en/docs/_index.md
index fbb51edc54bd..98f87b24634d 100755
--- a/website/content/en/docs/_index.md
+++ b/website/content/en/docs/_index.md
@@ -19,9 +19,9 @@ Karpenter works by:
 * **Scheduling** the pods to run on the new nodes
 * **Removing** the nodes when the nodes are no longer needed
 
-As a cluster operator, you can configure an unconstrained Karpenter provisioner when it is first installed and not change it again.
+As a cluster administrator, you can configure an unconstrained Karpenter provisioner when it is first installed and not change it again.
 Other times, you might continue to tweak the provisioner or create multiple provisioners for a cluster used by different teams.
-On-going cluster operator tasks include upgrading and decommissioning nodes.
+On-going cluster administrator tasks include upgrading and decommissioning nodes.
 
 As an application developer, you can make specific requests for capacity and features you want from the nodes running your pods.
 Karpenter is designed to quickly create the best possible nodes to meet those needs and schedule the pods to run on them.
diff --git a/website/content/en/docs/concepts/_index.md b/website/content/en/docs/concepts/_index.md
index 27b41f98da32..31070051bd1c 100644
--- a/website/content/en/docs/concepts/_index.md
+++ b/website/content/en/docs/concepts/_index.md
@@ -4,12 +4,12 @@ linkTitle: "Concepts"
 weight: 35
 ---
 
-Users fall under two basic roles: Kubernetes cluster operators and application developers.
+Users fall under two basic roles: Kubernetes cluster administrators and application developers.
 This document describes Karpenter concepts through the lens of those two types of users.
 
-## Cluster operator
+## Cluster administrator
 
-As a Kubernetes cluster operator, you can engage with Karpenter to:
+As a Kubernetes cluster administrator, you can engage with Karpenter to:
 
 * Install Karpenter 
 * Configure provisioners to set constraints and other features for managing nodes
@@ -82,7 +82,7 @@ The concept of layered constraints is key to using Karpenter.
 With no constraints defined in provisioners and none requested from pods being deployed, Karpenter chooses from the entire universe of features available to your cloud provider.
 Nodes can be created using any instance type and run in any zones.
 
-An application developer can tighten the constraints defined in a provisioner by the cluster operator by defining additional scheduling constraints in their pod spec.
+An application developer can tighten the constraints defined in a provisioner by the cluster administrator by defining additional scheduling constraints in their pod spec.
 Refer to the description of Karpenter constraints in the Application Developer section below for details.
 
 ### Scheduling
diff --git a/website/content/en/docs/tasks/_index.md b/website/content/en/docs/tasks/_index.md
index d4da0411c2d6..f84a1a7cb00b 100755
--- a/website/content/en/docs/tasks/_index.md
+++ b/website/content/en/docs/tasks/_index.md
@@ -4,4 +4,4 @@ linkTitle: "Tasks"
 weight: 45
 ---
 
-Karpenter tasks can be divided into those for a cluster operator who is managing the cluster itself and application developers who are deploying pod workloads on a cluster.
+Karpenter tasks can be divided into those for a cluster administrator who is managing the cluster itself and application developers who are deploying pod workloads on a cluster.
diff --git a/website/content/en/docs/tasks/running-pods.md b/website/content/en/docs/tasks/running-pods.md
index 1ea1daef3257..3d4e593e5b0e 100755
--- a/website/content/en/docs/tasks/running-pods.md
+++ b/website/content/en/docs/tasks/running-pods.md
@@ -13,7 +13,7 @@ Reasons for constraining where your pods run could include:
 * Wanting to use techniques like topology spread to help insure high availability
 
 Your Cloud Provider defines the first layer of constraints, including all instance types, architectures, zones, and purchase types available to its cloud.
-The cluster operator adds the next layer of constraints by creating one or more provisioners.
+The cluster administrator adds the next layer of constraints by creating one or more provisioners.
 The final layer comes from you adding specifications to your Kubernetes pod deployments.
 Pod scheduling constraints must fall within a provisioner's constraints or the pods will not deploy.
 For example, if the provisioner sets limits that allow only a particular zone to be used, and a pod asks for a different zone, it will not be scheduled.