Engineering management for WordPress teams

Leading WordPress developers is a special sport. The platform is approachable enough that everyone has opinions. It is also complex enough that bad opinions still compile, still deploy, and still create support tickets three months later.

I currently work as a team lead and senior WordPress developer at Digital Six in Australia, and I lead a team of 10. Before that I led delivery on high traffic university WordPress work with Hybrid in the UK. The job title changes. The core problem does not: how do you ship without turning the codebase into a museum of shortcuts?

What technical leadership is not

It is not being the fastest typist in the room. It is not collecting meetings like merit badges. It is not rewriting every pull request because your ego wants uniform style more than the business wants progress.

Leadership is subtraction and protection. Subtract unclear tickets. Subtract hero culture. Subtract the meeting that could have been a written decision. Protect the architecture, the estimates, and the people doing the work.

The WordPress specific failure modes

Generic engineering advice helps, but WordPress teams fail in familiar ways:

• Plugin soup with no ownership boundaries
• “Just put it in the theme functions file” as an architecture strategy
• Page builder debt described as agility
• Staging environments that look nothing like production
• Estimates based on demo speed instead of integration reality
• Juniors praised for shipping fast while seniors quietly clean up the blast radius

If you lead a WordPress team and you are not watching for those, you are managing activity, not engineering.

Practices that scale past five people

When the team grows toward double digits, memory stops being a system. You need rails.

1. Written decisions for non trivial changes

If a change touches data models, caching, auth, or shared templates, write a short decision note. Not a novel. A page that says: problem, options, choice, risks, rollback. Future you will thank present you.

2. Reviews that teach

Code review is not a courtroom. It is apprenticeship with a diff. I ask reviewers to explain the why, not only the nit. I also ask authors to summarize risk. If nobody can explain the risk, the change is not ready.

3. Staging that is not a surprise

Staging should embarrass you before production does. Same major PHP. Same object cache posture where possible. Same critical plugins. Fake staging creates fake confidence.

4. Estimates that respect physics

Clients want dates. Agencies want utilization. Code wants physics. Leadership is negotiating those three without lying to any of them. I would rather reopen scope than invent a fantasy timeline that burns the team.

How I run delivery without becoming a meeting

Async first. Overlap windows second. Meetings only when a decision needs faces.

A healthy week for us usually includes:

• A short written weekly plan per workstream
• Pull request review SLAs that people actually honor
• One technical sync for blockers, not status theater
• A release checklist owned by someone named, not “the team”

Remote work from Kathmandu with Australian, UK, and US stakeholders only works if writing is treated as infrastructure. If it is not written, it is not decided.

Protecting juniors from the platform

WordPress makes it easy to succeed locally and fail in production. Juniors need guardrails:

• Clear plugin vs theme ownership
• Examples of good ACF field groups and template patterns
• A performance checklist before calling a page “done”
• Permission to say “I do not know” without punishment

My job is to make juniors dangerous in the good way: able to ship, able to question, able to leave the codebase better than they found it.

When to say no

Saying no is part of the job. No to packing five features into a sprint that already has a migration. No to installing a plugin that duplicates what you already maintain. No to “quick Elementor page” on a platform whose performance budget is already on fire.

A useful no always includes a path: not this, because of that, here is the alternative that still moves the business.

What good looks like

A well led WordPress team feels calm in public and sharp in private. Releases are boring. Reviews are direct. Estimates are imperfect but honest. The codebase has fewer secret doors. Clients feel progress without needing a war room.

That is the bar. Not more dashboards. Not more standups. Better systems, clearer ownership, and a team that can still laugh on Friday because production did not become a personality test.