[dangrover]

I was a PM at Meta from 2016-2022. I work at a startup now and have to write detailed specs and deal with lots of small details —- something I was discouraged from doing as I rose in rank at Meta and scarcely did after the first year. Looking back, I don’t even remember what it was that I did if not that —- lots of strategy docs, aligning other teams, but no specs. I am having to unlearn a lot of bad attitudes and habits to do new gig effectively.

I remember when I left feeling funny that there were as many people working on metaverse stuff as were in company when I joined (like 16k), and it’s mind boggling to me now that the layoffs are affecting around same amount.

[wpietri]

Are you excited to be writing lots of detailed specs? Especially in a startup, that seems terrible to me. When I've done startups, one of the best things for me about them was close collaboration with the product/design side of the house. Detailed specs would have slowed that down significantly for us.

[adjkant]

I've noticed that people can conflate "detailed spec" with "terribly meticulous process". Close collaboration with design/product doesn't mean that writing things down isn't useful, and can come in handy specifically:

1. When capturing complex logic areas, especially if related to any areas that are related to money or legal considerations

2. When onboarding new people on any side who need to learn about or get context on a product (product, design, eng)

3. When you revisit a V2 3 months later and forgotten what decisions you made or why you made them

Lots of detailed specs to me sounds like a fast velocity of products and totally compatible with startups. That said, you also added the word "lots" that OP didn't use. It could just mean two or three!

[neltnerb]

I would go further even and say that for any team that doesn't all do just one thing, developing the spec is half the work.

Once all the interconnections are figured out and the mechanical engineers know what needs to hold what shape at what temperature and pressure, and the metallurgists know what chemicals will be touching the metal, and the power connectors to sensors are all numbered so you know how many you need and where they'll go, and the communications lines with what format and inputs/outputs they'll talk to at what voltage... to me a spec is the document that tells everyone where their little part needs to fit.

You have to do that downstream and collect it back upstream for larger projects, since the person doing it never has enough expertise. And then the spec negotiation between teams that don't really necessarily know what constraints each other has which need to be resolved so that people know what to design.

It's frustrating but actually writing down a detailed spec really does enable a lot of other stuff to happen. I'm sometimes blocked as an individual because of a team that's in my path but which isn't really in my field. Say, they do optics and I design the optical sensor so I need to know the optical power to expect but they have to do simulations and get information from the chemists and semiconductor test engineers first. I need a spec for what they want -- I need to know how low the light level is, how much noise there is, and lots of other little details too.

I don't know if that qualifies as "terribly meticulous" but in my experience skipping the spec step often means wasting an incredible amount of time solving the wrong problem.

[adjkant]

Yep fully agree! I wanted to highlight some areas that devs may immediately "get" but "developing the spec is half the work" really should be shouted from the mountaintops.

[nojvek]

Amazing. Love PMs who can dive into details and clarify edge cases.

That’s half the battle of writing code.

At our startup, the philosophy is to “first write code without writing code”.

This gives clarity of problem and proposed solution to weed out edge cases, before going too deep into implementation phase.

[AlotOfReading]

In a prior life I was an archaeologist and would visit these amazing structures, built by literal dozens of people working together making steady progress over time. It was gratifying to see that incremental progress reflected in the excavations as well. Even if you were doing something as slow as cleaning a cobblestone walls/paths with a brush, over a couple weeks a few people could clean a surprisingly large fortress.

I don't feel the same about some of my years in tech. There are periods where I can't remember doing much of anything that could be called progress, even though I know that I was "meeting with stakeholders" and other ostensibly important things. There's this diffusion of responsibility that occurs in large orgs where everyone is micromanaging some infinitesimal slice of the mission while communication overhead and "following the process" consumes unimaginable amounts of time.

It's hard to not want to throw the baby out with the bathwater and desire some kind of self-governed organizational anarchy, but I'm not sure where I think that line is best drawn.