<!-- Content Here -->

Amazon: The Good Parts

I have been reflecting on my Amazon experience and, while the company has plenty of issues that I am happy to be free of, there are a few practices that I plan to take forward in my career.

Writing Culture

You may have heard about Amazon’s “peculiar” meeting style where the first half of the meeting is spent silently reading a document and the rest is for discussion. Writing out ideas is so much more effective than talking through bullet points on a slide or having a free form discussion. The writer is forced to think through their recommendation, fill in gaps, and fully support assertions with data. Clear writing requires clear thinking. While a deft speaker can gloss over inconsistencies or ambiguity, those deficiencies have nowhere to hide in a document. Documents accelerate the decision making process by organizing all of the inputs and making sure all of the decision makers are fully informed. A good document anticipates skepticism and brings supporting information into the conversation rather than requiring a follow up. You don't waste any time debating facts or jumping from topic to topic. Often the meeting ends with a decision, or at least a concrete list of factors to address. Plus, the reasoning behind the decision and related commentary is fully archived to revisit later.

Leadership Principles

Amazon’s Leadership Principles are the lingua franca of the organization. All Amazonian’s know the LPs by heart and use them in their reasoning. In a performance review or promotion, a manager might be asked to provide an example of an employee “Diving Deep” or “Inventing and Simplifying.” In a strategy discussion, you might consider which option demonstrates more “Customer Obsession.” The LPs seem simple and obvious on their surface, but you come to appreciate the nuance and tension between them. For example, “Bias for Action,” which might lead you to charge forward with an experiment, can seem in conflict with “Insist on the Highest Standards,” which counsels thoroughness and perfection. The LPs make you think and they give you language to discuss your ideas. As an example of how seriously Amazonian's take the LPs, I remember some great conversations about how the two newest ones ("Strive to be Earth’s Best Employer" and "Success and Scale Bring Broad Responsibility") lack the clarity and guidance of the others. So a group shared revisions that I think are much more useful: "Lead with Empathy" and "Build Sustainably." These versions were never officially adopted but I saved the definitions here.

Hiring

Amazon was aggressively hiring for most of my time there. The process was designed for efficiency and effectiveness. Everyone on the interview team had a plan for what areas they were evaluating. They were responsible for finding supporting and contradictory evidence of proficiency in the areas that they were interviewing for. Interviewers were required to submit their notes and their conclusions (inclined or not inclined to hire) before the review meeting. During the discussion, everyone on the team was expected to challenge unsupported statements from their peers. For example, you couldn't say that the candidate "seemed aloof," you had you give an example where they tolerated substandard work and describe the implications of that behavior. By pushing each other and accepting feedback, the interview teams were able to identify and weed out unconscious bias. I was also impressed that Amazon was able to maintain high standards despite the hiring frenzy that all of the big tech companies were engaged in.

Amazon is a huge company and some groups only go through the motions rather than get the full benefit of these mechanisms. But the fact that everyone at Amazon is trained to use them is an incredible strength for an organization if leaders are able to walk the walk.

RTO Mandates

Here is an interesting Fortune Magazine article about the backlash to Return to Office (RTO) mandates: "We’re now finding out the damaging results of the mandated return to the office–and it’s worse than we thought". In addition to the inconvenience of getting to an office and the inflexibility of not being able to interlace small home tasks in your work day, this article made me think of the “mandate” aspect. Edicts like these send the message that the employee is less valued for what they can achieve than for doing tasks in compliant ways. The top down nature shows how little power the management chain has to support the team and advocate for individuals.

Virtual Talent Advantage

With their "return to office" mandates, many companies are signaling an inability to adapt their culture and/or processes to effectively manage a remote workforce. There is a significant population of employees who have thrived while working remotely and are unwilling or unable to go back to a traditional office setting. For example, an employee may live in different part of the world, their commute may be too long, they may need a more flexible workday, an office setting may aggravate mental health issues or subject them to discrimination or biases, they may have a disability and their home office offers better accommodations... the list goes on. This is great news for companies who are able to "crack the virtual code" because the "RTO" trend gives them access to talent that they could not otherwise lure away from "Blue Chip" employers. Many of the people who are searching for remote work are doing so because they perform better remotely and employers will benefit if they can tap into this talent pool.

