• People-Centered Leadership During a Department Merger

    People-Centered Leadership During a Department Merger

    When I was promoted to Head of Production, my first assignment was to merge the production and delivery teams, reduce headcount from eight to four, and cut costs by 65%. The task wasn’t purely operational. The two teams had been built in parallel, had little coordination between them, and didn’t yet trust each other. Or me.

    The challenge

    Production had mature systems and strong process ownership. Delivery relied on institutional knowledge and ad hoc communication. Both were working toward the same client outcomes, but the overlap created redundancy, delayed handoffs, and blurred accountability across every stage.

    Morale was fragile. People didn’t know what the merger meant for their roles. I needed to run a process that was fair, transparent, and took the human side of a difficult decision seriously.

    Designing a fair selection process

    To make the process credible, I proposed including candidates from other departments to widen the evaluation pool and reduce perceived bias. I asked the People & Culture Manager to be involved from the start, both to validate the process and to serve as a point of support for anyone with concerns.

    I built an interview framework with a structured questionnaire and a scoring rubric assessing performance, potential, and fit with the new team’s direction. Then I personally conducted ten one-on-one interviews, gathering not just performance data but each person’s perspective, strengths, and what they’d need to succeed.

    The goal was to build the right team for what we needed next. Performance data was one input. Context and potential were the others.

    Onboarding and offboarding with care

    For departing team members, I developed individual offboarding plans, drafted communications, and coordinated closely with People & Culture so no one was left uncertain about what came next.

    For the new merged team, especially former delivery team members whose processes had never been documented, I ran hands-on training sessions. We walked through updated workflows, built new SOPs together, and made sure everyone understood the reasoning behind the changes, not just the changes themselves.

    I was aware of how I might be perceived: coming in, taking over, and replacing their former lead. So I didn’t assert authority. I asked what they were doing, what they thought could work better, and committed to adjusting my approach where their process was stronger. By the end of the transition, some of the same people who had initially felt sidelined were among the most engaged on the team. That shift from guarded skepticism to genuine ownership was the clearest measure I had that the approach had worked.

    Unifying the workflows

    Merging the teams required more than reorganizing roles. The two teams had operated from separate ClickUp folders with different standards. I redesigned both into a unified system with updated SOPs, reworked automations, and clearer handoffs at every stage.

    I introduced a client journey tracker in ClickUp that gave cross-departmental visibility into where every piece of content stood and who owned each stage. It shifted the culture away from finger-pointing and toward identifying and fixing root causes.

    I also co-developed a strike policy with other department leaders to create shared accountability standards across teams, not just within production.

    Turnaround time dropped from 33 days to 21. Departmental costs fell by 65%. Productivity was back to 100% within the first month.

    Looking back

    This merger taught me something I’d suspected but hadn’t tested at this scale: the way you handle change matters more than the speed of it.

    The team I inherited was uncertain and skeptical. The team I handed off was focused and collaborative. That difference came from how consistently I told people the truth about what was happening, made space for their questions, and followed through on what I said I’d do. Structure helps. It doesn’t build trust on its own.

    Clarity, in the end, is a form of care.

  • Operational Leadership During Organizational Change

    Operational Leadership During Organizational Change

    When I was promoted to Production Manager at Codeless, the role didn’t yet exist in any formal structure. The company had more than 30 active clients and 45 team members, but no clear ownership over how content moved from brief to delivery. Work got done, but inconsistently. I’d seen where the gaps were from two prior roles and had specific ideas about how to fix them.

    Proactively shaping my role

    The Content Production Specialist role was my idea. While working as Operations Strategist, I’d been documenting SOPs and mapping workflows, and the same bottlenecks kept appearing. Everyone could see them. No one owned fixing them.

    I drafted a role proposal: the responsibilities, the workflows it would own, and the kind of person who’d succeed in it. Leadership approved it. What I hadn’t anticipated was being asked to lead a newly formed team. That unexpected promotion became the starting point for everything that followed.

    Leading through change

    Within months of stepping into the role, things got complicated. My direct manager resigned unexpectedly, which caused uncertainty across the team. On top of that, budget constraints required repositioning team members and eventually reducing headcount significantly. I was making hard personnel decisions before I’d fully found my footing as a manager.

    My response was to stabilize through structure. I introduced centralized team pages in ClickUp, personal OKR dashboards, and new systems for feedback and performance reviews. I increased cross-functional visibility by inviting people from other departments into our meetings, so the team wasn’t operating in isolation. I built in space for team connection at the end of each session.

    Team satisfaction rebounded to 95% within three months. The team stayed focused and productive through the uncertainty, and the systems we put in place became a reference point for other teams at the company. The goal throughout was the same one I had when I proposed the role: make the right behavior the easy behavior.

    Scaling the production workflow

    As client volume grew, the original systems couldn’t keep pace. There were frequent delays, communication gaps, and unclear ownership at every handoff.

    I optimized our ClickUp-based production system that covered the full workflow from topic approval to delivery: role-specific responsibilities, automated assignment logic based on writer experience and availability, and a structured communication layer that kept clients informed about where their content was at any given time.

    Turnaround time dropped by 35%. Writers had clearer expectations and editors had fewer bottlenecks. For the first time, delivery was predictable.

    Rebuilding the automation layer

    When my manager left, I also inherited responsibility for the company’s automation workflows. These had been managed by a VA who reported only to her, operated in complete isolation, and had no documentation behind any of it.

    The setup wasn’t working. Requests were missed, communication was minimal, and the automations themselves were fragile. After a performance improvement plan produced no change, I made the decision to offboard her.

    With no one else trained on the systems, I stepped in directly. I taught myself Zapier, reverse-engineered every existing workflow, and simplified the entire automation layer from scratch. Then I documented all of it so onboarding a replacement would be repeatable the next time.

    The results were measurable: automation errors dropped by 90%, time to generate content cards fell by 25%, and Zapier dependency dropped by 50%. The function went from a fragile, undocumented dependency to a role anyone could pick up and run.

    Proposing the merger

    For months I’d been watching the production and delivery teams operate in parallel, duplicating effort and creating avoidable delays. The fix was clear: merge the two teams into a single function with client-specific ownership. But I wasn’t in a position to push that decision yet.

    I had a new manager, and she’d been told I had conflicts with the other team. Trust had to be built before anything structural could change. So I focused on delivering consistent results, documenting where the redundancies were costing time, and making the case through data rather than argument.

    Four months later, she approved the proposal. That merger became the foundation of the Head of Production role, which I moved into next.

    Looking back

    Operations isn’t the systems in isolation. It’s the systems alongside the people who use them and the conditions those people are working in. I learned that more clearly in this role than in any other.

    The work I’m most proud of from this period is harder to quantify than the metrics. The team kept moving when things were hard. The documentation I built outlasted my time in the role. That’s usually the sign you built something real.

  • Building the LinkedIn Content Factory

    Building the LinkedIn Content Factory

    In late 2024, my LinkedIn presence was inconsistent. I had ideas but no system. Posts happened when time allowed, which meant they often didn’t happen. I knew the problem wasn’t motivation. It was operations. So I treated it like one.

    The challenge

    Creating LinkedIn content that actually sounds like you is harder than it looks. The obvious bottleneck is time. But the deeper one is structure. Without a repeatable system, every post starts from scratch: the brainstorm, the framing, the draft, the edit. That’s not a content problem. It’s a workflow problem.

    I also had a quality issue. AI-assisted content was fast but impersonal. The posts that performed best were the ones where I’d added something specific like a personal observation, a real example, a genuine opinion. The challenge was building a system that preserved that human input without making the process slow.

    The approach

    I started with a framework from Creator School’s AI LinkedIn Content Factory course, which introduced the concept of a structured AI-assisted content workflow. The initial version used a custom GPT and a Google Sheet to track ideas and manage the production pipeline. It worked, and I learned a lot from building it.

    Over the following year I rebuilt the system from the ground up. In early 2026 I migrated from the custom GPT to Claude, which gave me more flexible project-based context and better writing quality. The bigger change was structural: I separated the work into four dedicated conversations: personal posts, LinkedIn posts for Tuesday and Thursday, LinkedIn comments, and content planning. Keeping these separate means each conversation builds context over time without one type of work polluting the others.

    The personal input problem, the one I’d struggled with since the beginning, got solved with voice notes. Instead of typing out what I wanted to add to a post, I record a short voice note directly into Claude. It’s faster, more natural, and the output actually sounds like me rather than a polished version of a brief I wrote. That single change made the biggest difference in quality.

    How the system works now

    The content planning conversation is where the quarter starts. I export the data from the previous quarter, feed it into Claude, and generate a full content plan for the next quarter. For example, for Q2 2026 that produced 35 ideas across my content pillars, enough to run for the full quarter without brainstorming from scratch each week.

    When I’m ready to draft a post, I open the relevant conversation, paste the idea, and add a voice note with my actual perspective. Claude drafts the post. I refine. For images, I take Claude’s description of the post’s message and generate the visual in Gemini, either by describing what I want or by pasting the post text directly and letting Gemini interpret it. The output has been consistently on-brand.

    For comments, the workflow is lighter. I paste the post I’m responding to, give a short note on my angle, and Claude drafts the comment. I give feedback over time to train the voice. The goal isn’t automation. It’s reducing the friction between having something worth saying and actually saying it.

    Results

    Content creation time dropped from roughly an hour per post to about 15 minutes. That’s across the full cycle: ideation, drafting, and refinement. Running at two strategic posts per week plus regular commenting, the system handles a posting cadence that would have been unsustainable without it.

    Profile views tripled over the period I ran the system consistently. The quality improvement was measurable too: posts with my personal voice input consistently outperformed posts where I skipped that step. The data reinforced the design decision. The human input layer isn’t optional. It’s what makes the system work.

    What this is really about

    The LinkedIn Content Factory isn’t a content hack. It’s an operations problem approached as one. The question I started with wasn’t “how do I use AI to write LinkedIn posts.” It was “what does a sustainable content workflow actually look like, and what breaks if I don’t build it properly.”

    The answer involved separating concerns, reducing friction at the human input stage, building in measurement, and iterating on the design. That’s the same process I apply to any operational system. The fact that it’s about LinkedIn content is almost beside the point.