Having been occupied with burdensome provincial pursuits described elsewhere for the first quarter of my life, and finding myself getting real bored of them, I decided in 2022 to try something new: full-time higher education. I hoped to meet new people, finish a computer science degree, and wend my way into the upper middle class. I took up lodgings at a nearby state college, acquitted myself reasonably well there (got decent grades, led a medium-sized student organization, worked as a research assistant and tutor for half the computer science department) and fell into the company of a few altogether quite singular and unique individuals similarly occupied; one of whom I had, whilst quitting the place, reason enough to prevail upon for a job.

Later, after a year and a half of trying to build an online retailer at a small, independent technology startup, I got outta there, as things had gotten a bit tense. This was my first foray into what’s commonly known as “white-collar employment,” and the first time anyone in my family had held such a position since my dad got laid off from his job as a switchgear designer during the Great Recession. It was a weird experience, and if that’s what white-collar work is like, I will happily go back to being a cashier at a gas station forever. But I don’t know that it is representative.

I quit, despite being offered huge piles of money to stay, because I knew that I was miserable and suspected there was more to life. A lot of things went wrong. There are a few ways I could tell the story:

1. Conflict

The biggest problem I experienced was a lack of patterns, mechanisms, or people that I could turn to for the purposes of conflict resolution. When two people disagreed about something, it was common for the plans, ideas, and software they were developing to simply diverge permanently. If one person wanted to pick the product categories that were displayed to customers algorithmically, and another wanted to do it manually, two incompatible initiatives would form.

This would happen regardless of the positions occupied by the parties who disagreed: role definition wasn’t concrete enough for anyone to claim the right to make initial decisions with regard to things like marketing, product, or software architecture, and the CEO of the company was as likely as anyone else at the company to have a “we aren’t actually going to do what he just said to do” conversation take place without him after a meeting. Also, there were people who could and would devote dozens of hours of their own and others’ time towards a project even if they completely lost the argument about whether it was a good idea. Conflicts didn’t end; they just re-emerged when people were confronted by what others were doing.

This hurt productivity. Around the time I was leaving, one of the major initiatives for the web app was a dashboard that would enable certain types of users to launch campaigns that would get people to buy stuff on our website. The designs for the dashboard were drawn up; they were critiqued by someone with a director role; and the employee who drew them up ignored these critiques and put themselves and others to work on building them. Then, we learned that there was an ongoing conflict over whether to enable this kind of user to launch this kind of campaign at all. The CEO had strenuously made the case that we didn’t need and shouldn’t have this functionality; the people directly above me (i.e. the leadership of the technical side of the company) disagreed with him, and just had it built anyway. So, after months of working on this feature, the CEO was like “we cannot ship this,” and thus months of work were wasted. Except they aspirationally weren’t, because the immediate response was to plan out how this dashboard could continue to be developed while remaining hidden and inactive so that it could be deployed later when the CEO wasn’t looking. The snowball of conflict continued to roll downhill.

So, from an efficiency and alignment standpoint, not ideal. But, if we’re being honest, the lost productivity was not actually the thing motivating me to leave: the endless amounts of resentment and animosity that this process generated was. Disagreements about whether someone’s work would get used were not passive. People attempting to bring conflicts to an end by actually making decisions were resented and mocked. While the initial version of the campaign dashboard was being developed, I heard (and often agreed with!) months of complaints about the weaknesses of the project from one side and about the people “bitching and moaning” about it from the other. Also, the emotional toll of throwing away months of work was not inconsiderable, especially for those for whom this was their first major software project.

The environment was ideal for those willing to commit to their instincts, dig in their heels, and put their heart and soul into proving the haters wrong about their great ideas. Ideal, that is, other than all the other people doing the same thing with theirs.

2. Responsibility

So that’s the 30,000 foot view of things. I could also center myself a bit more and tell the story in a very different way.

This company was built around and run by a small group of fairly privileged young people who met at private school, received investment through wealthy family members, and weren’t used to the word “no.” None of them could really get into serious trouble with each other: they had ironclad rights granted to them by the ownership structure of the company, and they all needed to present a cheerful picture of what was going on to their distant investors.

So, they weren’t and couldn’t be held accountable for whether they were performing the basic functions of leadership. One aspect of this was the expectation that people would just intuit what was wanted from them: the expectation seemed to be that everyone would just do whatever they thought was right, and then try to defend it afterward, instead of being told what the rest of the company was doing. Employees who really needed feedback as to how to improve their work never got it.

