Seb.L.
Back to all posts

We had to downsize, but we ended up being more productive (AI helped).

Jan 24, 2026 - 7 min read

In late 2024, our company experienced significant downsizing, which left us with a much smaller team and the loss of key IT team members.

During the past year, since I took over as CTO, we reevaluated and streamlined our ceremonies and workflows, and began introducing AI into our daily work.

A little over a year later, we not only maintained stability but also substantially improved our individual contributions by +49% compared to the previous year.

Below are before-and-after comparisons of our team structures and workflows, and the next steps we are planning to take.

My background
  • 5+ years of experience as a print and web designer
  • 12 years in software engineering (10 years in leadership roles: Tech Lead, Team Lead, Head of Engineering, CTO)

👴 Past (Until late 2024)

Team (8 people)

  • 1 CTO (hands-on backend)
  • 1 Head of Engineering (hands-on frontend) → 👋 me
  • 4 Developers: 1 Fullstack, 2 Frontend, 1 Mobile (2 freelancers)
  • 1 Product Manager
  • 1 Designer (freelancer)

Ceremonies

  • Daily standups: 30min every day
  • Sprint reviews + Sprint planning meetings: 1h every 2 weeks
  • Retrospective meetings: 1h30 every month
  • Roadmap meetings: 1h every month
Consequences

On average, each team member spent almost 4h per week on meetings and ceremonies.

Feature development workflow

For each feature, the workflow was the following:

  1. PM + CEO → Discuss the feature
  2. PM + CTO + HoE → Discuss the feature blockers and feasibility
  3. PM + Designer → Work on the feature on Figma
  4. PM → Add the feature to Linear with the Figma mockups
  5. HoE → Refine the Linear issues, adds context, priority, technical details and labels
  6. Every 2 weeks: Team → Sprint planning: issues are being weighed and assigned to the Developers
  7. The new sprint starts: Developers → Work on the issues
  8. Developers → Commit the code on a separate branch and create a pull request
  9. Developers → Wait for a review of one of their peers
  10. PM → Test the feature on the preview environment and provide feedback to the Developers
  11. HoE → Review the pull request and merge it into the main branch
  12. Every week: HoE → Deploy the code to the production environment
  13. Every month: PM → Show a demo of the new features to the company during the monthly meeting.
Consequences

From initial concept to production release, the process could span up to 4 weeks, requiring involvement from over 4 team members before developers even began work on the feature.

👨‍💻 Present (Since December 2024)

Team (2 people)

  • 1 CTO (hands-on fullstack + UI/UX + Product) → 👋 me
  • 1 Fullstack Developer

Ceremonies

  • Engineering team + CEO quick review/demo + features brainstorming meetings: 1h every 2 weeks
  • CTO + Client Support manager meetings: 1h every 2 weeks
  • Issue refinement meetings: 1h every 2 weeks
Impact

On average, the fullstack developer is spending 1h, and the CTO is spending 2h per week on meetings and ceremonies.

This is a reduction of up to 4x compared to the previous year! (This excludes One-on-ones and Executive Meetings)

Feature development workflow

  1. Every 2 weeks: Team + CEO → Features refinement. CEO can propose new features to CTO anytime
  2. CTO + 🤖 AI → Create the basic User Stories, requirements and edge cases
  3. CTO → Assign issues to the Developers based on their skills and availability, and prioritize them based on the existing to-do list
  4. Developers + 🤖 AI → Plan or start development (using Linear MCP or manually), commit to a branch, and open a pull request
  5. Developers → Validate the feature themselves on the preview environment
  6. 🤖 AI → Review the code for potential issues and security vulnerabilities
  7. Every day: CTO → Check the previous day's merged PR and validate the features (double validation by CEO if needed)
  8. Every day: CTO → Deploy the code to the production environment, then notify the dedicated Slack channel about the new features
  9. Every deployment: CTO → Publish a changelog on the dedicated Slack channel
Impact
  • Developers now have ownership of the features they are working on, from conception to the pre-production deployment.
  • A check is still done by the CTO to ensure the feature is working as expected before pushing it to production.
  • Production deployment can now be done almost instantly.

Why is it working?

A smaller, pluridisciplinary team

Having a smaller, pluridisciplinary team eliminates unnecessary intermediaries, allowing for quicker decision-making and more direct communication. With clear ownership and cross-functional skills, we iterate quickly and maintain quality and accountability.

Trust & ownership

  • Developers are trusted to work independently, ask the right questions to the right people, self-review, and ask for help when needed.
  • In a small team, developers have autonomy because specs are defined collaboratively.
  • Developers are expected to share feedback and re-evaluate specs with the CTO and CEO as needed.
  • Developers focus on solving problems, not just pushing code, and can choose to use AI as needed.

Transparency

  • All tickets are accessible to everyone in the company, making the daily meetings unnecessary, since progress is visible to all.

Communication

  • Every released feature is announced in a dedicated Slack channel open to the entire company.
  • Teams are open, and anyone can ask questions directly without needing approval.

AI

  • AI helps identify edge cases and pitfalls early when defining specs.
  • AI is used to review the code before pushing to pre-production, no more double reviews.

Safeguards

  • The CTO (and CEO if needed) reviews features and code for safety before production deployment.

🔮 Future

We can still improve our workflow by:

  • Creating a Linear agent to trigger a full feature development workflow (git branch creation, feature development using OpenCode, commit back and pull request creation).
  • Changelog generation for client-facing features with AI and automatic publishing on Slack when releasing on the production environment.
  • Using AI-driven spec generation tools like OpenSpecs or BMAD.

🤖 When did AI make a real difference?

  • Saving time during the features specification: AI chat about a feature → structured document (using the canvas mode in ChatGPT/Gemini)
  • Identifying potential pitfalls and edge cases that may otherwise be overlooked
  • Faster development: plan mode using OpenCode or Cursor
  • Codebase introspection: AI helped us understand the legacy codebase
  • Code review: security vulnerabilities detection, performance or accessibility issues, etc.

📝 Notes

Our tools
Our stack
AI models used