Comment by throwaway9191aa | Hacker News Reader

Comment by throwaway9191aa | Hacker News Reader

Parent Full thread

throwaway9191aa

> Practically the definition of "process over people". There are certain types of people who thrive in that environment. The people I've seen be successful there are either people who successfully disassociate their working lives from their personal lives or who are engineers with high technical ability but lacking social skills.

That has been exactly my experience, after 5.5 years. My team spends 4 hours in sprint planning every week (there are 9 of us). It is way more important to try to plan out work than it is to actually do the work.

> The bigger problem I have with the company is the types of managers that environment creates. The primary function of a manager at Amazon as far as I can tell is to enforce process and the secondary function is to maximize output of the people reporting to them.

I did burn myself out trying to reduce operational load. I wasn't arguing for it the right way, so I ended up doing it myself. I was able to measure my results, but it didn't even count towards a promo because I didn't "harmonize discordant views"... instead I just did what needed to be done.

Many many folks inside Amazon say it has a startup culture. That is false. Try to find out how many of those folks have actually worked outside Amazon before taking their advice.

> My team spends 4 hours in sprint planning every week

That seems excessive, but I don't know what area you work in. Does your team need to spend that long? I have heard of that happening within Amazon, but then people vote with their feet and move to a team that doesn't spend four hours in sprint planning.

> Many many folks inside Amazon say it has a startup culture.

I've spent roughly as much of my career at startups as I have at Amazon. It's a bit of a mix bag. Having worked at start-ups that had to spend time doing undifferentiated work (just getting automated deployments, for example), it's in some ways nice not to deal with that, and yes, you have to follow The Process for that to be easy. I sometimes see people taking chances and acting quickly on new opportunities. But yes, I also see people not taking chances when the cost of doing so would have been small. Then again, I once worked for a start-up where you had to use a particular template for a design document, and you had to produce a project plan that 6-month long projects that was accurate to the hour. So... I think it's hard to make generalizations.

Why wouldn’t it be more important to plan out the work than to do the work? We’ve all seen the graph of how much more expensive things are to change the further down the process is.

I absolutely think you should plan out how your customer will solve their problem with your product, including concrete examples, and make sure you are always headed towards that goal. I'm very waterfally that way.

In this case I'm talking about the tasks in each sprint. I think 1 day of planning per sprint is a lot. We are supposed to be agile. If we missed a task, swap it with another. If something isn't actually important, bring in something new. We end up doing this anyway... so why all the upfront planning each sprint?

Related back to the above comment, (my opinion) people really love to establish rules and processes and are not able to handle ambiguity. I spend a lot of time (remember the 4 hours a week) arguing whether a story is a mouse or a hedgehog.

IMHO it's splitting hairs, let's just do the work and we estimated a little wrong it just isn't that important.

I don’t work for a service team. I work in Professional Services. I was working on a project and I found a bug in one of the APIs. I reached out to the service team and they found the bug - it was a 3 line change in some front end code (long story). They put a fix in almost immediately. But as I was tracking the weeks long deployment process across regions, I came to appreciate how costly any changes are at the scale of AWS. You have to measure twice and cut once.

My implementations are for a specific customer and I don’t have to worry about that type of scale where a mistake or miscommunication in requirements can be costly and affect hundreds of customers.

I have made mistakes as a contributor to a popular company sponsored open source project. Even that caused headaches beyond the scale I was use to dealing with.

Oh yes, the pipeline deployment process is pretty amazing. I agree, for good reason. My manager has actually recommended I look at profserv teams because of the ability to deliver results for customers.

When I started in AWS, I watched customers implement hack solutions for themselves because it would take our team too long to deliver a proper solution (so hard to give specifics on HN :) ). That was the hardest thing for me to handle. The mindset is what works best over the next N years, not what works best for a set of customers right now.

Honestly that is the right mindset. Early adopters know they are early adopters and will have to work around problems.

I think the take away from this conversation, for anyone still following, is that a lot of developers (like myself) want to move really really fast. AWS has processes in place to prevent this movement from breaking customers. While it is so annoying for me, it really is a win for customers.

FYI: I think you responding to the wrong parent comment. :)

Reply on news.ycombinator.com