And, as in the example of the campaign dashboard above, this was obviously worst when it came to situations that touched on the perpetual conflicts over the product. I came to learn that I couldn’t trust people in leadership positions to tell me what others wanted, even when I asked explicitly. Multiple people in leadership positions would claim that they were the only person I should listen to, even on matters of highly salient internal company policy, leaving me with no safe path forward.

And my position in particular became untenable over the course of my employment there. I was told I was crucial to the software development effort: in private contexts, I was treated as part of leadership, and told I was the person who was going to make our e-commerce platform work. It was indicated that the company depended on me; I believe it because of the size of the raise I was offered when I decided to leave. Despite this, I was given no support or backing when it came to answering technical questions or resolving disagreements about the software platform. Anyone could turn anything into an interminable conflict. Thus, I was expected to fulfill leadership responsibilities while being at the mercy of any new hire who literally didn’t understand how cookies worked.

In other words, I was treated as leadership, but only for the purposes of having problems offloaded onto me. I was expected to fulfill the responsibilities of the people that I worked for, who were largely absent from day-to-day software engineering activities, without the rights and privileges inherent to their positions. And the rest of the time, I was collateral damage for the learning experiences of people who not only had never been managers, but had never really even had managers. It was a lot.

3. Fairness

Of course, that version of the story isn’t entirely fair. It’s true, but it leaves out a few things; primarily, that no one was getting what they wanted.

It’s easy to look back and be frustrated by the fact that even basic engineering questions turned into endless conflicts that were never decided, but that type of problem didn’t just affect me: our CEO genuinely seemed to face the same difficulty when it came to basic product decisions. I think he was in a bit more of a secure position, since he was CEO, but still.

The young executives I worked for might have genuinely wanted me to succeed and have a storied career leading technical initiatives at their company; or maybe, they just wanted to use me as a shield so they could avoid confronting the technical and personnel problems in the software engineering side of the office that would normatively be their responsibility. I was genuinely uncertain about this at the time; now, I realize it’s an almost meaningless question. Even if the people in leadership wanted me to succeed, it seems unlikely that they could have enabled it, as there were no signs that they were even able to accomplish their own goals. They couldn’t have helped me get what I needed from the people around me, since they couldn’t seem to bring about anything they wanted themselves. In terms of everything that factored into my day-to-day experience working there, it was impotence and paralysis all the way up.

Conclusion

It has long been my view that not all difficult situations are instructive. Hard cases make bad law, as they say. Sometimes you can learn a lot from a difficult time in your life; other times, the smartest thing to do is go “AUGH! AUGH! AAAAUUGH!” quietly to yourself and move on.

But, these are some of the values that guided people’s behavior there that I’m consciously trying to unlearn:

• Intelligence is not the same thing as competence. Competence does not come from great exertions of intellect or originality; it mostly comes from having seen the same idea or built the same system or had the same conversation enough times that you could do it in your sleep. (It also usually comes from seeing someone else do it first.) If you apply all your intelligence to coming up with a cool system for sending emails, but are unaware that such systems generally separate transactional and marketing emails and that marketing teams are used to the specific features of CRMs, your email system will not be useful in practice, and will be worse than what a slightly dimmer but more competent person would have built.
• Enthusiasm is not the same as competence. There’s this idea that if you don’t really know what you’re doing, but you throw yourself into it with complete commitment, pour uncountable hours into your work, and dedicate yourself to the email system that you’re building, your efforts will bear fruit and it will turn out great. This does not work. Enthusiasm doesn’t substitute for competence for the same reasons that intelligence doesn’t, with the added bonus risk that an enthusiastic person will get too attached to their ideas and accomplishments to accept the feedback that marketing will just use an existing CRM for this kind of thing.

There’s also a bigger lesson that I learned that’s a little more subtle. It’s something to do with the dangers of centering yourself. If you make yourself the hero of every story you’re living through, everything you do seems justified; everyone else is dancing to the tune of the song stuck in your head. You think you’re a leader and a hero, when you’re actually just using people. You think you’re being taken advantage of, when your needs are actually just not understood.

If I decentered myself a little more, I could tell the version of the story where I was the villain. I leave that to others to do.