First, I was not a paying subscriber of this podcast. And second, Josh doesn't have it set up so that really important people like me who shell out $400/year of someone else's money don't get special posting privileges like I get on Nate Silver's substack chat. Especially since I subscribe at that level to Very Serious and Serious Trouble. Come on, man. WTF does founding subscriber even mean these days?

I can't really blame Josh, of course. I would never let a crazy person like me start threads on a chat. Nate Silver is just build different. He, as they say, fucks.

Speaking of which, let's talk about who fucks since that's the chat I wanted to have on substack.

My credentials for explaining who fucks are as follows: I can solve a problem that no one on the podcast was able to solve. Namely, what woman totally and unambiguously fucks? There is a straightforward and obvious answer that no one can or will argue with.

Carrie Fisher.

Do you need more proof? Amy Poehler fucks. Tina Fey does not. Carol Burnett fucks. Madelein Albright Fucks. Angela Merkel fucks, but Jacinda Ardern does not. Sheryl Sandberg is the opposite of fucks, but Elizabeth Holmes fucks all the way from prison. Queens Victoria and Elizabeth II fucks, but Diana does not.

Now that's out of the way, let's talk a lot more about who exactly fucks and more importantly who definitely does not.

Linguistic Issues

"Fucks", in this sense of the word, has nothing to do with the literal act of fucking, which is confusing because it sounds an awful lot like fucking when we're talking about someone who fucks. But that is not the case. I submit to you that the infinitive form of the verb we're talking about is to fucks. The conjugation is I fucks, you fucks, he/she/it fucks, etc. Also there does not exist a time component for fucks. Once you fucks, you always fucks, even if you are currently deceased. My dad, for example, has been dead for a little over 5 years, but he definitely fucks. If we fail to adopt this language pattern, the conversation inevitably becomes confounded by people confusing fucking with fucks. We can't have that.

I will caveat this by saying it is possible to become somone who doesn't fucks if you live long enough to lose your fucks status, like Joe Biden lost his. I'm not entirely sure if Joe Biden is still alive, but I am incredibly glad that Democrats aren't bringing him up. To solve this problem, I propose that we time-box people in this way: Young Joe Biden definitely fucks. President Joe Biden does not fucks.

There Is No Sex Involved In Fucks

In so far as literal fucking is involved, it is only to the extent that other people believe it is plausible that a person does or could do a lot of fucking. There was a lot of confusion about this among the hosts. Having a kid doesn't imply fucks. Having lots of kids doesn't imply fucks. That part of the podcast was clearly wrong. Mitt Romney doesn't fucks.

Fucks is not a sexual thing. It's about other people's ideas of what the person who fucks sexual thing is. It is not about wanting to fuck someone, or someone being attractive enough that lots of people want to fuck them. It is most definitely not about being wanted. People who fucks give no fucks about anyone who wants to actually, you know, want to fuck them. But they also actually and literally fuck and enjoy fucking.

This is why I don't think fucks is as straight male coded as proposed in the podcast. It's true now, always has been, and probably will forever be that women who fuck a lot will always be judged in a negative way by both their female peers and the men around them. And that men who do the same will, on some level, be seen more positively by theirs.

What Does Fucks Mean?

There were many aspects of fucks that Josh, Megan, and CHH were sort of close to getting right. It's mostly about personality, charisma, and dominance. But not dominance in a way that's domineering or overbearing in the ways that "dominant" have been interpreted by modern males. Perhaps a better description for it is the ability to own a social situation without really caring about owning it. In that sense, Ben was the closest to correct when he said that it's about not giving a fuck. Not surprising because it's very possible that Ben fucks.

But that's also not quite right. You have to give enough of a fuck to actually be in a place and time that people can notice that you fucks. Otherwise, there's no fucks.

Here Are The Main Blockers To Fucks

1. People who present themselves as structured and thoughtful

The fucks-people are who they are because they are spontaneous and a little bit joyful about what's happening in their minds, no matter what it is. They are having fun in the moment. They are not people who are considering how things play out in a situation because they already know the outcome is positive for them.

2. Protestants

It's impossible for a protestant to fucks. They are too self-aware that everyone is watching them and judging them just as they judge others, and they don't have the core mechanism that other religions have to get out of trouble with Him. They have to not-fucks in order to be taken as seriously as they need to be.

3. Atheists

No one gives more of a shit about God than atheists. What a bunch of dicks. "I am completely angry about how this entity that doesn't exist ruined my life, and you should be too!" said no one who fucks, ever. These people are obssessed.

4. Anyone who has ever referred to a podcast as a pod

Seriously, what is wrong with you? What an insane fucking backformation. This is not what the cool kids are calling them. You have completely misunderstood the assignment. The abbreviation "pod" in reference to portable sound content is short for "iPod". Good god, please go get laid if you can't trouble yourselves to fucks.

5. People who care about what other people think

