The Three Tech Projects You Meet in Hell

“One must imagine the senior engineer happy.”

7 min readOct 19, 2022


If you’ve read even a children’s book about Greek mythology, one thing that will stand out is how often the Greek gods punished people. Whether you were mortal or immortal, if you broke a promise or snubbed a guest or showed even the smallest amount of hubris in front of an Olympian, you could end up spending eternity as a spider, or tied to a flaming wheel, or as a frustrated futurist.

Of course, ancient myth isn’t just an easy source of bedtime stories for 21st century children (another: a good translation of Grimm). It also can work for us the same way it worked for the ancient Greeks themselves: a reasonable store of metaphor, archetypes, and shorthand for people or situations we meet or know in every day life.

Each horse is allocated 25% to this very important project.

Three of the most famous, and vivid, punishment myths are the myths of Sisyphus, Tantalus, and Prometheus.

In case you’re not 100% caught up on Greek myth:

Sisyphus: tried to cheat death, was punished to eternity in hell rolling a gigantic rock up a hill. Each time he reaches the top of the hill, the rock rolls down and he has to return to the bottom to roll it back up again.

Tantalus: invited the gods to dinner, and tried to feed them his own son (!). Condemned to an eternity of hunger and thirst, while standing waist-deep in a lake with delicious fruit hanging just above his head; but every time he reaches down to scoop water it recedes, and when he reaches for the fruit it always hangs just out of reach.

Prometheus: Gave fire to humans. Condemned to spend eternity tied to a large rock, having his ever-regrowing liver picked from his abdomen by ravenous birds.

It occurred to me recently — during a conversation with a coworker, another software engineer at an ‘enterprise’ (i.e. large) company — that while we always want to see ourselves directly in the roles of mythical characters, these three myths actually function as good metaphors for different kinds of technical teams we are likely to encounter during a career.

I’m not talking about successful teams here! These are punishment myths, and so the kind of team or project that I’d like to describe are failing or broken.

I’ll argue that there are three kinds of Broken Team or Failing Project, which we can describe as

  1. Sisyphus Team
  2. Tantalus Team
  3. Prometheus Team

(I’ll use “Team” and “Project” nearly interchangeably for the rest of this post.)

Knowing what kind of team you’re in — or maybe what kind of team you’re dealing with from the outside — might be helpful in understanding how to talk to the people in it, predicting how it will (nearly inevitably) end, and perhaps softening the blow for those involved with it when it does.

Sisyphus Teams

I’m finally finished with this ticket.

Each kind of team I’m describing differs in the way it’s perceived from the inside of the team (by members of the team or project, or close coworkers) vs the outside of the team (usually “management”).

We sometimes find Sisyphus teams in organizations where groups of engineers are allocated (sometimes in a “matrix”) across multiple products or projects. Each product team conducts meetings, does planning, closes tickets, executes releases — and yet the team itself is unmoored from the users who do (or don’t) use their software, and “floats” in a state of keeping-the-lights-on water-treading for years at a time. A manager might look at project planning software and see that “we have 15% of engineer A and 23% of engineer B allocated to the team,” but … nothing is really happening.

So a Sisyphus team, from the outside, looks like it’s making progress. Engineers are assigned, tickets are being closed, code is committed, the rock is being rolled up that hill! Sure, there might be occasional setbacks or problems, but the team is functioning and day-to-day or week-to-week there are incremental improvements.

From the inside, however, a Sisyphus team’s difficulty in reaching its goals — its futility and absurdity — are immediately apparent. This is not to say that the members of the team are necessarily frustrated. They might be unhappy, but sometimes they have come to grips with the absurdity of their own situation and the consequent freedom bought by that realization.

Tantalus Teams

Tantalus teams are, if anything, the mirror image of Sisyphus teams.

From inside, the team always appears about to reach its goals. Project completion, or the next release, is always close. People in the team are hungry, motivated… and it’s only from the outside that perhaps we can see how the deadlines are always receding, the “killer” feature always delayed, the important customer always a little unsatisfied.

Examples of a Tantalus team might be a team that’s trying to build, internally, a product or migration that will solve all our problems. Perhaps this team uses words like platform or framework to describe their end goal. It’s the last heist before retirement, or the “MVP” that doesn’t turn out to be so “minimal.”

I can allllmost reach version 1.0

But however you describe it, the work is always in the present while the rewards continue to hover in the future.

How Does It End?

Another dividing line between Sisyphus and Tantalus teams is understanding how they end. How does an organization bring itself to a point where it can shut down a Broken Team, or end a Failed Project?

Each of these teams is broken through the way that the inside and outside views of the team are so different, and so any resolution will necessary also involve re-aligning these two viewpoints.

The distinction between inside and outside perceptions of a team points us towards one answer: Sisyphus teams are ended through ground-up communication, while Tantalus teams must be shut down by management.

In the case of a Sisyphus team, change has to come from team level up to management, about the state of the project, its lack of progress, and the futility and frustration that results from continued work.

Conversely, in a Tantalus team, you can’t make progress by talking to the team members. Here, each person working on the project still believes that they’re always almost about to reach their goal! It’s the responsibility of the gods, the Olympian C-Suite or upper management, to realize that Tantalus is grasping at but never reaching its own goals.

Prometheus Team

The alternative to successfully shutting down a Sisyphus or Tantalus team is that it becomes the third kind of failure: a Prometheus team.

Prometheus had perhaps the most straightforward punishment. There’s no difference-of-opinion about what is happening to him: he’s getting his liver eaten. He knows, the vultures who eat it know, the gods know. Everyone knows, and yet the punishment continues.

Maybe you’ve encountered this kind of project in your own career. Perhaps it’s a piece of critical infrastructure which only one engineer knows how to maintain and therefore can never escape. Or it might be an application, so crusted over with technical debt and unused code that updating or releasing it is impossible, but which has a user group powerful enough to prevent any tech retirement or migration.

This is the third kind of Broken Team: a team which is clearly dysfunctional, yet no one involved has the will or power to fix. From management who fund its, to the leaders who run it, and even the engineers who are tormented by it daily, everyone knows it’s broken but we are hopelessly chained to the rock.

I think I need a new job.

Knowing What to Build vs. Knowing What to End

You’ll sometimes hear engineers involved in startups or small companies claim that the biggest mistake is building the wrong software, that “knowing what to build is the most important thing.

In a large company, by contrast, “knowing what teams to shut down” is one of the most important decisions an organization can make. The alternative is broken teams which continue to push on for years at a time, always almost successful, or forever pushing the tickets up the hill while watching new ones slide back down to the bottom.

When you find (or find yourself in) a Sisyphus or Tantalus team, you also have a decent guess as to what kind of feedback is needed — and from whom — before the team can be shut down. Even Prometheus was eventually rescued from his rock.

Don’t let your teams become Prometheus Teams! If you’re a manager, find your Tantalus projects. If you’re an engineer in a Sisyphus team, speak up! Prometheus may be objectively the best Titan (insert [fire emoji] [human emoji] here) but no one deserves that kind of punishment.




Lazy programmer, skeptical ontologist, amateur biologist. Read a book about the printing press that changed my life, occasionally does stuff with genomes.