So how to crack the code? Here is my quick list of company characteristics that are conducive to supporting a healthy and productive virtual culture.

• Aligned Strategy and Goals. In their book Extreme Ownership, Jocko Willing and Leif Babin talk about how effective leaders are able to communicate goals, set parameters and expectations, and empower people to execute. It helps for a leader to welcome doubt and an opportunity convince their team on the thinking behind the strategy so team members can make better decisions and align others. When someone believes in the strategy and goals, they become internally motivated to act independently and can adapt to changing information. They don't need as much supervision to get results. They don't go through the motions or waste time on superficial expressions of dedication (like face time in the office).
• No Hybrid Teams. While a company can be "hybrid" (part colocated, part distributed), a team should be either colocated or distributed. Sprinkling remote workers into a colocated team creates communication gaps and unhealthy dynamics. When a team is fully distributed, they use tools and build mechanisms that are optimized for virtual collaboration.
• Content Culture. Distributed workers can't rely on peers being available to answer questions during every one of their working hours. Instead, they need to be able to rely on "content" (documentation, notes, plans, updates...) that can be shared across space and time. Distributed workers need effective writing skills to produce assets that will become the ground truth and shared understanding of the team. And there needs to be a culture that values the availability and accuracy of documented information.
• Social Effort. Social connection doesn't necessarily depend on continuous physical proximity. People can coexist for years without even learning each others' names. Whether you are colocated or distributed, you need to intentionally reach out to connect and build trust. When your team is distributed, you need to be more intentional because you don't have constant access to body language and other signals. This includes checking in on each other because silence can mean many things. It's also important to schedule periodic get togethers for team building. Pro-tip: going to a conference with your team is a great way to learn, socialize, and get energized by new ideas.
• Recruit Experience. Organizations that hire entry level staff and practice "up or out" career management often struggle with the remote model. New graduates need highly visible role models and professional socialization that is harder to get in a remote setting. Coaching needs to be more interactive and personalized. Young professionals also tend to have less of a network or community for emotional support. On the other hand, workers who already have a professional foundation and are looking for remote positions have probably already established family and community that they need to balance with work.

Comfort is the single most important factor of change management

I have been reading some articles on digital transformation and change management and I am surprised about how little attention is given to the notion of comfort. The reason why change is hard is that it makes people feel uncomfortable. And when people are not comfortable, their confidence, morale, and productivity suffers.

At the very least, there is the loss of familiarity. Habituated routines that once hummed along on the edge of our consciousness all of the sudden require direct attention. Tasks take longer to do. Mistakes are made. The confidence of mastery can feel threatened.

There is always a group of people who benefited from the old way of doing things even if that way was inefficient or dysfunctional. Dysfunction can create jobs or mask poor performance so don't assume that everyone is onboard to eradicate it.

There is great advice for assessing change readiness and rolling out change. But be aware that the resistance that you feel is a primal tendency to seek and preserve comfort. In addition to your conventional change management best practices, focus your attention on people whose comfort will be the most impacted. These will be people who have developed mastery over specialized skills and knowledge or have accumulated power from the current dynamics. Think about what benefits would be the most motivating for those groups to buy in. If you don't have their support, you can count on their interference.

And remember to measure the impact of a change after people have had a chance to re-equilibrate and form new comfortable habits.

Silos everywhere

It is fairly typical for a consultant or new leader to walk into an organization and see nothing but silos. These leaders regard silos as a barrier to efficiency and make them a target for change. What they often wind up doing is replacing organically formed structures with new ones that look better on powerpoint than in practice.

Why does this happen? Let's start by digging into what a silo is. "Silo" is usually used as a derogatory term to describe a grouping that you don't like. But groupings are important in large organizations because the number of possible point to point connections makes communication too noisy and prioritization too difficult. If everyone is talking to everyone all the time, nothing gets done. Teams naturally form to confront this challenge. Complementary capabilities are assembled and scaled in highly focused work groups. Process is continuously refined because of a tight feedback loop.

To the outsider, trying to navigate these structures is confusing and frustrating. People seem unaware of what is happening outside of their group. They appear oblivious rather than focused. The reactionary impulse is to criticize the duplication of what appear to be identical functions. The ego feels good when you think you see obvious dysfunction that nobody else recognizes. It certainly feels better than having to slog through complexity that everyone else understands.