I'll get to this more later, but it is not possible to be one who fucks and at the same time honestly care about whether what you are saying in a moment is socially acceptable. There's nuance here, but I'll stick with this for now.

6. Political Partisans

Sorry, it's just too much believing in stuff for it to be a realistic fucks situation. See above. Believing things is not a fucks thing.

These Are The People Who Can Fucks

1. Catholics, Jews, and Agnostics

Not all of these people are those who fucks. But you can't fucks if you're not one of these groups. Whatever your religious thing is, there has to be some version of it that allows you to not care that much about it at all.

Most people who fucks are agnostic on some level. Dad was a serious Catholic for most of his life. But he was agnostic for 20 years or so after he got done with WW2, and he fucks.

2. Centrists

See above. Believing too much of anything automatically disqualifies you from being someone who fucks. Those who fucks are just too fucking busy to give a fuck.

3. Asian Women

I'm including this only because my girlfriend is Asian, and I'm kinda scared about what happens if I don't include her in the list of what I obviously think of as cool people, even though there is no possible way she will ever read this unless I stupidly send her a link, which I just did.

Okay, So What Is Fucks?

If you try to make a Venn diagram of Democrats and people who can be fucks you end up with . . . two completely isolated circles, which is not a Venn diagram at all. It's an Euler diagram when there are only two circles, regardless of whether or not they overlap.

This is exactly the kind of finger-wagging, non-fucks thing a Democrat would lecture you about.

People who fucks are transgressive in social situations, but not because they are trying to be transgressive. The moment someone attempts to become intentionally awful to get a reaction, they become repulsive to everyone. The line between a try-hard asshole everyone despises and someone who fucks and people sort of adore is thin and often depends on wit and timing.

Very few people can pull this off. And it's only the one's who genuinely aren't aware who can.

Democrats don't have anyone who fucks. They are structurally barred from being people who fucks. They are required to care. They must care. The groups have spoken, and their word is that even if you don't actually care, you must pretend to care.

People who pretend to care about other people's shit don't fucks.

There are cases when you experience two different problems in some relational graph that seem to be the same problem but are not actually the same. They have the same sound, a similar definition, but the root causes and the solutions are very different. These usually manifest as conflicting definitions based on business unit perspective.

Scenario A

A company called ExampleCorp takes data from other companies and provides some kind of revolutionary data analysis to drive revenue. ExampleCorp's customers at the top level are people who pay them to analyze data. One of their customers is FoodCorp. FoodCorp has an app that people use to buy food. These are FoodCorp's customers. FoodCorp also has people who deliver food. They are also FoodCorp's conceptual customers.

When ExampleCorp signs a contract with FoodCorp, you have a lot of confusion. The exec team and sales team calls FoodCorp the customer. The app team calls FoodCorp's buyers customers. The database team calls FoodCorp's delivery people customers. This is a problem. No one knows what anyone means when someone says "customer".

Scenario B

ExampleCorp has database, finance, and legal teams. Every time they have to talk about compliance auditing, there is confusion about who is talking about what when the word transaction is used.

Database team thinks transaction means something specific about an interaction with a database engine inside the construct of a session, with certain guarantees about outcomes, failure modes, and data persistence.

Finance team thinks transaction is an event that has monetary impact on the company's financial position and is recorded in a ledger. (There's probably more to it than that. I don't know.)

The legal team thinks a transaction is an event involving two or more parties that involve the formation and performance of an obligation or contract. And contract all by itself has its own specificities around offer, consideration, acceptance, capacity, legality, and a bunch of other stuff I don't know because I'm not an attorney.

This is a problem because no one knows what anyone means when someone says "transaction".

Analysis

At first blush, we appear to have two problems that are equally well-described by the same diagnosis: we have different teams using the same words to mean different things. This causes confusion and inefficiency.

These are not actually the same problem, and the solutions are not the same.

Scenario A is a mismatch between words and meanings that stems from a lack of business context. If everyone involved in the different teams got into the same room at the same time and realized the hierarchical structure of the business model, it would be immediately obvious that we need terms like client, buyer, deliverer. It might take some executive pressure to force this meeting of minds to happen, and people might have different reasons for rejecting these specific terms, but everyone would eventually agree that there needs to be an unambiguous way to differentiate these different groups of people.

Compromise is possible, and things can move forward.  In Scenario B, the name confusion has nothing to do with a lack of business context.

These are terms of art that are required to function in the individual domains. There is no compromise available. The data engineer can't say, "Well, I'll give up strong consistency if Finance team gives up ledger, and legal gives up obligation." It doesn't even make any sense to write what I just wrote.

No amount of executive pressure can alter this situation. The solution is local. The solution is an agreement to make it clear when we are talking about which term of art.

The solution is a collaboration between teams that share specific words with different technical definitions to reach out to the other teams and share their technical definitions, educate each other, learn from each other, and decide on a communication strategy to differentiate between them.

