Employee well-being is not a checklist item. It is a philosophy that must show up in daily practices, leadership behaviors, and organizational policies. The good news is that creating a healthy, supportive workplace does not always require sweeping reforms. Often, it comes down to doing the basics right and doing them consistently.

Here are 10 simple ways leaders can take care of their employees and, in turn, build organisations that last.

1. Decent Work-Life Balance

Work-life balance is not about reducing productivity, it is about sustaining it. Teams that are constantly stretched eventually burn out. In some organizations, long hours became the default expectation and soon attrition followed. Encouraging reasonable work hours and respecting personal boundaries keeps employees energized and engaged over the long term.

2. Prioritise Health and Family Well-Being

Employees do not exist in isolation from their families. When organizations recognize this, the culture becomes deeply supportive. In many successful companies, medical emergencies or family priorities are given unquestioned importance. This assurance reduces anxiety and builds long-term trust.

3. Clear and Documented Roles and Responsibilities

One of the most common sources of stress in teams is unclear ownership. When roles overlap without clarity, tasks fall through the cracks. In several cases, projects have derailed because people assumed responsibilities were with someone else. Simple and documented role definitions prevent friction, improve collaboration, and help individuals focus on outcomes rather than navigating confusion.

4. De-Risk Single Points of Failure

Every team has subject matter experts, but concentrating critical knowledge with one person is a risk. Organizations that fail to de-risk often face disruption when such individuals leave or are unavailable. Stronger teams assign a secondary owner for key responsibilities, ensuring continuity and faster ramp-ups. This builds resilience and prevents knowledge silos.

5. Empower to Delegate, Educate to Own

Delegation should not be confused with offloading. Good leaders delegate with context and guidance, allowing team members to learn ownership. Over time, this nurtures independence. In many places, young professionals flourish when they are trusted with responsibility early and supported with mentoring rather than micromanagement.

6. Promote Self-Ownership and Accountability

A culture of self-ownership creates trust and eliminates the need for constant follow-ups.

Cultures where managers must constantly follow up usually reflect weak accountability. High-performing organizations cultivate an environment where individuals take initiative, update proactively, and fully own their work. Such a culture creates reliability, reduces managerial overhead, and drives consistent delivery. Accountability, when embedded as a cultural norm, builds a system where trust is natural.

7. Decent Benefits and Perks

Health coverage is often underestimated until a crisis occurs. Employees in many companies face financial stress because insurance cover is insufficient. Providing a base health insurance of at least 15 to 20 lakhs, with a super top-up option of another 20 lakhs or more, ensures employees and their families are protected. This is not a perk - it is a baseline responsibility for any serious employer.

8. Decent Leave Benefits

Leave policies should strike the right balance - enough to allow rest and recovery, but not so open-ended that employees feel guilty or uncertain about using them. Unlimited leave policies, while well-intentioned, often backfire. On the other hand, defined sick and vacation leave give employees clarity and comfort. Thoughtful leave policies signal genuine care for employee well-being and prevent presenteeism.

9. Empower to Exit

The best way to retain people is to prepare them for their next chapter.

The healthiest organizations do not fear attrition, they prepare employees for their next chapter. Leaders who invest in skill-building, provide meaningful work, and enable career growth find that employees actually stay longer. When people know they will leave stronger than they came, they feel respected and motivated. Empowering employees to exit often becomes the very reason they choose to stay.

10. Single Buddy Outside the Team

Beyond formal HR processes, employees benefit from having a buddy who is not part of their immediate team or reporting chain. This creates a safe and informal space for questions, cultural guidance, and general support. Organizations that implement buddy systems often see faster integration of new hires and a stronger sense of belonging across departments. This single buddy is not a replacement for HR, but a human connection that helps employees navigate their journey.

Final Thought

Employee well-being is not achieved through slogans or one-time initiatives. It is built through clarity, fairness, trust, and consistent practices. These 10 simple approaches, when embraced as a philosophy, create an environment where employees do not just work - they thrive. And when employees thrive, organisations inevitably follow.

The question every leader should ask is simple: are we creating a workplace where people feel genuinely cared for?

If you are a leader, reflect on which of these practices already exist in your organization and which need attention. If you are an employee, share what works best for you - your perspective might just inspire the next wave of positive change in your workplace.

For this part, I chose K3s, and in this post, I’ll walk through how I got it running, validated it, and prepared it for secure workload deployment with SSL automation.

Why K3s?

K3s is a minimal, certified Kubernetes distribution built for production use in resource-constrained environments. It was designed by Rancher Labs and has the following advantages for my setup:

