🌱 Leading Through Community: Best Practices for Modern Product & Tooling Leaders (With Personal Stories From the Field)

When people ask me what I do, I used to answer in simple terms:
“I manage engineering tools” or “I drive AI adoption.”

That was the safe, straightforward version.

But the truth — the real, lived truth — is much more human than that.

I enable people.
I build capability.
I shape culture.
I help teams adopt modern practices in ways that feel safe, shared, and sustainable.

 

And I learned all of this not from frameworks or certifications — but from real people, real challenges, and real conversations inside TDCNET.

Here are the best practices I’ve learned as a product and tooling leader — told through the stories that shaped them.

 

🧭 1. Tools Don’t Transform Organizations — Communities Do

A few months ago, during a conversation with one of our engineers, he said:

“We want to do things the right way… but every team is doing things differently.”

That moment landed hard.

It reminded me of my early career in the Philippines, leading BPO teams where processes looked uniform on paper — but execution depended entirely on people supporting each other. We fixed things not by rewriting SOPs, but by gathering teams, sharing patterns, and lifting each other up.

Decades later, in Denmark, leading tooling and DevOps modernization, the pattern is exactly the same:

True transformation happens when people learn and grow together.

Best practice:

Build a community around the work — it scales change faster than any tool ever will.


🤝 2. Treat Community as a Product — Not an Afterthought

When I began shaping the DevOps Community, I approached it the same way I approach any product:

  • Who are the users?
  • What do they struggle with?
  • What value can we deliver?
  • What will success look like?

This mindset shift happened because of a conversation with a platform engineer who said:

“I just want a place where I can learn what other teams are doing. We shouldn’t be reinventing everything in isolation.”

That was the moment I realized:
The DevOps Community isn't a side project — it is a platform.

Best practice:

Treat the community as a product with users, outcomes, and a vision.
It becomes a living space, not a mailing list.


📣 3. Collaboration Isn’t a Luxury — It’s a Survival Skill

One of the most telling moments came when two teams discovered they had built the exact same automation pipeline — separately.

Same logic.
Same triggers.
Same pain points.
Same solution.
Zero visibility into each other’s work.

When they finally talked, both teams laughed and said:

“We could have saved weeks if we had talked earlier.”

That conversation became the seed for community demos, monthly meetups, and shared patterns.

Best practice:

Create intentional spaces where engineering, Ops, architecture, QA, security, and product talk with each other, not around each other.


🔄 4. Enable, Don’t Enforce

As a tooling manager, there is a temptation to publish guidelines and hope they drive alignment.

They don’t.

People follow what they understand, trust, and co‑create.

A breakthrough moment came when a senior engineer said:

“I’ll follow any standard… as long as I’m part of shaping it.”

That completely reframed my approach.

Now, standards are co-created based on real-world patterns, not directives. And adoption skyrocketed.

Best practice:

Bring people into the design of standards — alignment becomes natural instead of forced.


🧠 5. Build Psychological Safety First, Expertise Second

In one of our early DevOps sessions, someone shared a “failed deployment story” — nervously.
They expected blame.

Instead, the room leaned in. We discussed learnings. The tension disappeared.

Then something surprising happened.

More people began sharing. More hands went up.
The room felt lighter.
Safer.
Human.

That was the moment I realized:

Communities are technical spaces built on human foundations.

Best practice:

Create a no‑blame environment where people can share openly.
Innovation only happens where people feel safe.


🧱 6. Build Capability, Not Just Competency

When you come from a global background — from the Philippines to Australia to the Nordics — you learn one thing early:
Skills get you hired, but capability lets you thrive.

Capability is:

  • confidence
  • curiosity
  • adaptability
  • culture
  • mindset

This is why partnerships with HR Academy, Security, and Privacy matter.
Because maturity isn’t just technical — it’s cultural.

Best practice:

Invest in learning pathways, hands-on labs, workshops, and pairing.
Tools evolve; capability endures.


📊 7. Use Community as Your Product Discovery Engine

One of the most productive feedback loops I’ve seen happened during a casual conversation after a session. A colleague said:

“We love GitLab, but we need a better way to standardize pipelines.”

That single sentence turned into:

  • a community-wide pattern
  • a reusable template
  • documentation
  • and an improvement to how teams deliver

The powerful thing?
It wasn’t a roadmap item.
It wasn’t formally requested.
It came from community conversation.

Best practice:

Listen not only to what people say in meetings — listen to what they say when they feel comfortable.


💛 8. Lead With Humanity (Your Most Powerful Tool)

As a Filipina leader working across continents, my leadership style has always been shaped by empathy, encouragement, and community spirit. In Denmark, where flat structures and trust-driven culture thrive, this translated beautifully.

Some of the most meaningful product leadership moments were:

  • encouraging a shy engineer to present for the first time
  • mentoring someone through their first automation build
  • helping teams navigate uncertainty during migration
  • creating spaces where people feel seen, heard, and supported

This is what leadership looks like today.

Best practice:

Lead as a human first, product leader second.
People follow leaders who make them feel capable, not controlled.


🌼 Final Reflection: The Human Layer Is the Real Engine of Change

If there’s one thing I’ve learned across my global career — from Manila to Melbourne to Aarhus — it is this:

Technology moves fast.
Tools change every year.
But people, culture, and community determine whether transformation succeeds or fails.

Leading a DevOps Community isn’t outside my role.
It is the heart of my role — because it brings people together around a shared mission:

Better engineering. Better collaboration. Better outcomes.
For everyone.

And ultimately, that is the work I want to be doing.
Not just managing tools — but enabling people.

 

Rating: 0 stars
0 votes

Add comment

Comments

There are no comments yet.