For example, finance team will use financial transaction instead of just transaction. DB team will use database transaction instead of transaction, etc.

But for once, I'm not writing about what's wrong with Agile. I'm deeply grateful to all my friends and colleagues who have been so patient with me over the last 15 years while I constantly point out the problems with it. But I've always been stymied when asked what to do instead.

I have a response now that's been baking in my head for a while. Interval Training, but for work. I'm not going to go deep into the analogy about High Intensity Interval Training or whether it's more healthy than sprinting or whatever because all of these abstractions break down pretty quickly when you put any pressure on them whatsoever. Also, HIIT might actually be worse for you than sprinting. I have no idea. That's not the point.

The point is that it is a way to get work done reliably and consistently and humanely. Without all the pretentious fuss about pretending we software nerds are more important than other people.

I'll describe the attributes of the cycle first and then explain why each of them are important and why they work.

• The cycle is 3 weeks
  • 2 weeks high intensity; 1 week cool-down
• The cycles begin on Tuesdays
• All work stops at the end of the 2 week High Intensity exercise
  • Unfinished work, even if close, goes back into the backlog for review
• Maintain and groom a backlog every week with the whole team
• Break tasks down into no more than 1 day of work
• There are 10 working days in a HI exercise. Assign 10 days of work.
  • This is more than is going to get done. That's good.
• Have a formal check-in half way through the HI exercise
• The check-in discusses status, not progress
  • Status is defined by risk, not effort
• At the end of the HI exercize, project work stops
  • If it's not done, it goes back in the backlog
  • Clearly define "done" for your team
• Retros are about the work process, not the work
  • Do have them
  • Talk about what went well
• Netros are considerations of what went wrong
  • Cordon off the negative meetings
  • Talk about what didn't go well
• The last week is cool-down. Planning, designing, researching, architecting
  • Vital for the next exercise to get off to a good start
  • No project work; only project planning and design

Okay, so let's start at the beginning. Why do I say these things? Why do I think they work?

The cycle is 3 weeks

I've seen things you wouldn't believe . . . . No, not going there. But I've seen Agile sprints from everything to a daily cadence to 6 weeks. I think 3 weeks is the sweet spot because I like the 2:1 ratio of busting ass and planning ass. It's also around the upper limit of what non-technical executives will tolerate. If you tell a CEO that your team goes hard for 4 weeks and takes 2 weeks to recover, you'll get your head bit off about the lost productivity. The 3 week cycle is also small enough to be nimble and responsive to any shifting priorities in the larger organization. But most importantly, you can plan the next cycle during your current cycle while you breakdown the backlog.

The cycles begin on Tuesdays

Why? Work begins on Monday. Why shouldn't your cadence? Because no one should ever put deadlines on Mondays. And the end of a cycle is a deadline. When you put deadlines on Mondays, people do not take their weekends off. They stress, they fret, they try to make things better because Monday is the end of the road for thing x that they are heavily invested in. People do not get the rest and distance from their work that they badly need, not only for their own personal health, but also for the great advantage that comes with distancing yourself from your work for a couple of days.

It seems like it's not a big deal to shift things by one day. But it is really a huge deal. You aren't just giving people an "extra" day. You are giving them 3 days of their life back by doing this instead of stealing their weekends. Over a 3-week cycle across 3 weekends, that's 3 cycles of engagement, withdrawal, fresh engagement. That is incredibly powerful.

All work stops at the end of the 2 week High Intensity exercise

This should probably not be phrased this way. People still work. It's just very differently focused. The meaning is more specifically that task and project work are halted. Anything not completed automatically returns to the backlog. This is an automatic action and a blameless one. No one needs to have a meeting about how or why X task wasn't completed. It wasn't. That's the end of it. Because we tried to do more than we were able to do from the beginning. On Purpose.

Maintain and groom a backlog every week with the whole team

This is critical for people to understand priorities and the relationship of their work to the rest of the company. People operating in a vaccuum don't understand their role. Managers might hopefully understand it, but that doesn't mean indvidual contributors do. Pretending that some people are exempt from these meetings because their time is more important is stupid and counterproductive.

These meetings are about prioritization and about people who are not in the loop getting into the loop. These meetings are for uncovering things that people are not aware that were hidden.

Break tasks down into no more than 1 day of work

If a task isn't so clearly defined that it can't be done by someone, with certainty, in a perfect scenario, in a day, the task is not clearly enough defined to be assigned. Break everything down to the level of 1 day of work. Does that mean it might take 2 days? Sure. But that's not a problem. We don't care about how long it takes at this phase of planning. We care only that it is well enough defined so it's possible to do it in a day.

There are 10 working days in a HI exercise. Assign 10 days of work.

I've seen no end of bulshit from the Agile-Scrum-OverNerds about this self-contradictory bullshit.

"Story points aren't about time!" "Agile isn't about time! It's about effort!" "I think I peed my pants while I was giving this training session! Isn't that great?!"