But there is great risk in introducing sweeping plans to achieve synergy before really understanding how these teams function. Even if the reasoning is valid, it is incredibly disruptive to blow up any working system and make it re-form under stress and uncertainty.

Before eliminating "silos," you need to understand why they formed. Were they imposed from the top down in order to make the organization easier to understand from the top? Or did these structures develop naturally to solve operational problems related to coordination and focus? Can the same benefits be achieved more efficiently?

You can't fix a working system until you fully understand why it is the way it is. You need to understand what is working right now and what obstacles stood in the way from the system naturally adapting to solve its broken parts. When you hypothesize dysfunction, you need to introduce your corrections scientifically and measure the results. But most importantly, you need to find the best parts and figure out a way to expand on them.

When remote working doesn't work

As a long time remote worker and manager of both distributed and co-located teams, I think about virtual teams a lot. While I have had great personal experiences with remote teams, there seems to be little consensus about whether it is a good idea. You have some articles touting the health, retention, and productivity benefits of letting people work from home. And you have other articles, like the recent Atlantic piece "When working from home doesn't work," that indicate a shift back to traditional office environments. Based on my own experience, I find it hard to imagine large companies succeeding by dictating enterprise-wide policies around remote workers.  The effectiveness of distributed teams depend on critical factors that will vary from team to team. Here are three things that undermine the effectiveness of distributed teams.

1. Hybrid teams do not work

2. You can't convert a colocated team to a distributed one

3. Not everyone will thrive as a remote worker

How to have success with technical freelancers

Over the past year, I have had the opportunity to work with some excellent technical freelancers. These relationships have been both professionally and personally rewarding. However, I also understand that for every one freelancer success story, there are many disasters. In fact, as a consultant, I have made a living out of cleaning up freelancer messes. Here are five tips to help you be more successful with your freelancers.

1. Don't use a freelancer to bring in a skill that you don't' already have in your organization

   If you hire a freelancer to do work that your team doesn't understand, you are setting yourself up for trouble. First, you will have no way to evaluate his/her level of skill and the quality of work he/she produces. Second, you will not be able to maintain the code or systems that the freelancer builds when the project is done and she moves onto other projects.

2. Use a publicly hosted distributed source control system (DVCS)

   Host your project on an externally hosted Git or Mercurial repository. This will allow you to try out freelancers with minimal risk. They can fork your repository and take on some development tasks and you can review their work before merging it into your own repository. If a new freelancer doesn't work out, just disable access.

3. Cast the net wide and filter

   The only way to really get a sense of skill and compatibility is to start working with someone. People who look great on paper and can talk a good game are not always as competent as they appear. It is also easy to dismiss diamonds in the rough. Some of my favorite freelancers were very shy when I started working with them and would have been easy to overlook. With a DVCS and the ability to review work, you can assign development tasks to several developers and see who rises to the top. Just be sure to assign meaningful work and pay freelancers for their time.

4. Connect

   Respect, trust, and communication are all critical to any relationship (personal and professional). Even though your working relationship with them may be shorter, treat freelancers with the same respect that you would give to a full time colleague. If the freelancer comes from another country, you have a great opportunity to learn a little about his/her culture and make a friend in a far away place. From my work with freelancers, I have seen a side of international current events that I would never see on CNN or the BBC. When you have these strong bonds, you get better commitment, better product, and a more enjoyable working environment.

5. Learn comfort zones

   Everyone has their strengths and weaknesses. In a new working relationship, it is natural for anyone to underplay their weaknesses. Who starts a job interview by listing all the things that they stink at? The only way to understand someone's strengths and weaknesses is to assign a variety of tasks and see what comes back. Usually, people will start with the work that they feel most comfortable doing. Once you have recognized a few strengths and built a level of mutual trust, you can have more candid conversations about comfort zones. Some people like to focus on work they have the greatest confidence in doing. Others like the challenge of learning new things. The greater understanding you have about personality and comfort zones, the better you will be able to assign work and also evaluate work product. For example, if one particular developer likes to stay inside his comfort zone, you should just assign tasks within that skill area and you can be confident that the work will be done well. If a developer likes to learn new things, you can assign him challenging problems but you better have more rigorous quality controls.

