Atticus Li built and managed a 27-member cross-functional team for Jobsolv while simultaneously leading Applied Experimentation at NRG Energy full-time, coordinating a dev agency in Egypt, a UX/UI design agency, and freelancers across Upwork and Fiverr. This is how that actually worked — and what nearly broke along the way.
The Setup Nobody Recommends
Let me paint the picture accurately so you understand why I'm writing this post. During 2024 and into 2025, my daily reality looked like this:
Full-time job: Leading experimentation and optimization across seven retail energy brands at NRG Energy. Running 150+ experiments, managing stakeholder relationships with C-suite executives, producing executive reports, scaling the program.
Jobsolv: A SaaS platform that grew to 30,000+ users and $80K+ revenue — with a 27-person team I was solely responsible for managing.
GrowthLayer: The content engine and growth marketing arm that feeds the broader ecosystem.
Nobody recommends doing all three simultaneously. I'm not recommending it either. But this is what building looks like when you don't have venture funding and you're not willing to quit your day job before the product proves itself.
What I can tell you is what I learned about managing a large distributed team as a solo founder with extremely limited time. These lessons cost me sleep, weekends, and a few relationships with contractors that ended badly because I hadn't figured out the systems yet.
The Team Structure
Twenty-seven people sounds like a lot. It is a lot. But they weren't all full-time, and they weren't all working simultaneously. Here's how the team broke down:
Dev agency in Egypt (3-5 engineers): This was the core product team. Backend, frontend, and infrastructure. They operated as a semi-autonomous unit with a tech lead on their side, but I was the product owner, the QA reviewer, and the architect for every major feature.
UX/UI design agency (3-4 designers): Responsible for the visual layer — wireframes, high-fidelity mockups, design system components, and usability testing coordination. They worked in parallel with the dev team, which meant synchronization was a constant challenge.
Upwork and Fiverr freelancers (15-20 across the lifecycle): Frontend developers, copywriters, QA testers, graphic designers, SEO specialists, and occasionally data analysts. The composition shifted constantly based on what the product needed at any given sprint.
The total headcount fluctuated. Some weeks I had 12 people actively working. Some weeks it was 22. The management challenge wasn't the number — it was the coordination across entities with different working styles, time zones, contract structures, and quality standards.
Managing the Dev Agency
The Egypt-based dev agency was the most critical relationship, and it took me months to get it right.
What worked from day one: They had strong technical skills and a genuine interest in the product. Their time zone (UTC+2) meant I could do handoffs at the end of my US workday and have progress by the next morning. When this cadence worked, it felt like having a 24-hour development cycle.
What I had to learn the hard way: You cannot outsource product thinking. I tried. I'd write a brief that said "build the resume optimization feature" and expect them to fill in the gaps. They'd fill in the gaps — just not the way I would have. Not because they were wrong, but because they didn't have the user context I had from watching session replays, reading support tickets, and talking to users directly.
So I started writing detailed Product Requirements Documents for every feature. Not because I'm a process person by nature, but because the cost of ambiguity was rework, and rework was the one thing I couldn't afford as a solo founder with a full-time job.
My PRDs included:
- User story with context: Not just "as a user I want X" but why this feature matters, what behavior we observed that drove the request, and what success looks like
- Technical architecture notes: Where the feature fits in the existing system, which APIs it touches, database schema implications
- Wireframe references: Linked directly to the design agency's Figma files
- Acceptance criteria: Specific, testable conditions that had to be true before I'd accept the work
- Edge cases: What happens when the user has no data? What happens with 10,000 entries? What happens on a slow connection?
I wrote these in Notion. Every sprint planning session started with walking through the PRDs together. Weekly standups were 30 minutes, focused entirely on blockers and scope clarification.
Code reviews: I reviewed every significant pull request. Not because I didn't trust the team — because I needed to understand every part of the codebase. As a solo founder, I was the only person who could make architectural decisions about tradeoffs between speed, scalability, and user experience. If I lost track of the codebase, I lost the ability to make good product decisions.
Managing the Design Agency
The UX/UI design agency relationship had a different set of challenges. Developers build what you spec. Designers interpret what you describe. The gap between interpretation and intention is where things go sideways.
Design system governance: Early on, every screen looked slightly different. The padding was inconsistent. Colors drifted from the brand palette. Typography varied between pages. I learned that you can't just hand designers a brief — you need a design system that constrains their decisions in the right ways while leaving room for creative solutions.
We built a component library in Figma that became the source of truth. New designs had to use existing components unless there was a documented reason to create a new one. This reduced design review time by roughly 60% because I wasn't catching inconsistencies anymore — the system caught them.
Wireframe reviews: I moved to asynchronous wireframe reviews using Figma comments. The designers would post their work by end of their day, I'd review during my lunch break or after my NRG workday ended, and they'd have feedback by their next morning. This async loop was the only way to keep two agencies and a pack of freelancers moving without me being in meetings 8 hours a day.
Usability testing coordination: We ran usability tests with real Jobsolv users on a monthly cadence. The design agency managed the test sessions, but I wrote the test scripts and review criteria. The results fed directly into the next sprint's backlog. This closed the loop between "what we think users want" and "what we watched them struggle with."
The Freelancer Engine
This is where most solo founders either waste enormous amounts of money or give up entirely. Managing freelancers across Upwork and Fiverr requires a system. Without one, you'll spend more time managing than the freelancer spends working.
Recruiting: I learned to evaluate portfolios with extreme specificity. I don't want to see a freelancer's "best work." I want to see work that looks like what I need. If I'm hiring a frontend developer to build a dashboard component, I want to see dashboards they've built — not landing pages, not mobile apps. The portfolio has to match the job.
I also started with paid trial tasks. Never a free test — that's disrespectful to the freelancer's time. But a small, paid task ($50-150) that mimics the real work. This filters out about 60% of candidates who look good on paper but can't deliver in practice.
Contract structure matters: I experimented with hourly, fixed-price, and milestone-based contracts. Here's what I landed on:
- Fixed-price for well-defined deliverables: Graphic design, copywriting, specific frontend components. When I know exactly what I want, fixed-price aligns incentives.
- Hourly for ongoing or exploratory work: QA testing, data analysis, research tasks. When the scope isn't fully defined, hourly prevents the freelancer from cutting corners to hit a fixed budget.
- Milestone payments for larger projects: Breaking a $2,000 project into four $500 milestones with clear deliverables at each stage. This protects both sides — I don't pay for unfinished work, and the freelancer gets compensated as they deliver.
Quality standards: Every freelancer received a brief that included not just what to do, but what "done" looks like. For copywriters, that meant a style guide, tone examples, and SEO requirements. For frontend developers, it meant browser testing requirements, accessibility standards, and pixel-perfect adherence to the Figma designs. For QA testers, it meant test case templates and severity classification guidelines.
The delivery workflow: Freelancers submitted work to a shared workspace (Notion for documents, GitHub for code, Figma for design). I reviewed asynchronously. Feedback was written, specific, and included screenshots or recordings when relevant. If something needed more than two rounds of revision, it was a signal that either my brief was unclear or the freelancer wasn't the right fit.
Sprint Planning Across Time Zones
This was one of the hardest operational challenges. The dev agency was in Egypt (UTC+2). The design agency was US-based. Freelancers were scattered across India, the Philippines, Eastern Europe, and the US. My NRG workday ran 9-6 Central.
The system that worked:
Asynchronous by default, synchronous by exception. Most communication happened via written updates in Notion and Slack. Standups were recorded Loom videos, not live calls. When I needed to talk live — usually for sprint planning or architecture decisions — I scheduled calls during overlapping windows (usually 8-9 AM Central, which was 4-5 PM Cairo time).
Weekly cadence: Monday mornings I'd review the previous week's progress, update the sprint board, and post the week's priorities. Wednesday I'd check in on blockers. Friday the team posted updates. This rhythm gave everyone clarity without requiring me to be constantly available.
Notion as the single source of truth: Every PRD, every design brief, every sprint board, every meeting note lived in Notion. If it wasn't in Notion, it didn't exist. This sounds rigid, but it saved me from the chaos of information scattered across Slack DMs, email threads, and WhatsApp messages.
What I Learned About Performance Issues
Not every hire works out. Not every agency delivers what they promise. Here's what I learned about handling performance issues as a solo founder:
Address it immediately, not eventually. When a freelancer's work quality dropped, I used to let it slide for a sprint because I didn't have time to find a replacement. That always cost more in the long run. Now I address it in the same review cycle. "This doesn't meet the standards we agreed on. Here's specifically where it falls short. Can you revise by Thursday?"
Separate the person from the performance. Some of my best long-term contractors had rough starts. The ones who responded to feedback with curiosity — "I see what you mean, let me try this approach" — almost always improved. The ones who responded defensively rarely did.
Have backup options ready. For every critical role, I maintained a shortlist of 2-3 vetted freelancers who could step in if needed. Building this bench took time, but it removed the desperation that leads to bad hiring decisions.
End contracts cleanly. When it wasn't working, I said so directly, paid for work completed, and moved on. No ghosting, no slow fade. Solo founders don't have the luxury of carrying underperformers.
How to Not Burn Out
I want to be honest about this part. I came close to burning out. Multiple times. The combination of a demanding full-time role at NRG — where I'm running 100+ experiments per year using Atticus Li's PRISM Method — plus managing 27 people across three continents for Jobsolv is objectively too much for one person.
Here's what kept me functional:
Ruthless prioritization. Not everything is urgent. The freelancer asking about font sizes can wait until tomorrow. The production bug that's blocking signups cannot. I categorized everything into "blocks revenue," "blocks other people's work," and "can wait." Only the first two got same-day attention.
Delegation with trust. The dev agency tech lead earned my trust over months. Once he did, I stopped reviewing every PR and only reviewed architectural decisions and user-facing features. This probably saved me 5-6 hours per week.
Saying no to scope. Every week, someone on the team had a great idea for a new feature. Most of those ideas were genuinely good. But building a product with limited resources means saying no to good ideas so you can say yes to the right ones. I killed more features than I shipped.
Protecting deep work time. My NRG work required focus — analyzing experiment results, building executive reports, designing test strategies. I blocked 2-3 hours of uninterrupted time every morning for NRG work. Jobsolv management happened in the margins: early mornings, lunch breaks, evenings. Never during NRG's core hours.
Physical health as infrastructure. I realize this sounds like generic advice, but I mean it operationally. When I stopped exercising, my decision quality degraded within a week. When I slept less than 6 hours consistently, I started missing things in code reviews. The body is part of the system.
What This Experience Actually Taught Me
Managing 27 people as a solo founder while working full-time taught me things that managing a team in a normal corporate environment never would have. Some of those lessons:
Systems beat hustle. The founders who brag about working 80-hour weeks are usually compensating for bad systems. Every hour I spent building a better process saved 10 hours of execution over the following months.
Written communication is a superpower. When you can't be in every meeting, your writing has to carry your intent perfectly. I got dramatically better at writing briefs, giving feedback, and documenting decisions because I had to.
The best people don't need management — they need context. My best contractors and agency partners didn't need me checking on them. They needed clear objectives, access to the information they needed, and the authority to make reasonable decisions without waiting for my approval.
Building a company is not a linear path. Jobsolv went from a services business to a SaaS platform. The team evolved with it. Some of the best people from the early days weren't the right fit for the later stage, and vice versa. That's not a failure — it's how building works.
If you're considering building something on the side while working full-time, here's my honest assessment: it's possible, but only if you're willing to build the management infrastructure that makes it sustainable. The product is only as good as the team behind it, and the team is only as good as the systems that connect them.
You can reach me at [email protected] if you want to talk about distributed team management or the reality of building while employed. I've made most of the mistakes already, so at minimum I can save you from a few of them.