I did not get hired as a director of web development.

I got hired as the IT guy.

My job description was all the usual stuff: Azure AD, laptops, VPN, M365, putting out whatever fire decided to wake up that morning. If you looked at my title on paper, you would never guess I would end up owning the company website, the brand experience, and half of marketing’s nervous system.

But that is exactly what happened, one “quick website change” at a time.

This is the story of how I fell into that role, and what I learned about accidentally promoting yourself by being the only one who actually owns a system.

Step 1: “Hey, You’re Good With Computers, Right?”

It did not start with some big formal project.

It started with stuff like:

“Hey, can you update this headshot on the website?”
“Can you swap this logo?”
“Can you add this new service under ‘Capabilities’?”

We had an old site running on WordPress / WP Engine. It had been touched by a mix of agencies, contractors, and “someone who used to work here.” No one really owned it. There were plugins no one understood, pages no one wanted to update, and a bunch of half-finished ideas buried in drafts.

So naturally, it got handed to the IT person.

At first it felt like just another ticket queue:

• Fix this broken link
• Replace this PDF
• Add this partner logo
• Tweak this form

But every time I opened the backend, I noticed more:

• Pages that did not match the current messaging
• Forms that did not go anywhere useful
• Layouts that looked like 2012 landed in the middle of 2024

I could have stayed in “just change the thing they asked for” mode. Click, save, ticket closed.

Instead, my brain did the annoying thing it always does and started asking:

“Why does it look like this?”
“Who is this page even for?”
“Does anyone know if this layout actually works?”

That was the moment the job quietly stopped being “website updates” and started turning into “web development.”

Step 2: Inheriting A Frakenstein Site

If you have ever inherited a corporate site, you know the vibe.

Different page builders welded together. Old agency templates living next to default WordPress themes. CSS band-aids stacked on top of each other. Plugins doing god knows what.

I started by trying to understand what we were actually working with:

• How many templates are we using?
• What plugins are critical vs “someone installed this once and forgot”?
• Which forms feed which tools - HubSpot, email, a black hole?
• Which pages get traffic and which are dead zones?

On paper I was still “IT guy who updates the website,” but day by day I was becoming the only person who actually had a mental model of how the site worked.

Marketing knew what they wanted to say.
Leadership knew they wanted it to “look better, more modern.”
But nobody could answer basic questions like:

“What happens when a lead fills out this form?”
“Which pages matter most for our message?”
“Who approves changes to the homepage hero?”

So I started quietly documenting:

• Which pages mapped to which services
• Where each form submitted data
• How the navigation tied to our actual offering
• What broke the layout on mobile vs desktop

That documentation became my unofficial job description.

Step 3: The “We Need This Live By Friday” Moment

Every accidental promotion story has a turning point.

Ours looked like: “We have an event next week and the site needs to reflect it.”

New messaging. New hero. New callouts. Updated branding. And of course, it all needed to be live “in time for Datadog” - with a timeline that did not care what the current tech stack looked like.

The old WP Engine setup could technically be forced into shape, but every change felt like wrestling the site instead of working with it.

That is when the idea of a rebuild stopped being “nice to have someday” and started looking like “we are wasting more time patching this than it would take to build it right.”

So we made the call: move to Webflow, rebuild the site with:

• A consistent design system
• Clean CMS collections for services, case studies, blogs, etc
• Built-in responsive layouts instead of plugin roulette
• Easier hooks for things like HubSpot forms and analytics

The scope jumped from “change a few pages” to “own the entire rebuild and migration.”

No one said “you are now director of web development.”
They said “can you handle the website?”

Same thing.

Step 4: From Pages To Products

Rebuilding the site in Webflow flipped a switch.

Suddenly we were not just “editing pages,” we were designing a product:

• Defining how services are structured
• Designing the flow from homepage to contact
• Making sure messaging is consistent across the whole site
• Making it easy to spin up new pages without breaking everything