Also, "We have to be careful about our time! Meetings! Time off! Sick days!"

"So really we should just be assigning about half a day's work for every engineer for the entire sprint. Because effort has nothing to do with time. Obviously"

Fuck that noise. It's so transparently stupid and also incredibly hostile to business management. Businesses are governed by contractual obligations and financial transactions. They are not governed by Agile bullshit. No matter how much you paid for his consulting fees.

This is a fundamental fact of life: tech teams are mountains of uncertainty, and businesses run best on certainty.

Assign the work. Fill up the docket. Prioritize what's needed (that's the whole point of the mid-cycle check-in), cut anything that's not. Expect to not get everything done.

Every minute of your life that you're being a fucking Python genius is a minute someone at the company that pays you to be a Python genius is signing a contract that you are inherently responsible for. That's not a bad thing. That's a reason to get myself off my high horse and do the work every day and earn my pay.

If there is one single identifiable truth in the universe it is this: there's always more work to be done than there are people who are qualified and willing to do it.

We are never going to get all the work done in a cycle. Accept it. But try to achieve it if you can. What's leftover is stuf that might not have been that important anyway. But if we did our jobs right earlier and broke the tasks down into 1-day segments, this should be easily corectible if it is a problem.

Have a formal check-in half way through the HI exercise

I'm not big on rituals, in case you couldn't tell. But this one is important to assess risk. What's first and foremost is the risk of the person who's working on the thing. Is it driving them mad? Are they working weekends because they don't feel good about where they are? Are they not getting enough sleep or rest or enough time to just be human? Are they putting their family aside because of company pressure?

Figuring all that out is the purpose of this meeting. And the meeting is blameless. It's all about de-personalized risk. That's why we only talk about

Status

Status is not about where an IC is on a task. It's not about "progress." Status is all about what is the risk item X won't be done. What is the risk to the project, the team, and the company? This is about shifting people around and moving priorities up and down, and that's all.

At the end of the HI exercize, project work stops

I know I sort of covered this earlier, but it's worth repeating. If you allow project work to continue after the drop-dead date, people will continue to work all the way to the end of the week, take no downtime, and get frustrated and burnt out.

If any ticket isn't done at the end of the HI exercise, the ticket automatically goes to backlog. No questions, no excuses needed. Everything is re-evaluated for the next sprint.

Retrospectives are about the work process, not the work

The work was either done or not done. It's not worth talking about as a team. There may be cases where a manager sees a pattern and need to intervene, but that is not what the retro is about.

The retro asks one question of all the people in the exercise: what could we do better?

That's it. It's actually not the right place to talk about what went wrong during a work cycle.

Netros