• Lightweight: Small binary (~100MB), fewer moving parts

• Single binary: Bundles kubelet, kube-proxy, containerd, and more

• Reduced memory footprint: Great for a single-node environment

• Embedded SQLite by default: Eliminates the need for a separate etcd setup

• Faster provisioning: I got a working control plane in under 2 minutes

Since I’m running this on a dedicated Hetzner bare metal node, I didn’t need a full-scale Kubernetes install with HA components.

Step 1: Installing K3s (Single Node)

I followed the official quick start guide for a basic single-node installation.

curl -sfL https://get.k3s.io | sh -

After a few seconds, the node was up and running with a fully functional Kubernetes API.

K3s installs the kubeconfig at /etc/rancher/k3s/k3s.yaml. I copied it to my home directory for ease of use:

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $(id -u):$(id -g) ~/.kube/config

Step 2: Validating the K3s Cluster

To confirm that the cluster was functioning properly, I ran:

kubectl get nodes kubectl get pods --all-namespaces

The output showed the single node in Ready state, and all system pods running smoothly. Since I installed K3s behind VPN access, all kubectl operations ran through the private tunnel.

Step 3: Identifying the Private CNI IP

K3s uses flannel as the default CNI. Each node gets a private overlay network IP, which is critical for routing internal service-to-service traffic securely.

To fetch the node’s CNI IP:

ip -o -4 addr show | grep flannel

This IP is different from the public server IP or even the VPN IP – it’s the overlay network IP, which I’ll use for all future secure communication between internal services.

Step 4: Verifying kubectl and helm

kubectl comes pre-installed with K3s. To install helm, I used:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

And confirmed it was working:

helm version

At this point, I had both cluster access (kubectl) and package management (helm) ready to go.

Step 5: Installing cert-manager Using Helm

To automate TLS certificate management in the cluster, I installed cert-manager, which supports Let’s Encrypt and other issuers via ACME.

kubectl create namespace cert-manager

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v1.14.2 \
  --set installCRDs=true

I waited for all pods in cert-manager namespace to become Running:

kubectl get pods -n cert-manager

cert-manager gives me the ability to generate SSL certificates – both wildcard and standalone – using DNS01 challenge mode, ideal for clusters without public ingress or open ports.

What’s Next

Now that the cluster is up and cert-manager is installed, the next step is to:

• Create a ClusterIssuer using Let’s Encrypt

• Generate wildcard SSL certificates for a sample domain

• Deploy workloads into the cluster with valid TLS termination

That’s coming up in Part 4.

References

• K3s Quick Start Guide: https://docs.k3s.io/quick-start/

• cert-manager Documentation: https://cert-manager.io/docs/

• Helm Installation: https://helm.sh/docs/intro/install/

Why Isn’t Succession Planning a Priority?

Let’s be honest: succession planning feels uncomfortable. There’s a subconscious fear it might be seen as grooming your replacement or admitting you aren’t indispensable. Often, the pace of IT work is so relentless that discussions about the future take a backseat to the demands of today. Many of us aren’t taught how to do it, and we assume we’ll “cross that bridge when we get there.” The reality is, if we wait until we need a successor, we’re already too late.

The Value of Succession Planning

What changed my perspective? I started seeing how disruptive unexpected absences - resignations, unplanned leaves due to illnesses, or even just taking a week off - could be. With succession planning:

• Teams keep momentum when key people leave

• Projects are less likely to stall during transitions

• There’s greater trust from both team members and upper management

Instead of scrambling in a crisis, we prepare the ground for stable performance no matter who holds the title.

How I Approach Succession Planning

1. Identify High Potential Talent Early: I pay attention to those who show initiative beyond their role, have empathy, and are constantly learning.

2. Delegate Real Responsibilities: Instead of delegating only tasks, I delegate decision-making. It’s uncomfortable at first, but it’s the only way to let people grow.

3. Cross-Train Whenever Possible: I encourage team members to learn each other’s “day jobs” to build resilience within the team.

4. Create Safe Spaces for Experimentation: I let potential leaders lead smaller projects or handle meetings. If they stumble, I provide feedback in private and support in public.

Personal Benefits: Delegation, Balance, and Peace

Succession planning doesn’t just help the company - it transforms my own work life:

• Delegation comes naturally when I see people are ready and willing to step up.

• Work-life balance improves, because I’m not the bottleneck for every decision. I can actually take a vacation (and not check my email every hour!).