We wired in:

• HubSpot forms where we actually wanted to capture leads
• Analytics so we could track what people clicked instead of guessing
• Cleaner navigation so buyers could actually find the thing they cared about

Every request started coming to me first:

• “Can we add this new offering?”
• “Can we create a landing page for this campaign?”
• “Can we highlight this case study?”

At some point I realized - I was no longer just the person with the password to the site. I was acting as:

• Product owner for the website
• Front-end dev and CMS architect
• Casual brand cop making sure things stayed consistent

Nobody formally handed me that role. I got it because I was the one person who could answer:

“How does this fit into the site without breaking everything?”

Step 5: The Day-To-Day Shift

On paper, my title did not change overnight. In reality, my day did.

A “normal” morning went from:

• VPN issues
• Laptop imaging
• “I can’t sign into Teams”

To something more like:

• Two website change requests from leadership
• A marketing idea for a new resource or landing page
• A Slack ping about “can we track X in analytics?”
• An IT thing about DNS or SSL for a new subdomain

It was still IT flavored, but my brain was living in a different place:

• Thinking about layout, not just uptime
• Thinking about conversion paths, not just CNAME records
• Thinking about how a new page would scale with the rest of the CMS

I started keeping a backlog for the website the same way dev teams treat an app:

• Bugs: layout glitches, mobile issues, forms not behaving
• Improvements: better copy, clearer CTAs, simpler nav
• Features: interactive components, new content types, new sections

Once you treat the website like a product, it becomes really obvious that someone needs to be responsible for its roadmap.

Congratulations, that someone is you.

Step 6: Owning It Changes How People Talk To You

The more I owned the site, the more people started involving me earlier.

Instead of:

“Hey, we need a page for this, can you build it today?”

It became:

“We’re thinking about launching this thing. How should we represent it on the site?”

Instead of:

“Marketing made this page in a vacuum, can you hook it up?”

It became:

“Can you help us structure this in the CMS so it’s easy to maintain?”

That shift is subtle, but it is everything.

You are no longer the person asked to push pixels around. You are the person people talk to when they want to make sure something fits the overall digital story.

That is basically what “director of web development” actually is in a smaller company:

• You understand the tech stack
• You understand the brand and messaging
• You understand how buyers will interact with the site
• You keep all of that coherent over time

The org chart might still say “IT” or “Specialist” for a while. But functionally, you are already doing the job.

Step 7: How To Intentionally “Accidentally” Promote Yourself

If you are in IT or a generalist role and you want to slide into something like “director of web development,” here is the pattern I would copy on purpose:

1. Take the “annoying” system nobody owns
   • The website
   • The intranet
   • The ticketing system
   • The knowledge base
2. Learn it deeper than anyone else
   • How it is built
   • Where it breaks
   • How data flows through it
3. Start thinking like an owner, not a technician
   • Keep a backlog
   • Document decisions
   • Standardize patterns (templates, components, naming)
4. Tie your work to outcomes
   • “We launched this new layout in time for the event”
   • “Form completion went up after we simplified this flow”
   • “Marketing can now spin up new pages without dev help because of this CMS structure”
5. Then, when you talk about your role, stop underselling it
   • Not “I make website changes”
   • Try “I own our company’s web platform and handle architecture, implementation, and ongoing improvements for the site”

The title often comes last. The responsibility shows up first.

Closing It Out

I did not wake up one day and say “I want to be director of web development.”

I said “sure, I’ll fix that broken page,” and then I never stopped asking why the page was broken, who it was for, and how the whole thing could be better.

If you are the one person who:

• Understands how the site is wired
• Keeps it from breaking
• Makes it easier for everyone else to use
• Connects the tech to the message

You are already doing more than “keeping the lights on.” You are quietly running the front door of the company.

Call it whatever you want.

But if you are going to carry that much responsibility, you might as well start talking - and being paid - like the director you already are.

‍