What we learned from Meta’s first “Code Machine” — a chat with Formation Co-founder Michael Novati

At Formation, we talk a lot about leveling up, not just by putting in more hours, but by getting clear on how you work best and using that to drive impact.

That’s exactly what our co-founder Michael shared in a recent live event, hosted in partnership with Taro: a deep dive into how he rose through the engineering ranks at Facebook (now Meta), eventually becoming one of the first engineers promoted to E7 and defining a new archetype along the way — what Meta came to call a “Code Machine.”

The recording is now live. Watch it here.

Here’s a quick recap of what we learned.

Promotions at Meta are based on evidence

Michael broke down Meta’s leveling system and explained how engineers progress:

• E3 (entry level): Do what’s assigned and stay productive.
• E4 (mid-level): Own small features, break things down yourself.
• E5 (senior): Lead projects, mentor others, and be a consistent driver of team progress.
• E6+ (staff and senior staff): Influence beyond your team, take on company-critical systems, and be known for doing something that others can’t easily replicate.

At the higher levels, the bar shifts from execution to ownership. You’re not promoted for doing more, you’re promoted for being the person others trust to handle complex, high-stakes work that unblocks the organization.

The Code Machine archetype started here

Michael became the model for what Meta called the “Code Machine”: a highly productive, highly trusted engineer who made rapid progress on work that others avoided — large refactors, debugging critical issues, removing legacy code, and accelerating zero-to-one efforts.

He didn’t wait to be assigned that work. He looked for it, especially when it was messy or cross-functional and didn’t have a clear owner.

One example he shared: removing 200,000 lines of legacy Newsfeed code that engineers across Meta had to work around. Another: consistently jumping in to diagnose site-wide outages and calling in the right people before most knew what was happening.

Choose your tradeoffs

 When joining new teams, he told managers upfront how he worked best.

To stay productive, Michael made deliberate tradeoffs. He opted out of most recurring meetings and didn’t attend daily standups. 

This approach helped him stay focused, but it also had limitations. He admits he didn’t invest much in one-on-one influence or building deep relationships across teams, and sees that as an area where he could’ve grown more.

Picking the right projects matters as much as performance

Later in his tenure at Meta, Michael began selecting projects that aligned with his working style. He looked for:

• Systems with legacy code and no clear owner
• Prototypes or early-stage tools that needed to move quickly

He avoided teams stuck in the middle—products with constant reorgs, heavy process, or unclear leadership.

This pattern let him deliver impact quickly and move on once the work shifted toward maintenance or coordination-heavy planning.

He built speed by fixing small inefficiencies

Michael didn’t just work quickly—he built systems to go faster. If something slowed him down more than once, he fixed it. That could be a script, a shortcut, or a better way to structure commits. Over time, those habits added up.

This mindset carries into how he uses AI today. He doesn’t chase new tools. He integrates what makes his existing setup faster, like GitHub Copilot inside VS Code.

AI is accelerating engineers, but it may change what the job is

In the event, Michael talked about two directions AI is heading:

1. Productivity tools that help engineers code faster (where we are now)
2. Autonomous systems that may eventually own parts of the stack, with engineers acting more like managers or reviewers

He sees real value in the first category, especially for internal tools, prototypes, or repetitive work. The second path feels less predictable but is worth watching.

His take: Tools that make you more efficient are worth adopting now. But engineers still matter, especially the ones who know how to move things forward when it counts.

Most engineers prep wrong for interviews

As a frequent contributor to communities like r/leetcode, Michael sees a recurring mistake: engineers solving hundreds of hard problems in isolation, with little reflection on how they’re thinking or communicating.

His advice is straightforward:

• Master easy and medium problems
• Talk through your thought process
• Follow a structured approach to problem-solving

You don’t need to guess what you’re good at

When people ask how to discover their strengths, Michael keeps it simple: write more code. Try more things. See what sticks.

You’ll figure out what you’re good at by doing, not by theorizing.

Watch the full recording

This session is packed with stories—early Facebook war stories, SEV fire drills, how performance reviews actually work, and what Michael’s learning now as co-founder of Formation.

🎥 Watch the full conversation

Want to learn from Michael directly? At Formation, we help mid-level and senior engineers navigate interviews, build leverage, and grow on their terms. If that sounds like what you need, check us out.