• Work becomes peaceful. I don’t operate from a place of fear. When difficulties arise, there’s confidence that the team can weather the storm - and that’s liberating.

Accountability and Ownership

When I invest in succession planning, I make it part of everyone’s job description - not just mine. I challenge my reports to identify who could replace them if needed. This culture of accountability strengthens the team’s sense of ownership. No one coasts. We understand that part of our legacy is leaving things better for those who come after.

The Importance of Teams, Delegation, and Backing Each Other

The IT world is complex and moves fast. No one person has all the answers. That’s why building a strong team, where roles overlap and people step up for each other, is non-negotiable. Effective delegation preserves sanity and drives innovation by empowering diverse voices. But delegation isn’t about abandonment - it’s about standing behind your team. When things go wrong (and they will), I back my team publicly and solve issues privately. That’s how deep trust is built.

Final Thoughts:

Succession planning forces us to think beyond our to-do lists and daily emergencies. It’s about building a legacy, not just a function. By investing in people, embracing delegation, and fostering true team cohesion, I’ve found more satisfaction in my own role - and set my team up to thrive, whether I’m here or not.

As someone who’s mentored dozens of engineers through this transition, let me share some honest, experience-backed advice on what it really means to be an engineering manager, especially in those crucial first couple of years.

Understanding the Role

First, let’s get clear on what an engineering manager (EM) is - and isn’t.

An EM is not the “boss” of the team in the traditional sense. You’re not there to hand out tasks or watch over shoulders. You’re there to enable, guide, and amplify. Your role is to help your team deliver software effectively while making sure they grow, stay engaged, and feel fulfilled in their work.

You still use your technical background - make no mistake. But instead of writing code all day, you’re thinking about how to build an environment where others can write great code consistently. You’re connecting dots, removing roadblocks, managing expectations, and nurturing talent.

What You’ll Actually Be Doing

Most new managers are surprised by how different the day-to-day looks. If you’re moving into management expecting to still do a lot of coding, you might want to hit pause.

Your calendar will soon be filled with 1:1s, planning meetings, hiring interviews, feedback sessions, and cross-functional syncs. These aren’t distractions from the job - they are the job. One-on-one meetings, for example, become a critical ritual. They’re where you listen to your team’s concerns, understand their aspirations, catch early signs of burnout or disengagement, and offer feedback. They aren’t status updates - they’re where trust is built, and people problems are solved before they escalate.

You’ll also spend a good deal of energy coordinating delivery. That doesn’t mean breathing down engineers’ necks for ETAs - it means helping teams plan realistically, protecting focus time, ensuring dependencies are clear, and making sure quality doesn’t suffer under pressure. It’s a subtle art of balancing business urgency with engineering discipline.

When Should You Consider Becoming an Engineering Manager?

I often see engineers lured into management because it seems like the “next step” in the ladder. But it’s not a promotion - it’s a pivot. The best time to make this shift is when you’re already showing signs of informal leadership: mentoring juniors, taking initiative to fix processes, influencing team direction, and stepping up during crises.

If you enjoy helping people unblock themselves more than solving the problem yourself, or if you find yourself gravitating toward team health and product clarity, it’s a good sign you’re ready. On the other hand, if you’re still deeply in love with the technical depth of your craft - and that’s perfectly valid - you may not want to give up the hands-on aspect just yet.

The Foundation You’ll Need

To make a successful transition, you’ll need a few solid foundations. First, your technical credibility must be established. You don’t need to be the smartest engineer in the room, but your team needs to trust your judgment. You’ll still be reviewing designs, guiding architectural decisions, and occasionally getting into the weeds.

Second, communication becomes your superpower. You’ll write more docs, send more Slack/Teams messages, and have more conversations than you ever did as an IC. The ability to communicate clearly, empathetically, and persuasively is what separates good EMs from great ones.

Third, you need emotional intelligence. You’ll be navigating career aspirations, interpersonal conflicts, and sometimes personal issues. Being calm, fair, and empathetic under pressure becomes part of your daily job description.

Is It a One-Way Door?

A common fear among new managers is, “What if I hate it? Can I go back?”

The short answer: Yes, you can. It’s not a one-way door, but it does get harder the longer you stay in management. Skills atrophy. Tech moves fast. That said, many companies today support dual tracks, and a move from EM back to a senior IC role like Staff Engineer or Architect is increasingly common.

Still, you should give management a genuine shot - ideally 12 to 18 months - before making that call. The first six months can be disorienting. You won’t get the same dopamine rush from shipping a PR, and you’ll sometimes feel invisible. But with time, the satisfaction shifts: from personal wins to team wins.

