Feedback on SPD

It's been sometime since I left SPD, so I might not be able to recall things clearly.
I was an IC on the engineering side, mostly working with the new products.
Outside of SP, I have been mostly working in both devs and ops role, with close contact with our direct users.
Hence, the feedback should be taken with this context in mind.

## Good thing
- A few people in the management/leadership position are willing to have direct, honest conversation about the department's direction.
- Culture feels neutral and doesn't have too many nasty people around, unlike many large orgs (at least on engineering side).
- There're attempts to turn things around and there are still people who care about doing this.
- Quality of engineers being hired is slightly above avg.

## Bad thing
- Lack of a product/engineering direction for such a large engineering organization.
  When I left we are still mostly trying to run a few POC and demos, no truly production system/user
  (even what we call prod is not really production-grade).
  -- I think this is partly because different expectation, background. for me, production where you actually care about uptime and that something like 99.99% actually correlate with monetary values. As a result, you have different concern when designing the code/handling incidents.
  -- When I left we mostly run what I 'd consider closed-alpha, or open-beta software. There were a few users, but most of them doesn't need the system to be up all the time (e.g: billing is just an end-of-month thing, and live login doesn't show users much, besides pretty UI for demo).
  -- As a result of this, you could have different concerns when running system (e.g: don't need to try and keep things up all the time, because there're cost associated with that)
  -- This applies in general. again, outside of SPD time my production systems means at least 10k concurrent users => quite different. so it might be just mismatched in terms of my expectation/what we actually do
- Very big division on dev vs ops. For example, devs are not allowed direct access to production.
  This is fine if we are a mature engineering team with tools to facilitate this.
  In reality, running these tools is not cheap and we created artificial work for ourselves building tools,
  instead of focusing on product/MVP.
  -- e.g: logging, CI/CD pipeline, metrics, alert management. iirc, we opt to run these things ourselves with a few (<5) devops, instead of going with SaaS offering (e.g StackDriver, DataDog, etc)
  -- however, anecdotal exp on my side shows that you usually need several teams to keep these up and running, which is a resource we don't have
- Too much focus on scale and reliability at the stage where building the right thing is important.
  There are probably many causes:
  - people not knowing what's truly important (imo, product-market-fit)
  - being told to build for scale when we don't need it
  -- we planned aurora for very large scale, but i don't think it happened. We could have just bootstrapped with a simple PG database instead, I think
  - simply being a large engineering team => people need to find something to work on
- Pay is not good compared to market => harder to attract truly good people who can turn things around.
- Lack of a strong "product" person/team. Most PMs are really just trying to juggle timelines and run scrum meetings.
  This leads to a big focus on processes, making things slower.

## Miscs
- While it was possible for me to stay longer, I dropped out thinking that things was not going to change for the better.
  This is not because the lack of attempt to shake things up, but rather because past attempts have not shown really good result.