I’ve been mulling over this article about working at Lovable for a couple of weeks now and it’s really stuck in my mind.

It’s by Elena Verna who’s been in senior growth roles at a long list of tech companies and is now just over a year into working at Lovable (in case you’ve been living in a cave for the last few years, it’s an AI app-building company).

She’s honest that her perspective is based on one company and she can’t always tell which bits are down to AI and which are just Lovable being Lovable. That’s a good reminder to not assume what works there is right for your business.

But one section has stuck with me more than the rest and I wanted to explore it a bit more in this week’s Build.

What the article says (roughly, paraphrasing is mine)

Verna’s starting point is that most of the “AI at work” conversation is still about productivity – the usual things like faster emails, rapid code creation and meeting summaries.

Her argument is that bolting those onto an old organisational model doesn’t get you very far. What’s different at Lovable is that the organisation itself has been shaped (and is still being shaped) around the assumption that AI is part of everything.

She splits her observations into what she loves, what’s hard and what’s just plain weird.

The things she loves include having almost no job titles (just individual contributors, Leads and Heads), very senior people choosing to stay hands-on rather than manage and a deep suspicion of meetings (all these resonate with me a lot!). She spends under a fifth of her week in meetings because context is shared and searchable, and people are trusted to act without permission. This is the kind of thing I bang on about as “institutional knowledge”.

The hard stuff includes the relentless pace. Her use of the word “survival” is a bit of a tell.

There’s also the blurriness of who owns what, where people stray into each other’s work and sometimes duplicate it.

And then there’s the bit I keep coming back to.

Lovable is in a constant state of reorganisation

Teams form and dissolve, responsibilities move and people shift areas. The structure that made sense three months ago is often wrong now.

That reminded me of the more formalised holocratic organisational trends of the new ways of working movement a decade ago.

Here’s the bit that I really think we need to pay attention to – nobody treats a reorg as an event. It’s just how things work there.

So when the structure changes, people don’t read it as something having gone wrong. They read it as “we learned something new”.

That’s a contrast with the relationship a lot of people (including many founders) have with change.

She doesn’t pretend it’s easy. Going fast with high stakes while your team and scope keep shifting isn’t something everyone will cope with. Her example of taking a week’s holiday and coming back feeling like she was being onboarded into a different company shows what that’s like in real life.

Her closing point is the one I’d underline for anyone tempted to copy any of this.

None of these practices work on their own. They work as a system.

Why this feels like a big deal to me

Constant change is something I’ve been thinking about a lot this year.

Folks like The Ready and NOBL have been making the case for a long time that organisations should be continuously evolving rather than lurching between big transformation programmes.

Verna’s piece is the most vivid and current example I’ve read of what that actually looks like day to day. And her honesty about the impact is has on the people inside it is really valuable.

Here’s the pattern I see with a lot of founders I work with: the reorg is an event, usually a big, scary one that gets put off until things are really bad enough to make the pain of change worth bearing.

It usually goes something like this:

• The structure has been “not right” for a year or more. Everyone knows it and feels it as they work, but it’s become normalised.
• The founder finally decides something has to change.
• They disappear for a few weeks to work it out with a small group and then there’s the big reveal.
• There’s a new org chart, an all-hands or Town Hall and lots of carefully worded communications.

And then actual work stops for a while or at best slows to a crawl (maybe I’m exaggerating a bit but you know what I’m meaning here).

People spend weeks working out what it means for their project, their manager or their career prospects. The rumour mill does a lot of overtime with a lot of invented truths becoming seen as official. Some good people quietly start looking elsewhere.

I’ll be the first to admit I’ve done exactly this.

As an MD running a digital agency a decade or so back, I treated restructures as something to get right once and then leave alone. I’d sit on a structure that wasn’t working for far too long because changing it felt like such a big deal. That of course made the eventual change an even bigger deal.

What strikes me about Lovable is that the change itself isn’t really the big pain when it comes to reorganisations. Perhaps the biggest pain comes from the surprise – the backlog of problems that have built up is real but the gap comes where nobody quite knows what’s going on to fix them.

When everyone is working on the assumption that the structure will change regularly, a lot of that pain just disappears (as long as people can handle the level of uncertainty it brings).

You’re (probably) not Lovable

I want to be clear – I’m not suggesting founder-led scale-ups should reorganise every few weeks. Most of you aren’t growing at that speed (and that’s no bad thing). Lots of your people would find that pace exhausting and Verna is right that it isn’t for everybody.

But I do think there’s a middle ground between a two year structure that gets overhauled once in a while and permanent churn.

Here are a few things I’d suggest trying:

• Be clear that the structure is temporary (say it out loud often). Maybe put a date on your org chart – something like “this is how we’re organised for the next six months”. It sounds small but it changes how people hear the next change. It becomes an update rather than a verdict on whether the last load of change was wrong.
• Make smaller changes more often. Build a structure review into your normal operating rhythm – you could do this quarterly as part of your planning. Adjust one team or one area at a time rather than saving everything up for a big bang. Small changes are easier to explain and easier to undo.
• Design around the work, not the boxes. This is the workflow-first idea you’ve heard me talk about before. If your structure follows how value actually gets created, most changes become tweaks to who’s doing what step. If it follows personalities and reporting lines, every change feels personal.
• Keep primary accountability clear even when teams move. This is where Lovable’s model causes waste in my view. Verna admits that sometimes all that autonomy just means duplicated work and nobody quite owning the outcome. If you’re changing structure more often, it matters even more that every important outcome has one named owner. Role clarity without rigidity is the balance to aim for.
• Make context easy to find for everyone. A big reason constant change works at Lovable is that decisions and the reasons behind them are written down and searchable. If your structure moves but the context only lives in a few people’s heads, the people outside that circle will feel every change as a shock. A simple decisions log and more open channels go a long way. And there’s a side benefit of more efficient new starter onboarding too.
• Watch the people, not just the chart. Change you expect is still change. Check in with your managers about who’s finding it hard. Some of your best people may do their best work with a bit more stability and that’s fine. Making room for them is part of the design that you need to do.

The idea I keep coming back to from Verna’s piece is that a reorg can be a sign you’ve learnt something rather than a sign that something went wrong.

For most founders I work with that would be a huge shift. It means treating your structure the way you’d treat your product or your pricing: something you expect to keep improving rather than something you need to get perfect.

So as usual here’s a few of the things I’m asking my founder clients as a result of the thinking behind this issue:

• When did you last change your structure and how long had you known it needed changing before you did?
• If you announced a small structural change tomorrow, would your team hear it as an update or as a crisis?
• Does every important outcome in your business still have one clear owner, whatever team they sit in?
• Where does the context behind your big decisions actually live?

As ever I’m always happy to chat any of this through. It’s top of mind for a couple of clients I’m working with right now. How organisations keep evolving in response to technology without wearing their people out is one of the things I find most interesting about this kind of work at the moment.

​