I honestly feel like this is the future way of working. Through strategic and effective use of freelancers, you can make your organization more nimble and responsive. Companies that are not able to use freelancers will be slow to start new initiatives or avoid doing them altogether. On a personal level, you can learn so much by working with a diverse set of freelancers with different experience and styles. It is also nice to build new friendships — it's even more fun than having a pen pal.

Diving into the talent pools

Even in this down economy, finding technical talent can be extremely difficult. Résumés are worthless. It comes down to this: programming is a craft but we don't get to see the craftsmanship and creative process when we hire programmers. At least not before we narrow down the application pool of thousands to a short list of real candidates. After that, during the interview process we can do things like logic questions and programming exercises to see how the programmers solve problems.

The issue of finding talent is a very real concern not just for start-ups but also for established organizations that are selecting technology (like a CMS) that they must staff up to support. The natural tendency is to go by the numbers. Choose a technology with a "household name" like Java, .Net, or PHP where programmers are a dime a dozen. You are bound to find a needle in a haystack that big. Where this logic breaks down is that when a technology is so widely known and used, everyone seems to have it on their résumé. You can't tell if the candidate just spewed out a few hundred lines of crappy code or if they have immersed themselves in the technology to the point where they understand the core principles and philosophy. You can't tell if they are a talented craftsman and are able to learn new things. By selecting a household name (commodity) technology you have just made the haystack bigger without necessarily adding more needles. It is hard to find a Jamie Oliver by putting out a search for people who can make a hamburger.

When it comes right down to it, a language is just syntax that lets you do things like assign variables, create conditionals (if statements), and loop through lists. Learning what is available in libraries is the true learning curve when it comes to a technology and those libraries are constantly changing. So a good programmer is always learning. One of my favorite books about programming (The Pragmatic Programmer: From Journeyman to Master

) recommends learning a new language every year to expose yourself to different approaches. The best programmers love the challenge of learning a new language or framework. They read books on different technologies and practices. If I was hiring a PHP developer, I may get an even better result if I found a great Java developer who is open to working in PHP. Of course, then I would have to find a great Java developer. If I was looking for a great Java developer, I could see myself looking for people who have worked in Python, Ruby, Groovy, or even Scala. That would show that they are committed to learning new things rather than churning out code the same old way.

When you look at it this way, the relative size of the "talent pool" should not drive you to a technology choice. You want to choose a technology that has proven itself to be more than a fad so that it will continue to evolve and mature. You want to work with a language that has good resources for learning (like articles, books, IRC, and mailing lists). But you don't want a technology just because a majority of technologists claim to know it. Most importantly, you want a good programmer. If a technology is sound and effective, a good programmer will be able to learn it and be productive with it.

Website Product Manager

I often tell my clients that every website needs a "product manager." This is the person who ensures that the website is meeting the needs of the customers (the audience). A product manager understands the customer and prioritizes the enhancements of the technical platform as well as the production and maintenance of the content. The product manager may not have deep technical experience in software architecture, information architecture, writing, or graphic design but needs to bring these disciplines together to create a product that is useful.

I have recently come across two very good articles on product management. The first is Program Manager by Joel Spolsky. He calls the role a "program manager" and narrowly focuses on the discipline of software development. His program manager leads a small team of developers to build an application (or a subset of a large application) by writing a functional specification that defines the product's vision and behavior. The article nicely describes how the product manager communicates with and manages a technical staff.

The second article is Internal CMS Product Management by David Hobbs. In his article, David focuses on the web content management system as the product and the users of that system as the customers. This role is particularly visible during the initial CMS implementation but is important throughout the system's lifetime to keep it relevant and useful. Requirements always change — not just when the business changes but also when it learns and learning is inevitable with a disruption like a new CMS that may streamline processes and create opportunities. People change too and they may need different training and/or encouragement as their responsibilities change. Too many content management systems fail from post deployment neglect. Always budget for continuing maintenance and enhancement of the system. Practicing the advice in Hobbs's article will help you avoid those pitfalls.

But, as I mentioned earlier, I think that the real product is the web site itself — not the content management system. A great CMS is worthless with bad content. We manage content because it is (or should be) valuable to an audience. A CMS doesn't make good content, people make good content. The best a CMS can do is eliminate some of the barriers that prevent users from making good content. There are plenty of other barriers that the CMS can't eliminate: no time, no interest, no incentives, no skills, etc. The product manager needs to address these as well.