How Is Your Success Measured?

You may wonder how you’ll know you’re doing well.

Unlike engineering, where outcomes are visible in code and features, management impact is fuzzier. But there are ways to measure effectiveness. Do people on your team feel psychologically safe and supported? Are they growing in their roles? Are you hitting delivery targets without burning people out? Are you contributing to org-wide hiring and process improvements?

Your key result areas might include team velocity, quality metrics, team retention, engagement survey results, or even stakeholder satisfaction. But more than numbers, it’s the health of your team - both emotional and operational - that tells your story.

Taking Time to Reflect

You’ll need to build a regular habit of reflection. Just like we hold sprint retros to inspect and adapt, you should do the same with your leadership style. What’s working? Where did you miss the mark? What’s the feedback you’re hearing (or not hearing)?

Keep a journal, seek feedback from your team and peers, and watch your blind spots. Self-awareness is one of the most underrated traits in management.

Building the Next Generation of Leaders

One of the most fulfilling parts of being an EM is grooming future leaders. Spotting potential, giving someone a chance to lead a project, coaching them through tough calls - this is where you move from being a manager to a multiplier.

Invest in your team’s growth. Create space for them to experiment, fail, and learn. Share context, not just instructions. And most importantly, be transparent about what management really involves - so they can make an informed choice when their time comes.

Parting Words

The transition to engineering management is equal parts exciting and overwhelming. It’s a role that demands patience, resilience, and humility. But it also offers unmatched opportunities to shape culture, drive impact, and make a lasting difference - not just in the codebase, but in people’s lives.

You won’t get everything right, and that’s okay. What matters is that you’re committed to learning, listening, and growing every day. If that sounds like a challenge you’re up for, then welcome aboard. The journey won’t be easy - but it will be worth it.

This post covers the setup in detail using Pritunl and both WireGuard and OpenVPN (TCP) as VPN protocols.

Why a Private VPN?

The moment a server is exposed to the internet, it becomes a target. Port scans, SSH brute force attempts, and other forms of probing happen within minutes.

Instead of relying on IP whitelisting or hoping SSH holds up under attack, I decided to:

• Completely block SSH from the public internet

• Funnel all admin access through a secure VPN

• Treat the VPN as the only entry point into the private cluster

This effectively air-gaps the node, while I still retain complete control.

Pritunl vs. OpenVPN OSS

I considered setting up OpenVPN manually, but Pritunl turned out to be a better choice for my goals.

OpenVPN (OSS):

• Fully CLI driven

• Flexible but complex

• Requires manual management of certs, keys, users, and routes

Pritunl:

• Clean web interface

• Built-in support for both WireGuard and OpenVPN

• Handles user and certificate management

• Easy to scale if I add more nodes later

For a single-node private cluster, the free version of Pritunl was more than sufficient.

Protocol Strategy: WireGuard + OpenVPN TCP

I chose to enable both WireGuard and OpenVPN over TCP for flexibility.

Why both?

• WireGuard: Fast, modern, and simple. Great for low-latency access from personal devices.

• OpenVPN over TCP: More resilient in restrictive environments (hotels, corporate networks) that block UDP.

Port Security Tip:

Both protocols use well-known default ports:

• WireGuard default: 51820/udp

• OpenVPN default: 1194/tcp

I changed both to non-standard high ports to reduce noise from bots and scanners:

• WireGuard: 51234/udp

• OpenVPN TCP: 14444/tcp

This helps minimise automated scans and random login attempts.

Installing Pritunl on Ubuntu 24.04

I followed the official instructions to install Pritunl and MongoDB

# Add repository

echo "deb https://repo.pritunl.com/stable/apt jammy main" | sudo tee /etc/apt/sources.list.d/pritunl.list

sudo apt install gnupg
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv-keys 7568D9BB55FF9E5287D586017AE645C0CF8E292A

# Install packages
sudo apt update
sudo apt install pritunl mongodb-org -y

# Start services
sudo systemctl enable mongod pritunl
sudo systemctl start mongod pritunl

After installation, the web dashboard was available at https://<your-server-public-ip>.

Changing Pritunl Dashboard Port

To avoid default port-based attacks, I changed the Pritunl dashboard port from 443 to something like 14443.

This can be done in the dashboard under Settings > Port.

Configuring Pritunl

Here’s how I set it up after logging in using the setup key:

sudo pritunl setup-key

Configuration steps:

1. Change admin password on first login

2. Create an Organization

3. Create a Server by enabling

   1. WireGuard (port 51234/udp)

   2. OpenVPN TCP (port 14444/tcp)