The good and bad meetings need to be segregated from each other because the bad news bears tend to dominate and not really be all that helpful (I know because I'm that guy). But have the meeting! Otherwise the disgruntled assclowns like me will feel like we aren't being heard.

The last week is cool-down. Planning, designing, researching, architecting

I think this part is pretty self-explanatory. You actually take cool down time and don't have any deadlines. That doesn't mean work isn't getting done, just like taking a weekend off doesn't mean work isn't getting done.

We're all very smart people, and we're always working on stuff somewhere in our minds. But we're also human, and we all need to catch a break every once in a while.

Because for over a thousand years the Kyrie was the only part of the mass that was Greek. Instead of Latin.

You can hear the differences in the work of Orlando de Lassus, Zarlino, and Palestrina. They all treat this part of the missa in a different way. They are more willing to break the rules of 16th C. counterpoint for this particular prayer. They do it not because the prayer is particularly problematic. They do it because this is one of the few places where a composer could exercise some artistic freedom.

My friend Jo Verdis wrote this version of a Kyrie that I think is truly gorgeous. The prayer is: Lord have mercy. Christ have Mercy. Lord have mercy. I'm not a particularly religious person, but I find a lot of beauty in this pattern. I espcially find a lot of beauty in the way that Jo expresses this prayer and the way the expression evolves over time. It becomes more and more complex and more desperate. Begging for the intent of the prayer. Begging for God to have mercy.

Artists like Alanis Morisette and Ani DeFranco write songs looking to forgive themselves for whatever they feel they've done wrong in their lives.

Jo Verdis isn't asking herself to forgive herself with Kyrie. She's asking us to forgive ourselves.

This isn't just because one more person adds that much more information, but the reason you are adding people is because the product is growing in complexity and needs more discussion, planning, and documentation. Methods of communication that work perfectly fine with 5 people become unwieldy with 8, and downright untenable with 12 people.

Story part 1

Pretty much every company these days manages work with some combination of group meetings and async communication, whether that's email or slack or google groups or whatever. In small groups where everyone knows pretty much what's going on, people take their own meeting notes, create their own task lists, do their work, asking questions and bring up problems in chat as needed.

As the group grows, teams will centralize the meeting agenda and notes into a Google doc or something for reference by everyone that no one reads or references. By 8 employees (if not before) the company decides it is time to get in bed with formal project management software. There are the old school enterprise products like Jira, Pivotal Tracker, and Basecamp; mid-life products like Trello, Asana, and Wrike; and literally hundreds of new competitors with slightly different takes on how to bolt project management ideas onto general purpose data stores.

The company will evaluate a few tools that seem promising based on their price, features, and ease of setup and then move forward with one of them. 8 people is also approximately the time when a team starts to formalize the pull request process, require reviews, and documentation for each merge. Now you have around 8 people and about 5 different systems for containing information.

1. email: every company does at least some work via email
2. chat: every company does at least some work in chat
3. docs: cloud docs are the only thing that make sense for slides or long-form writing
4. project management tool: we need it to define, assign, and track work items
5. pull requests in some form of git manager: we need to be able to see what a commit does and why it does it

Even with a pretty small team so far, the need for purpose-built tools has distributed organizational information across at least 5 different tools, and it's very unlikely that any member of the org owns any particular tool. Just some rough guidelines around how to use them.

Fast forward to 12 people on a team. You've added some handy integrations to the chat app to let you create tickets in the project management tool. You've set up some alerts in a channel so that people see when a PR is submitted for review. You've taken steps to streamline interactions between the knowledge systems. But the information is still fundamentally disconnected, and it's hard to remember where to look for any given piece of information. All of these systems individually have decent search capabilities, but because they are distributed, there's no guidance about where to search.

Was that conversation in email or slack? Or was it in the comments on a Jira ticket? Oh crap, maybe it was in the comments on the PR. You're spending a lot of time trying to figure out where the information is that you need to know. You might have even hired a project manager to help keep track of the things. The timing will be different for every company, but once you get to this point, one thing is absolutely certain: someone will declare that what we need is a Wiki. We'll centralize process and information in the Wiki, and that will solve the problem.

Spoiler alert: it will not solve the problem.

Every team/company I've worked on since 2006 has, at some point, decided to create a Wiki. And every Wiki project has been a total failure.

Story Part 2

When everyone agrees that yeah a Wiki is a great idea, one person champions the project and recruits maybe 1 or 2 other people. They choose a platform. They build out the categories, subcategories, and topics. They stub some articles. They write the ones that they can. They bring this new beautiful knowledge base to the team and ask people to spend time writing articles. Some people do; some people don't. But ultimately on paper it looks like a pretty good start.

People keep asking in chat, "Where do I find X?" And at first the Wiki-Champions are excited to show them that it's right here.

"Oh, I couldn't find that."

A few months later, that's still happening, and the Champions are annoyed. So are the users because they still can't find things, and the Champions are getting testy about no one using the fruit of their labor.

By 6 months after launch, no one talks about the Wiki or uses it or thinks about it. Everyone has moved on, and some people are disgruntled about it. The company has decided that we need more meetings rather than better documentation. Because this just isn't working.

Why does this story happen over and over every time someone wants to build a Wiki for a team or company?

1. It's because the basic model for every Wiki system is a hierarchy of information.

The basic hierarchical model imposes a huge amount of friction to add information to it, so people don't want to. Right up front when you decide to add new information, you have to decide where to put it in the hierarchy, or if it fits in at all or needs a new category or topic or subtopic. For many people, they can't write if they don't know the context of how the information fits into what's around it. So you start off with a great piece of information and are immediately stalled because you have to have a conversation either with yourself or with others about where this thing actually belongs. And where you put it alters in some ways how you approach writing it.

2. It's because the hierarchy design is a reflection of the designer's mental model of the company.

This is why no one can ever find anything. A software engineer is going to organize information in a different way than a marketing person or a sales person or a customer support person. That doesn't mean any of them are right or wrong or stupid or bad at their jobs. It means that the model itself is so subjective that it's useless.

3. It's because information is naturally a graph, not a hierarchy.

Most pieces of information—even very specific ones—naturally fall into multiple categories. This article itself could fall into multiple categories: information design, startup advice, Wiki usage, and project management. At least. If you were going to link to this in your internal company Wiki, where would you put it? It's pretty hard to choose.

4. It's because deciding to relocate an item is a lot of work.

Most Wiki systems automatically generate permalinks based on the context of an article's position in an information hierarchy. If a team decides that one article belongs somewhere else, then the permalink is completely broken, and that is a very bad practice. You don't want to break people's bookmarks in that way, so you have to either never have permalinks or set up tools to redirect to the location of new links. This is bad, and we should feel bad.

5. There's an obvious objection here, and it's that Wikipedia is one of the most successful websites in the world. So why can't we be like that in our company?

First, Wikipedia is organized by hundreds of thousands of people who spend all of their free time arguing about where and how things should be organized, and they do it for free.

Second, Wikipedia is successful because Google indexes all of it, and Google is actually good at search, whereas the base Wikimedia package absolutely sucks at it. If people had to depend only on the base install to run Wikipedia and there were no external search engines helping it out, it would be a total and complete failure.

Do you want to spend your time solving both of those problems internally? No. You do not. You want to focus on your business.

The Wiki is never the right answer.

What's a better story?

1. Intentionally choose to centralize your organizational information.

If you do not do this, vital information will naturally distribute itself over multiple platforms and the value will attenuate over time.

2. Choose a single platform to centralize your information and build human or automated processes around ensuring that all information reaches that platform.

Cross-platform integrations can be useful for this, depending on how they are implemented. Creating a new ticket from a slack command? That's cool.

A slack command that only notifies a channel that something has moved to a different stage? Not so cool. The important part of a cross-platform integration isn't that there's a notification. We are all overwhelmed by notifications. The important thing is that the event is captured.

3. Choose your platform for centralization based on the efficiency of creating tags and how fast it is to lookup those tags via APIs.

The concept of a tag is absolutely key to building a graph of your organizational information. It reduces the friction of creating new content. It allows for faster searches for relevant content. It allows people to update content with new tags without having to step through actually moving articles and changing links.

4. In my experience, the best place to do all of this is in your project management tool.

You can link to pull requests, you can link to slack conversations, you can link to emails, you can link to other tickets in the system and you can link to any cloud docs. And also in my experience, project management tools have better APIs and tagging functions than comm systems. For example, don't ever rely on Slack APIs for anything ever. At all. Jira, on the other hand . . . it's not nearly as bad as the UI. It's faster, at least. And totally consistent.

Closing Remarks

People should be free to use the comms of their choice to get the work done that needs to get done. Some people prefer slack or email. Some people prefer discussion inside of Github PRs. And that's all fine. As long as these things are linked into an item in the PM software there's one and only one central location to search for organizational information. It becomes the "root node" of the graph search space. The process that backs that centralization is really honestly pretty lightweight. And on top of that, if you adopt such a model, you've given yourself a gift when your organization grows large enough that you want to pull data out of the API and start doing internal analytics.

Centralizing organizational information saves you money. Companies hire project managers in the early stages mostly to be central repositories of distributed information. If you design the information up front and the process around that, you can spend that money hiring more engineers or product people or sales people or whatever you need at the moment.

There's an enormous amount of value locked up in organizational information that we don't normally think about until we're missing it. Generally speaking, that value is locked up in the minds of founders and early stage employees. And we are mostly not very good at recovering it when those employees are too busy to interact directly. Early stage companies need to have these resources in place at about the time they need to disconnect from day-to-day operations by inserting a middle-management layer between themselves and the newer employees.

It's possible to design very lightweight processes around simple services that expose that information to machine-readable formats that can make searching across the brain-space of early employees not only possible but easy. This can be a huge productivity boost when companies begin to onboard new people quickly. And it can also be a great resource for older employees to understand architecture and infrastructure decisions.

Most companies understand the value of design at the presentation layer. It seems sort of obvious that the ways in which people perceive and interact with a product are vital to the product's success. Whether that's a chair or a webpage or a lamp is somewhat incidental.

Some aspects of design seem rather arbitrary. Why is it that every piece of software puts the Okay/Accept/Continue button in a dialogue box on the right side of the modal window? And the Cancel/Stop/Don't Do This! button on the left? Is it because Apple wrote in their Human Interface Guidelines that this is the way to do it back in 1977? But Microsoft was also doing things the same way in very early versions of Windows. Was that a case of multiple discovery the way Newton and Leibnitz came up with calculus or the way oxygen was discovered at pretty much the same time by Priestley and Lavoisier?

If I knew more about design, it's possible that I would understand that these interfaces were modeled on some deep layer of human instinct or possibly on some older physical device interactions that were similar in some key way. But I don't know that.

It seems plausible to me that this was an arbitrary decision, but the need for uniformity of interaction demanded that a consistent standard be developed and enforced.

But consider something like a lamp. I'm also not a lamp historian, but it seems likely to me that the earliest version of a lamp didn't have a switch. You might have had to plug it in to the wall to turn it on and unplug it to turn it off. In that kind of a situation, a switch to turn it on and off isn't an arbitrary convention. It's a legitimate innovation that makes interacting with the lamp an objectively better experience.

These are both aspects of design that you could reasonably dump into the user interaction or user experience buckets. But they are fundamentally different approaches to design. One is maintaining a convention and status quo to avoid confusing people with a certain habit, and the other is a measurable improvement in the value of a thing. Now that I think about it, I might have just defined the difference between user interaction and user experience. I never really understood that before.

There's another layer of design—I won't say if it's higher or lower because I don't know. But it's a different layer. It's the layer I think Steve Jobs was talking about when he said, "Design is how it works." It's the layer that technologists are thinking about when we design software. How do you build a thing that's well-suited to solving a specific domain of problems? Answering that question is designing "how it works."

Many companies are also heavily invested in this. Software architecture is an important component of most tech companies, and this isn't usually a particularly hard sell . . . until you bump into how a company is designed.

Designing a company is yet a different layer of design, and it's a layer that most companies pay zero attention to. Especially startups.

There is an obvious conflict between intentionally designing a thing and having the freedom to be flexible about what the thing is. Companies need to be flexible enough to respond to market conditions, changes in competition, and supply chain fluctuations.

But companies need to be designed with the same care and consideration that web apps do. We all know the story of a company that starts out with a few cofounders, they build an MVP, get some clients, get some funding, and from there it's just chaos. Oh, we need a sales team now. Hire some salespeople. Oh we need more engineers. Hire some engineers. Oh crap, we aren't 6 people anymore. We're 50. We need managers because the cofounders are too busy to actually engage with what's going on. So you hire some managers. People are burnt out, they quit, there's contention between teams, lots of awfulness.

Some people call this growing pains and think of it as a natural part of the process of building a company.

I submit to you that this is wrong.

Companies need to be designed.

This is a hard thing to think about because when your company is very young there's no time to think about anything but product-market fit. It's bare survival. And once you figure out how to survive, you're too busy growing to think about it. I'm not unsympathetic to founders here. It's hard.

But I'm arguing that this layer of design is just as important as the presentation and architecture layers.

When you're 12 people and close-knit, titles don't matter. So you don't use them. You're building trust, product, and process. When you're 50 or 100 people a year later, all three have eroded without you noticing. It's a mess if you haven't designed your company.

What do I mean by design your company? I don't have a prescription that fits everyone, but I have a list of questions that you should answer as part of your design process.

Who is driving the product? Is it sales team? Is it a product team? Is it your engineers? Do you even want a product team? Is it always going to be the C-suite?

Related, what are the relationships between teams going to be? They could be front and backend, or it could be sales and developers, product and marketing, or supply chain logistics and developer relations.

What is the structure of management that you want in place at 20 people? 50? 100? 500? 1,000? People will get increasingly distanced as the organization grows. Design ways to keep key people in touch.

How do you expect employees to grow and progress over time? You need to design a career path, even at small companies. Good individual contributors don't automatically make good managers, and vice versa.

What processes do you have in place that support and enforce your mission and vision? Missions and visions and values are meaningless without intentionally designed processes that support them.

How are you planning to recruit? This also needs to be designed. Many prominent tech companies have kicked the can down the street by saying that they can't hire with diversity and equality because there aren't enough diverse and equal people graduating from CS degrees. That's stupid, but it's their argument. Is your company going to try something different? Break the pipeline? Hire women and minorities as apprentices and train them up? Great. Design that process. Just doing it with no plan is chaos.

What kind of management hierarchy do you want? Do you want small clusters of teams led by subject matter experts? Do you want departments and divisions led by directors? Again, it seems like a silly thing to ask when you're 12 people, but it is vitally important for companies to figure this out as early as possible.

Companies that aren't designed—that "evolve organically"—suck. Especially if you're a part of them while they are violently evolving. But a company can be designed to prevent that pain if the founders are willing to take the time to be thoughtful.

In VC-backed economies, the focus is always on explosive growth. But I think there is a way to design growth that is healthy and sustainable.

Chapter 1: Someone has an idea. It could be you, a product manager, a C-level person, it doesn't really matter. But the idea goes, "Hey, I wonder if we could . . . ." And you think to yourself, "I don't really know for sure, but yeah. I could probably do that." So you put in a little extra time a few nights or on a weekend and you throw something together that does whatever that idea was.

Chapter 2: Everyone loves it. It's the new hotness. It could be an internal tool, or it could be an actual business idea for a startup, or it could be something in between. Doesn't matter. What matters is that you found your audience, and they love it. They want new features, which you very quickly add. Development is rapid, and everyone is very happy.

Chapter 3: Things break every once in a while, but people don't get that upset because this is all new and just a proof-of-concept anyway. They appreciate the work that's going into all of this because it's just all happening so fast.

Chapter 4: The Thing has been around for 6-8 months. People are using it daily and have come to rely on it. It's no longer the new hotness, and your team or customers aren't so charitable when things break. So management decides to invest your time (or your team's) into it officially. "Make it stable enough for production."

Chapter 5: Why is this taking so long? It already works! Just make it work better! This should just be like a 2-3 day project!

Chapter 6: Everyone is mad.

Why does this story happen so often? How can we prevent it?

The thought I'm going to explore in this article is that it happens because both companies and developers are unwilling to take out the trash. We need to incorporate garbage collection cycles into our human processes.

There are all kinds of people who will try to sell you solutions to this problem, but none of them are really correct. They fail to acknowledge that proofs-of-concept and MVPs are actually just learning mechanisms for developers to figure out a problem domain. That goes for traditional SDLC (i.e., waterfall), Agile, and Test-Driven Development. All of which try to solve this exact problem with exactly zero success.

Failed Solutions

Waterfall, Agile, and TDD are all different variations of the idea that you should "just build it right the first time." And my argument here is that is fundamentally the wrong approach and the wrong expectation. They are each very different in their approaches, but they are completely and totally wrong. Here's why:

• Waterfall says that you frontload the timeline by learning everything you need to know about the problem domain and the requirements. You don't just go out and build a thing based on a conversation. A) that's not reasonable, and B) there are tons of things you don't know about implementation and architecture details no matter how much research you do. There are many things you can't possibly know until you get into the weeds of writing the code.
• TDD says that if you build the test harness as you go, then you have—by definition—built the right thing. It's a fairly pedantic argument to say that a problem isn't really a problem because we've defined it as not-a-problem. But that's really what it does. In addition, TDD actually promotes this story at the top by sinking costs directly into the developer's learning process. You can't write effective tests without knowledge of the problem domain, and you often don't have that when you're writing an MVP. When you TDD a new project, you are essentially locking yourself into an undesigned architecture that's based on a completely naive understanding of the problem space. That is always going to end up putting Babe in the corner, and no one should do that. The test harness that you create along the way limits your options to rework the fundamental architecture because it's just so much work to redo all of that. It's not the point of a proof-of-concept.
• Agile says that if your process is agile, then you have—by definition—built it right the first time. It is the human process version of TDD. Working small ideas one at a time without any guiding design is a recipe for an absolutely terrible architecture, a codebase that sucks, and a fragile product that's unmaintainable. It's the equivalent of managing your logic with post-it notes all over the office walls or walking a random forrest.

So now that I've made pretty much everyone in the software developer world angry, what's next?

Take Out the Trash

We should acknowledge that every developer/team's first foray into a new thing is absolute garbage. That doesn't mean the developer is garbage. It only means that we acknowledge that software development is a Bayesian process. We start with some priors, and we update them as we go. Aspects of process like Agile and TDD slow down the updating mechanism or stop it altogether because we get entirely too sunk into our priors. Waterfall is an assumption that we can verify our priors and they will not need updating. TDD bakes the priors into the code, and Agile incorproates the initial priors into a process. All three approaches fundamentally defeat the learning process in one way or another.

Process is fundamentally bad for the exploratory and learning aspects of software development. Software Development is an inherently creative activity that needs freedom to learn from mistakes and adapt to them. Being free from constraints and able to experiment is a necessary step in designing good architecture.

But it is very difficult to get institutional buy-in for taking out the trash. So here are some strategies I've found to help make that more palatable:

• Write your MVP in a language that you don't know very well or a language that isn't generally supported by your company. Are you mostly a Python shop? Write your MVP in C# or Clojure. Are you a mostly functional language team? Write the MVP in Ruby. Or possibly write it in a meta language that can compile to multiple different langs like Nim. The possibilities here are endless, and you probably need to make sure you get the sign-off from your boss. The point is to do something that's guaranteed to get garbage collected. Plus, you get to learn more about a new language. If your boss' boss' boss' boss' boss is like, "I want this in production now!" and your boss is like, "Yeah, we don't have the ability to support brainfuck in prod right now. We need a v2 in common Lisp." That's a lot more likely to get prioritised than, "Well, yeah we could push that to prod, but we shouldn't for various technical reasons that you don't understand, Mr. CEO."
• Write integration tests as soon as you start seeing adoption. These don't require any specific implementation details at all. Just exercise the API. You can do this with make or bash if you want. You don't need anything fancy. It gives you some amount of stability, as well as a good starting point for v2.
• Speaking of, v2 should always be on your mind when you're writing your proof-of-concept. Always expect to want to have done things differently. When you actually get the go-ahead to work on it, notes and integration tests are a fantastic little love letter from your past self to your future self.
• Always have a deployment process. Bash script, Ansible playbook, Makefile, whatever. Always have a thing you can call in very simple terms that will get a new version deployed to users. You are going to have a situation where some user bumps into an edge-case and the fix is like one line of code, but it's been 3 months, and you don't remember the exact incantation to get it out there. Document it. Script it. With something.

I've bagged on almost every methodology that exists in this article, but that doesn't mean that I think they are all bad. Reality is nuanced. And this article is about a specific scenario revolving around MVPs or proofs-of-concept and how to get those into production.

But that doesn't mean I hate these methods of getting things done. In situations where developers really know the space, any of them could be real options. For example, I've implemented banking systems based on ISO-8583 twice, for two different companies, using two different programming languages. If someone came to me and asked me to do it a third time, first of all: no. But second, I would waterfall the hell out of that because I know what's needed and how sideways it is going to go. If someone asked me to work on, say, music composition software, I would TDD the hell out of that because I have the domain knowledge of a music theorist and composer already.

I'm not suggesting that these things are inherently bad. I'm saying that they don't account for the garbage that we create as we are learning, and that is bad.

We need to find our trash and take it out.