kaspm
Joined 14 years ago
Joined 14 years ago
There's certainly SOME PEs that go deep in some areas but the majority I've worked with are broad owners of technology in large organizations. The difference between the two roles often has to do with what balance of time you want to spend influencing others for broad goals vs. building up jr. folks to accomplish your team's goal.
In either case your authority is derived from whether people "under" you want to work with you. People who can't get a set of people to go a certain direction won't last long in either role.
If there are tickets, read and understand all the tickets, organize them in a way you can manage day-to-day.
If you're working off some other spec, start breaking it up into individual tasks that can be managed on a spreadsheet or in a ticketing system.
If you're working off general guidelines without documentation (and you can't run!), start by writing out all the tasks that need to be accomplished to finish the project. Even if they are brief.
Now take the list of tasks and organize them into 2 "types"
Stories: Tasks that deliver value to the end user
Tasks: Tasks that are required or nice to have to enable 1 (Tasks or Chores)
Now prioritize those into different buckets
1. MVP: if we don't ship this, the project will fail
2. Nice to Have: Someone _really_ wants this but it's not MVP
3. Phase 2
The more scope you can put into bucket 3 the more likely you'll be able to deliver _a_ working, functional project on time. You will get more credit for delivering something _good_ than failing to deliver the perfect project.
Your team will also thank you for taking significant stress off their plate and for making them a success.
1. he misspoke and meant "80%" of the AWS capacity, which I agree seems implausible. 2. Amazon does not run on AWS because Amazon is 80x more than all of AWS infrastructure. This also seems implausible because of Netflix. In fact, there's an article out there that said AWS exceeded Amazon's capacity within 1 quarter!
I still don't understand what that has to do with autoscaling exactly
OR there wasn't backpressure on a cascading failover so as services failed they increasingly failed to more and more overloaded systems
OR there WAS backpressure and it was the luck of the draw whether you were queued into an error page or got good data
OR the autoscaling couldn't keep up with the onsale window. This used to happen in ticketing a lot. Ticketmaster has a talk somewhere where they talk about warming the scaling load and server cache in anticipation of big ticketing onsales. The time it took to autoscale was just too long.