It’s been 3 months since I started working on the Kindle team at Amazon. I have been asked by a great number of people some form of the questions “what’s it like” “do you like it” and “how does it compare to Microsoft?”
It’s my intention to answer the first two questions, but not the third. It would be impossible not to try and read into my answers and deduce my feelings of the third, but I leave that to the reader. This particular posting is likely to read more like a recruiting piece for Amazon, directed at a specific type of person.
To level set for the reader, my title is Director of Product Management for Kindle Cross Platform. I am not writing code, nor considered an engineering resource, but as a product management team, we do drive business requirements, form and function of the product, and manage the business. The opinions expressed here are my own.
The short answer is: I love it. The company is full of some very smart people, and the missions that the groups are taking on are not insignificant. Three months still puts me in the honeymoon phase, but there is a statement I made to my wife after the first week which still holds true (and she cringes every time I say it): “I haven’t left work once wanting to punch anyone in the face.”
Sure there are little things to gripe about, like the commute and paying for surface street parking. I can’t say that I am a fan of the laptop I was issued (man does it suck), but I’m not a developer, so I can’t really complain about the machine. It’s more than enough to get my work done. The wretched evil of the credit-card-accepting snack machine is unspeakable. However, there are a solid number of themes which have emerged over the course of my first 3 months.
Civility
One of the very first things I noticed was the level of civility on the part of employees. That may sound strange to some people to read. Perhaps thinking “who would want to work, or continue to work, at a place where people aren’t civil to one another?” There’s a reason why entire sit-coms have been made about the work place environment.
Even in the face of open disagreement about a particular topic, there is always a level of respect that between employees. There is a key leadership principle at Amazon which is “disagree and commit,” which is explained as:
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting.
What’s important to take away here is that there is no presumption of stupidity on the part of the speaker. I know I have been in many meetings where a decision needed to be made, and there was almost a palpable sense of contempt emanating from people in the room, each just waiting to pounce, willing to derail an entire meeting on some point of minutia, just to show how smart they are and how stupid the speaker is. It’s a toxic and corrosive ethos, and is (as of yet) unseen at Amazon.
This particular set of behaviors really speaks to the strength of the establishment of culture at a company, and the lasting effects that culture can have on a company, and the people who work there. Those 14 management principles are on the Amazon career site. They are presented as part of the new employee orientation. When interviewing candidates, we are to probe for character traits which align to these principles. This constant reinforcement ensures that the cultural precepts are clear. The end result, unsurprisingly, is behaviors match what the cultural values.
Docs Over PowerPoint
The written word matters a lot more at Amazon than any place at which I have ever worked. In any meeting where a decision is to be made, or a review of any kind, there is a set document type which is to be used to drive the meeting. The topic is set ahead of time, and the meeting owner brings the document to the meeting.
What makes this process so interesting is that there is little to no preselling/politicking of decisions. By beginning meetings with a set time period to read the document (anywhere from 15 to 30 mins), the team can process the doc and an informed discussion can be had. The docs are limited to 2 pages for a shorter discussion, and to 6 pages for longer reviews. Appendices can be attached, most notably containing a FAQ. This structure forces clarity of thought, refined thinking, and organization of ideas. It’s easy to hide that you don’t know what you are talking about in a PowerPoint deck. Not so much in a 2 page Word doc.
I have to admit, when I was first being recruited and someone tried explaining this concept to me, I had a very strong adverse reaction. Not sure why. Maybe because it was different. Having now lived through a few doc creation exercises, I much prefer this as a device for driving decisions in a company where projects have many stakeholders.
Meeting Culture
I have worked at places where meetings are a badge of honor. The more meetings you have on your calendar, the more important you are. That if you were not invited to a meeting, well, you had to reconsider whether or not you mattered in the overall company structure.
Amazon appears to have a completely different point of view. Within the Kindle team, I am pretty much free to go to whatever meetings I want. All you have to do is request to be invited. There are some meetings where people can’t do this, but for the most part, anyone can attend. The decision about whether or not to attend is really an exercise for the employee. The unasked question is: “is this meeting the best use of your time?”
Meetings at Amazon are not a badge of honor. Meetings with SVPs have attendees from all levels. It’s very welcoming and refreshing.
On the topic of meeting culture, it is unbelievably surprising to see the level and depth of knowledge VPs have in meetings. They are incredibly broad, and very deep, in understanding their businesses and their partner organizations’ businesses.
Email is sometimes open during meetings, but not in the smaller meetings. When there are large readiness meetings, people who need to be there to present their part will certainly do email, but in the smaller meetings, which have a focused agenda or a necessary decision, computers are generally closed.
Slightly off the meeting culture topic – it is so nice not to be ruled by email. Email disasters are not fun, and even less so when the entirety of the company culture is email driven. My email volume is way way down. Way down. For the first few weeks, I had to keep checking to make sure that the Live Tiles on my phone (yes, I am still using Windows Phone) weren’t broken.
Deferring to SMEs
There is a great deal of deference to the subject matter experts (SMEs) on most topics. Even when there is a meeting to present some feature to an SVP, the feature owner is often called upon to do the demo or walk through, not the direct report of the SVP to whom this feature rolls up. The questions are directed at the SMEs, and the managers let them speak. No, that’s not quite right. They expect them to speak.
I was in a very senior meeting in my first week, and one of my team members was speaking. He made a small mistake, and one of the VPs tapped me on the shoulder and said “hey, a teaching moment for him later is…” Think about that. He didn’t call the SME out in the meeting. Didn’t denigrate him, or even tell him directly. He told his manager, and he did it very discreetly. I was really impressed.
Division of Labor & Ownership
There’s plenty of work to go around. I heard someone once say that Amazon does the work of 10 with 7 – it ties back to the frugality principle. I can’t vouch for that statement, but I can say that my team owns quite a bit more than I expected coming into the role. Should the opportunity arise to take on more work, there is no penalty in asking for more resources. Provided there is a business case to be made, you can generally get the resources. Of course, resources don’t grow on trees, which makes staffing up a fun exercise. You may get the allocation, but you still have to find the bodies.
Due to the fact that teams are consistently stretched, everyone has a very high degree of ownership of their features/projects/teams. It’s wonderful. Amazon is a company with plenty of business problems to go around. There hasn’t been entire teams and divisions spun up to deal with process problems. When you have teams whose sole job is to improve or optimize process problems (and not business problems), it should come as no surprise that processes get invented. Further, when ownership of work is so diluted to the point that it is almost meaningless, people are likely to fight like hell to hold on to whatever they have left. This fundamental misalignment of priorities has not been something I have as of yet witnessed at Amazon.
There is very much a belief of helping teams be successful. This is taken as far as lending people and headcount to other teams so that they can meet their dates. We literally will ask people to go spend a month or two working with another team to help get something across the finish line. This is interesting for a few reasons. First, the breadth of experiences to which one can expect to be exposed is welcomed. Second, this mindset allows people to ask for help without fear of reprisal. I have seen this manifest itself as more transparency in intra-group communication and more team work. The enemy isn’t other teams pilfering your resources, or fear of looking bad in front of other teams. One of my favorite quotes is readily applicable here: “circle the wagons, and point the guns outside.”
Big Problems With Long Term Vision
I can’t really say much about some of the things on which I am working. I can say that the goals of some of the teams are huge. Huge. There are 3 core businesses in which Amazon is playing, and each of them on their own is enough to drive a large degree of change in the world.
I’m lucky that I get to work on a product that I really love, and loved before coming on board. In some ways that’s suboptimal, because I am riding on the shoulders of giants who have created amazing product long before I showed up. That said, I can say I had been here less than 3 months when I got the nod to go look at some completely new business opportunities. High pace. Big problems.
I think the anecdote which sums this one up best has to do something my SVP said to me on a phone call during my recruitment process. He closed me with one line out of a 30 minute conversation, and I’m not sure he knew it at the time. He said, “the goal of Kindle was to enable a system to allow someone to buy any book ever published, and have it delivered anywhere in the world in 60 seconds. It’s time to think bigger.” Mind. Blown.
Success Factors
So what does it take to be successful at Amazon? I have no idea. Not fully anyway, though adhering to those management principles is the right direction. What I can say is that it’s much closer to the startup pace than I had even at one of the other early stage companies at which I worked. The pace is high, no doubt about it, and there are certain people for whom this is not an ideal work environment. That’s not to say they don’t measure up. Not at all. Take 100 people, and you will find some people who are great for a small business (which is different than a “startup”), people who are great for a tech startup, people who are great for government work, and people who are great for big companies. There are some people who can be successful at more than one. It’s really important to know what kind of person you are.