I don't think that I am asking too much for a product manager to guide the technology and help content producers create good, well organized content. Wikis are a good example to look to. Wikis that continue to be successful after their novelty wears off usually have an evangelist that is constantly tracking content updates and giving feedback to authors (Is this page redundant? Does the title make sense? Is the information still accurate? Is it findable?). When you really think about it, this is the role of an editor in a media and publishing company. Maybe all companies that manage content (even for internal purposes) should think of themselves as publishers and have editors that push their contributors to produce a worthy product.

Communicating Across the Techno Gap

You have probably heard people talking about "dotted lines" in organizational charts. That is when someone has partial accountability to someone other than his direct manager. An org chart notation that I would really like to see is a "flashing red" line. I would use it to show when someone reports to a manager who has no clue what he does.

Any reader of Dilbert knows that this happens all over organizations but the case that I am the most keenly aware of is when a technologist reports to a non-technologist (or, perhaps worse, a former technologist). As a consultant, this is the area where I am regularly deployed. I am often hired by the non-technical manager to help him validate and/or understand what his technical staff are doing. I am also often hired by the technical staff to validate and explain their strategy. Consultants get put into this position because this is an area where companies struggle on their own. They need an outsider to facilitate and verify because communication and trust is so compromised. While I do love this work and would be happy to perform this role at your organization, here is some free advice to get you started so you can make some progress on your own.

Communicating to a non-technologist

Your manager doesn't really understand what you do despite your best attempts to explain it. You suspect that he doesn't care. Maybe he doesn't want to understand. Maybe he can't help that his brain just locks up when you say words like "refactor." You don't feel appreciated. You are about to stop trying.

When talking to your non-technical manager, don't try to dumb down what you say but for every detail mention, make a very clear connection to something that matters to the business. That usually means cost (short term and long term), quality, and impact. By impact, I mean things that will benefit the business: time savings, competitive advantage, etc. Provide inputs for any financial analysis he wants to do.

Don't get bogged down in numbers. Instead, draw comparisons because the units are probably meaningless. At the end of the day, the non-technical manager wants to be reassured that progress is being made and nobody is making "unconventional" technology decisions. An example of the former, is saying that you are "doubling storage" rather than "adding a 500GB RAID 5 storage array." For the latter, say "companies like EBay use MySQL" rather than "MySQL is a fully ACID compliant database."

More important than anything you say is how you listen. Listen to his concerns. Figure out what kind of proof will alleviate these concerns and provide it. Prototyping is a great way to show a technology in terms that a non-technical person can relate to - much better than UML.

Communicating to a technologist

Admit it. You are a little afraid of your tech guy. He has strange working habits and speaks in a language that you only barely understand. Even though you manage him, you have very little visibility over what he does. Unlike with other people who report to you, your advice to him is pretty much worthless because you both know that you have no idea what you are talking about. Whenever you ask a question, the answer just confuses you more. You just stop asking. The scariest thing you can think of is that your tech person leaves and, after drifting helplessly for weeks, you learn that your entire infrastructure is in chaos and about to collapse. What is going on in this technical empire he has built under your nose?

If you don't know anything about technology, you should start learning. Unless you are retiring in the next couple of months, you can only expect technology to become a more important part of the business that you are supposed to run. Have your technology guy help educate you. Ask him about the technical details underneath what you see as a user. But don't just listen to your internal technology people, listen to what is happening outside of your organization. Talk to your peers at other companies and learn about what they are doing. Read stuff online. Hire a good consultant. Share what you are learning with your technical staff in a non-confrontational way. Don't go in with managerial bravado. You are the student - be humble. It is a warning sign if they get defensive when you show a genuine interest.

The best approach for making technology decisions is to describe what you need in very clear terms (your technical person will call that requirements gathering). I like usage scenarios as a way to communicate these things. Ask your technical staff to put together their best solution and schedule time to review its viability and sustainability. Have an open dialog about the implications. Meet regularly with the team - not just at the end to "sign-off."

More important than anything you say is how you listen. Treat the interaction not as manager but as a partner and teammate. You both have the same goals. When the technical discussion gets out of your depth, don't shut down! Instead, connect it to something that you do understand and that matters to your responsibilities. Share the insight that you have about the company's needs and what your boss will ask for.