4. Add Users under the organization

5. Configure Routes as required

Important: Remove 0.0.0.0/0 Route

By default, Pritunl adds a full-tunnel route (0.0.0.0/0) which sends all your internet traffic through the VPN. I deleted this to avoid:

• Slowdowns in general internet browsing

• DNS leaks and latency issues

• Wasting Hetzner bandwidth

I only kept routes to the internal VPN subnet, like 192.168.100.0/24 (check your internal VPN subnet in Pritunl Dashboard under Servers, this is only an example)

Hetzner Firewall Configuration

Hetzner’s robot stateless firewall is easy to use and quite effective. I used it to block everything except:

• WireGuard port: 51234/udp

• OpenVPN TCP port: 14444/tcp

• Pritunl dashboard port: 14443/tcp (allowed only from my ISP IP)

I completely blocked port 22 to enforce VPN-only SSH access.

Testing Access

After configuring and downloading the VPN profiles, I connected and tested SSH:

ssh root@192.168.100.1 #Use your VPN Server subnet first IP

Both protocols worked as expected. I now access the server only via VPN, with no open public ports other than the ones explicitly allowed.

What’s Next

Now that the server is secure and accessible only through private VPN tunnels, I’ll move on to setting up a K3s Kubernetes cluster.

In Part 3, I’ll walk through installing K3s, initialising the cluster, deploying workloads, and integrating it with monitoring and CI/CD tools.

Stay tuned.

References

• Pritunl Documentation: https://docs.pritunl.com

• Hetzner Firewalls: https://docs.hetzner.com/robot/dedicated-server/firewall/

• WireGuard Overview: https://www.wireguard.com/

• OpenVPN Protocol Info: https://openvpn.net/

In this first part of the series, I’ll walk through:

• Procuring a bare metal server via Hetzner’s auction

• Getting through the verification (KYC) process

• Choosing the right payment method

• Securing login via SSH keys

• Picking the right OS and data center

• A teaser for what’s coming next

Step 1: Buy a Server from Hetzner Auction

Hetzner’s server auction is a hidden gem. I’ve found some seriously capable machines at great prices compared to their regular offerings.

Recommended spec for a private cluster node:

• CPU: Intel Xeon (e.g., E5-2670 v3 or better)

• Memory: 128 GB ECC DDR4

• Storage: 2 x 240 GB SSD in RAID 1 (for redundancy)

• Network: 1 Gbps port

These machines are more than enough for running a Kubernetes master, CI/CD jobs, or small VM clusters. Keep in mind that the auction servers are used or refurbished, but they’re tested and quite reliable.

Step 2: Account Verification (KYC for Indian Customers)

Before I could start using the server, Hetzner asked for identity verification. As an Indian customer, I had to go through their KYC process. This included:

• Uploading a government-issued ID

• Submitting address proof (like a utility bill or bank statement)

• Sometimes recording a short video or selfie for verification

This is covered in Hetzner’s account verification documentation.

Note: The process can take anywhere from 24 to 72 hours. It may take longer on weekends or if the documents need manual review, so it’s best to factor that into your setup timeline.

Step 3: Payment Methods

Hetzner supports multiple payment options:

• Credit or debit cards

• PayPal

• BitPay (for crypto payments)

For my use case, using an international credit card made the most sense. It allows automatic billing every month, which saves me from having to track due dates or process manual payments.

Step 4: Use SSH Key Authentication

Once the server was provisioned, I used SSH key-based authentication to log in. It’s more secure than using passwords and eliminates the risk of brute-force attacks.

To generate a key:

ssh-keygen -t ed25519 -C "your_email@example.com"

I added the public key to Hetzner when I was setting up the server. If you missed it during provisioning, it is easy to add later via the console interface.

Step 5: Choose the Right OS and Data Center

I went with Ubuntu 24.04 LTS for the OS. It’s stable, current, and has wide support across all the tools I plan to use.

For the data center location, I considered network latency and regional performance. My top picks:

• Helsinki (FSN1) – great for workloads targeting Europe and India

• Singapore (SGP1) – better if most traffic is Asia-Pacific based

The location you choose can affect latency and bandwidth, so it’s worth aligning with your traffic pattern.

What’s Next

Now that the server is ready and secured, I’ll move on to setting up a private VPN endpoint that effectively air-gaps the node from the public internet.

In the next part of this series, I’ll cover that setup in detail - including how I configured a secure, private access tunnel and locked down all external exposure.

Stay tuned for Part 2.