Software Engg – First Year Learning : Clément Bataille

I started a year ago as a software engineer at Foxintelligence, a Parisian startup. I previously had 2 experiences as a project manager in IT departments so I had an idea on how to make software. But I learned many new things becoming a developer myself. Here are some.


Writing code that works is easy

Before applying to software engineering jobs for the first time I made some online trainings (mostly freecodecamp, that I recommend). I wanted to show my motivation, and what I could learn in a couple of weeks.

When I started my new job, my first challenge was to write code that works. Which means code that actually does what the specifications say. Almost everything was new. I learned about JWTs, how to connect to a database with Node.js, how Vue.js framework works and technical elements like these.

But after a couple of months writing code that works I realized that this was not the most difficult part. The hardest part is to write code that other people can understand.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Martin Fowler, 2008.

So my next challenge was to write readable and maintainable code! It was also the time when another developer got into the project I started alone. I had to explain and clean up all the parts I was the only one to understand.


Writing good code is harder

So, how do you write good code that doesn’t just work but follow good practices?

First what is good code? Some elements that help considering good code to me.

It’s understandable

Good code is understandable by your co-workers (present and future) and your future self. Everything will be easier if more than one person at a given time can understand what the program does.

For instance, you can start by taking time to name variables, functions or errors the most clearly you can. It sounds easy but a huge amount of time will be saved if functions are well named (getdataid should be banned). Worse than too generic, the function does something different than the name suggests. A function getSomething that also sets something inside it and thus has a side effect: not cool.

Another aspect is an effective code architecture, split by files and by function. So that people can retrieve what they are looking for. It also helps unit tests if you have functions that are well separated and can be tested in isolation.

Errors are caught

Your code is good if it doesn’t break each time there is an error. Which means there is good error handling. Indeed, errors are part of the software, it could come from many different elements. A user using the software in a way you didn’t design for. Data that don’t have the same format as you expected (via user input, API changes, etc). The number of concurrent users that you did not have in development mode or even network errors.

Even if you can’t plan for every error that will appear, you can have a more generic error handling strategy for each case it doesn’t go as expected. For example, for every route of your API, you can encapsulate all the things done in a try catch that will log the errors and send a generic error message to the client. You can’t anticipate all the errors but this way you will:

  1. Have a log of the error in any case
  2. Respond properly to the client that is waiting for an answer (without exposing your internal API errors to the client)

However you should not systematically catch every error. You may need to throw the relevant errors and not sort of swallow the real cause of the problem.

It’s documented

Because you won’t be here forever. Plus you want to save your time answering the same questions again and again. It’s easier to take the time to write how things work. A good start is having a readme up to date, an architecture diagram and comments in the code when something is not clear (a common advice is to explain why and not how).

It’s maintainable

Which means the product can evolve, you can add features, or enhance part of the product without breaking everything and taking too much time to refactor. It’s a subtle art of going fast to iterate (which introduces technical debt) and developing thinking about the future to be generic enough for evolution.

How to write good code?

Once we have an idea on what good code looks like, how to help people applying those principles?

To me there are 2 main mechanisms (other than the good will and the knowledge of the developers): the conception and the code reviews.

Conception

As a project manager, my first responsibility was to define the scope of the project I was working on. You need everyone aligned on the scope, because the rest will depend on that. You can’t discuss the budget, the planning, the risks, the resources of the project if you are not clear on the scope.

As a developer it’s the same: the first thing to do before even thinking about the technical conception is to define the scope of the feature. You usually do it with the product owner/manager in an agile organization.

Is this part included in the sprint or not? Can we reduce the scope to have something working (even not perfectly) at the end of the sprint? Is this part core to the feature or a nice-to-have?

Once you have a clear scope, you can start to do the technical conception. You can discuss: the name of your components, your API routes, the data format and what part of the codebase will be affected for instance. You don’t need to discuss every implementation detail or spend hours discussing a function name. But think about the overall architecture and how different parts of you application will be connected. It will reduce the subjective decisions one person will have to make and thus improve the readability and the quality of the code.

Code reviews

In the classic git flow, every new feature is developed on a feature branch and a pull request is made before merging the work into one of the main branches. The code review is the process of checking every change made to the code (called git diffs). People can then discuss if something is not clear, or not optimized (for the readability). It‘s hard at the beginning and it takes time but it will save way more time in the long run.

This quest for readableclean and maintainable code is never finished. I don’t think that even the most senior developer writes perfect code 24/7. But reviewing and letting your code being reviewed greatly helps at the beginning of your career.

So what’s next? What can be more difficult than writing good code?


Working efficiently with a team of developers can be THE challenge to face

Take one good developer, you can expect him to write clean and maintainable code. Take another good developer, same thing. Now take them on the same project working together. It is not obvious that you get a good team of developers.

How do you organize? How do you split the work? How do you not overlap? How do you avoid merge conflicts? How do you avoid people blocked by another?

Those are the questions you ask yourself when you start working with a team. I have seen the team growing (up to 5 developers) and those challenges had to be addressed fast. When 5 people are working on a project, you can’t afford to lose precious time. Say you loose 1.5 hours in a meeting that is not productive with your team and that’s a day of work gone. Here are some principles we started as a team to limit the friction and stay productive.

  • Divide the work up-front. During a sprint, one person will be more focus on one part of the application. It could be doing one component in the front, or implementing this API route. It’s not necessarily only front-end versus back-end but it needs to be limited to some files that other people will not touch a lot. This is best if it’s not always the same people doing the same thing. The advantages are: everyone can modify every part of the app (limiting the bus factor), better quality as every line is challenged by other developers, and people learn new and diverse things.
  • Conception (again). To make sure one feature is not modifying every other file. And to anticipate the impact of every modification.
  • Move fast. Everyone is encouraged to push his feature branch often and do small iterations. It limits the time one branch is living alone without rebasing on the common branch and thus limiting merge conflicts. Which also means reviewing code as soon as possible.
  • Fake it until you make it. For API calls, for instance, the person working on the front-end component doesn’t need real data to start working. If the API route return fake data with the correct format (cf the conception) nobody is blocked. Same with the data shared among components through the store in a React or Vue interface.

This is an ongoing process and we regularly challenge it to improve how we work together.

Working closely with a team is not easy and it can be more challenging than writing code alone. But it is also rewarding and can make a real impact on the startup execution.


What’s next?

There were some challenges I’ve been through during my time as a software engineer so far. I’d like to say it’s really exciting to be part of a product teamand to build something useful for our customers.

I’ll conclude by some of the topics I’m currently learning and that could be further tackled in a future article.

Developing a product from scratch is really different than having one in production. The latter includes among others:

  • Application monitoring and real time dashboards (we use Kibana and Grafana)
  • Understanding the environment where your app is running (containers with Docker on AWS for us)
  • Performance issues and cost optimization

Another aspect of being responsible for an application running in production is that you want the least interruption of service for the people relying on it. Which is tightly linked to automated tests, especially on critical part of your application.

Advertisements

अपनी तस्वीर को आँखों से लगाता क्या है: शहज़ाद अहमद

अपनी तस्वीर को आँखों से लगाता क्या है
इक नज़र मेरी तरफ़ भी तिरा जाता क्या है

मेरी रुस्वाई में वो भी हैं बराबर के शरीक
मेरे क़िस्से मिरे यारों को सुनाता क्या है

पास रह कर भी न पहचान सका तू मुझ को
दूर से देख के अब हाथ हिलाता क्या है

ज़ेहन के पर्दों पे मंज़िल के हयूले न बना
ग़ौर से देखता जा राह में आता क्या है

ज़ख़्म-ए-दिल जुर्म नहीं तोड़ भी दे मोहर-ए-सुकूत
जो तुझे जानते हैं उन से छुपाता क्या है

सफ़र-ए-शौक़ में क्यूँ काँपते हैं पाँव तिरे
आँख रखता है तो फिर आँख चुराता क्या है

उम्र भर अपने गरेबाँ से उलझने वाले
तू मुझे मेरे ही साए से डराता क्या है

चाँदनी देख के चेहरे को छुपाने वाले
धूप में बैठ के अब बाल सुखाता क्या है

मर गए प्यास के मारे तो उठा अब्र-ए-करम
बुझ गई बज़्म तो अब शम्अ जलाता क्या है

मैं तिरा कुछ भी नहीं हूँ मगर इतना तो बता
देख कर मुझ को तिरे ज़ेहन में आता क्या है

तेरा एहसास ज़रा सा तिरी हस्ती पायाब
तो समुंदर की तरह शोर मचाता क्या है

तुझ में कस-बल है तो दुनिया को बहा कर ले जा
चाय की प्याली में तूफ़ान उठाता क्या है

तेरी आवाज़ का जादू न चलेगा उन पर
जागने वालों को ‘शहज़ाद’ जगाता क्या है

हयूले : shadowy form
मोहर-ए-सुकूत : tight-lipped/ quietness
पायाब : shallow, fordable, within man’s depth

Time Is Your Most Valuable Resource: Dave Anderson

During interviews at Amazon, we allow five minutes for questions at the end. Some people ask about the team they’ll be working with, while others inquire about the technology they’ll be using.

Occasionally a candidate says, “I’ve heard Amazon can be a really hard place to work. Some people thrive and some people fail. Why is that, and how can I avoid joining the ranks of those who fail?”

This is a great question. I have heard a variation of this statement at Amazon dozens of times over the years:

I’m going to lose my mind! I have 14 direct reports and one critical project on fire, and my calendar is completely packed. The only way I can make any progress is by working after my team goes home. I’m not sure how much longer I can take it.

My usual answer to the interviewee is this:

Amazon has an infinite amount of work. The fire hose of work will never abate. No one will throttle your work for you. If you have a hard time saying no, or a hard time prioritizing your tasks, you are guaranteed to drown. You will work more and more hours until you eventually quit. On the other hand, if you aren’t terrible at your job, and you can pick the right things to work on and say no to everything else, you’ll love it here.

If you put this advice into practice, it will pay dividends for the rest of your life. You can replace “Amazon” with any modern company, a side business, or even your personal life. Your time is your most valuable resource. You can’t make more. You can’t pause it. You can only allocate it. Here’s how.

Identify your most important task

Early in my career at Amazon, I received approval to hire five additional engineers for an important project with a tight deadline. I opened the positions in Amazon’s internal system and talked to a few people about transferring. I also began writing up a project plan, creating the major stories to begin working on, and scheduling design review meetings with our engineers. I had a discussion with my manager a few weeks later, which went something like this:

Manager: How’s the hiring going? As you’re aware, you have a tight deadline.

Me: It’s a bit slow. I might have one position filled.

Manager: Are you treating this as your most important task?

Me: I’m spending as much time on it as I can, but I have a pretty full calendar. I have this critical project, my existing work, and a pretty big team. There’s a lot going on. I’ll try harder.

Manager: I assume you agree that you can’t finish the project without those five engineers. There will always be a lot going on. Trying harder is not a mechanism. If you’re not literally spending at least 50% of your time on this, you’re planning to fail. You need to spend at least four hours a day on hiring. Coffees with potential hires. Meetings with recruiting. Updating job descriptions. You can’t succeed without this. You can succeed without almost everything else.

My manager taught me a very valuable lesson that day. I was looking one level deep at the seemingly important things I had to do right then and there. But I needed to take a step back and assess whether I was allocating my time to take me to where I wanted to go. I was pedaling my bike as hard as I could, but I wasn’t looking at the street signs.

I internalized what my manager said. I recognized I was making progress in general, but not toward my most important destination. I was broadly focused on the bulk of my work, but I needed to focus narrowly on my most important work.

Realize that business as usual won’t work

A number of years ago, I was a very busy bee. I had multiple teams, with dozens of engineers and managers reporting to me. I had long-term project planning, architecture and design discussions, a couple of dozen one-on-one meetings a week, broad organizational meetings, operation review meetings, and more. My calendar was always booked with at least 40 hours of meetings a week, and I tended to spend at least another 10 to 20 hours at work per week. I was having fun, but I was also burning the candle at both ends.

I was then asked to run a massive cross-organizational planning process. I was told very clearly that this would be my top priority for the next three months. During that time, I would be expected to spend at least 20 hours per week on this planning process. The process would help determine what our organization would focus on for the next year, so it had leverage over hundreds of engineers. As is always true at Amazon, I wasn’t being taken off anything I already managed. I was just offered this important role, and expected to solve the problem.

Selectively pick a few things, and cut everything else. Work on only your most important things.

I was excited for the career opportunity, but I also had to fit another 20 hours into my 50- to 60-hour workweek.

I can still remember sitting in my office that evening with a beer (don’t judge me), staring at my completely full calendar. I started by looking for anything obvious to cut. I switched one weekly one-on-one to biweekly. Then I stared at my calendar some more. Finally I recognized that something drastic had to change. Business as usual was not going to cut it.

Cut to the bone and measure the pain

When trying to cut things out of our lives, we often ask the wrong questions. We ask whether something is important, or if we value it. It is far too easy to answer in the affirmative. Instead, we should ask these two questions:

  • “What is the worst case result if I cut this?”
  • “Is this going to get me where I want to go in the long run?”

Think of the pain you’ll experience if you cut this item/work/task/meeting. What is the worst result? Can you handle it? And, equally important, is this item/work/task/meeting related to your most important long-term goals?

That night I finished my beer and cut my schedule to the bone. I asked one of my managers to attend the weekly operations meeting, then dropped it. I asked one of my senior engineers to take charge of the architecture meeting series, then dropped it. I moved all junior employees to biweekly meetings. I moved a couple of direct employees to report to a manager. I dropped the weekly project status meeting. I dropped a couple of mentees—with apologies.

I was down to perhaps 15 hours of meetings a week. I was able to easily schedule the planning process into my calendar, and at the same time cut down my hours worked each week.

Examine results and aftermath

When I completed the planning process, my calendar was suddenly half-empty. This was very rare for those in positions like mine. I had certainly never experienced it.

First, I had completely removed some work. These meetings were useful, but not enough to justify their time on my or anyone else’s calendar. Free time back gives an infinite return on investment.

Second, I had delegated some high visibility and critical work to my managers and a few senior engineers. It was a wild success for both parties. I was delegating work I knew how to do. This wasn’t growth work; it was maintenance. I gave people growth opportunities, and they thrived. The new owners changed some processes and made improvements. They were challenged by the new opportunities, and it was exciting for all involved.

Challenging work is growth work, and by holding on to those leadership positions I had been depriving someone else of their own opportunity to grow. Delegating is a gift with two recipients. You get more time, and someone else gains valuable experience.

I expected temporary pain that I would remedy once the project was over. Instead, I had made a healthy cut, and most of the changes were permanent. I now had the time to re-evaluate what was important to me and my group in the long run, and I could schedule that work instead.

Make regular cuts

When you remove something from your schedule, you’re usually picking a single item from the bottom of your importance stack rank. You’re saying, “I need 30 minutes more per day, so I’ll drop this single 30-minute task.” It has limited return on investment, because you’re swapping one item for another.

Instead, make regular cuts to the bone with your schedule, your possessions, and the like. Instead of cutting from the bottom of your stack rank, switch your process. Selectively pick a few things, and cut everything else. Work on only your most important things.

Look at every single thing you’re doing. Determine whether you need each one to achieve your most important long-term goals. If not, ask yourself how much pain you’d feel if you cut it. Consider whether it makes sense to spend that time on your top priorities instead. Your top priorities are almost always the things that move the needle in your life, and time spent there is the most precious.


Climbing Corporate Ladder: Quora

“Congratulations on the promotion. Who is going to fill your old role?”

Within seconds of being promoted, my new manager was already putting me on the spot. I suggested several candidates, based on achievement and what I knew of their interest. Growing impatient, he fired off questions in rapid succession.

  • “Who are your top performers?”
  • “Who are the informal leaders on your team?”
  • “Who has shown interest?”
  • “Are we even ready to make this move?”

Until this moment, the focus was on proving myself. With his last question, I learned a lesson in succession planning. No company is going to promote someone if that move does more damage than good. Recognizing that I wasn’t prepared to answer, my new manager asked me to give it more thought and respond by the end of the week.

In most organizations, the process of deciding on who gets the next promotion is informal. Several managers discuss the potential candidates in a quick meeting and often make decisions on the spot. Eighty percent of the work is done before that position presents itself. If more than one qualified candidate exists, they might get an opportunity to interview, but one person typically has a considerable head start.

The first person I called was a mentor of mine. Don was our top sales rep and had 40 years of industry experience. He taught me the ropes as a young rep and was a steadying presence on our team when I was promoted to be his manager. When the topic of succession came up, I asked him what he thought about two people on my list. His reply took me by surprise.

“Well, I want to throw my name in the hat.”

I knew Don well, and this was the first time he had mentioned an interest in management. I was mistakenly under the impression he wanted to retire soon. After the shock wore off, I thought back to my executive’s questions and the type of person we wanted in this open role. Those questions became standard for every promotion decision I made in the future and the same questions you should ask yourself if you want to make it to the next level.

“Am I delivering results?”

The best predictor of future performance is past results. If you apply for a loan at a bank, they will check your credit history. When others lent you money, how did you perform? They do this for one reason. It is an accurate predictor of your willingness to make payments on the next loan.

Within an organization, you are interviewing for your next role every single day. If you have not delivered results in your current role, your manager would be reckless to offer you more responsibility. Companies look for candidates with a reliable track record of consistent performance who offer the best chance of generating a return on that position. If you can’t perform among the top 25% of your peers, you have no business asking for more responsibility.

Many people are not patient enough to earn the opportunity. According to a 2018 survey by the U.S. Department of Labor, Americans born in the early 1980s held an average of 7.8 jobs between the ages of 18 and 30. If you plan to move up in responsibility, staying with a company for 1.5 years on average won’t give you enough time to demonstrate your effectiveness.

In Don’s case, he was a model performer. He delivered results year in and year out, regularly finishing in the top 5% in every objective measurement. If the company introduced a new product or service, he was first to capitalize. If Don gave me a forecast, I accepted it as gospel. Don led the field in accountability and reliability.

“Do I demonstrate skills necessary at the next level?”

More responsibility in an organization often ties directly to more collaboration across the company. A startup’s top programmer can deliver sensational results in seclusion while the founder is in front of people all day long. Individual performers can often deliver results while working independently, but those same individuals struggle one level higher where communication becomes critical.

The skills needed to climb the ladder happen to be those most lacking in today’s economy, according to LinkedIn CEO Jeff Weiner. His company conducted a survey which found that the leading skill shortage in America is interpersonal communication. Leaders listen, network, partner, negotiate and persuade. They build coalitions within their business unit and across multiple functions.

Results will bring attention, but your behaviors are what managers are evaluating. If you want a promotion, start doing that job before you have the title. Be the person that your team comes to when your manager isn’t available. Volunteer to mentor and train new hires. Share your best practices. Put the team first, and soon they will see you as a natural successor to your manager.

Don checked this box and more. He taught me how to sell, and I sent every new hire to his office to learn as I did. He was vocal in all of our meetings, shared his strategies and routinely helped me strategize. Even though he reported to me, I leaned on him like an advisor or consultant. I could easily visualize Don leading the team seamlessly in my absence.

“Have I clearly communicated my intent to move up?”

A 2014 study by Accenture found that 44% of respondents had asked for a promotion and 68% who had done so received one. More than two in three of those asking for increased responsibility were rewarded for their direct approach, but an astonishing 56% had not bothered to ask.

Companies typically have a short window to make a promotion decision. Several leaders discuss the pros and cons of current options and give heavy weight to those who have expressed interest. Managers are not interested in promoting individuals that seem comfortable. First, they don’t want to upset a good thing if someone is performing well. Second, managers don’t want to push someone into a role they might not be interested in.

You never know when your boss will need to answer these questions. When that time comes, they will inevitably think of their most recent career conversations with you. If your peers are eagerly pushing for a promotion and you are quietly hoping for the best, expect to be disappointed.

Don almost lost his chance. He assumed that by doing all of the right things, he was the obvious choice. His unassuming approach was humble, but he came across as uninterested and content in his current role. Thankfully, I checked in with him before making a decision.

I called my new manager and told him that I had a candidate who was a clear answer to all of his questions. He listened and then asked me what I was waiting for. Don had an offer that afternoon. The next time your manager is asked this question, will you be the name that answers every query?

*This article originally published by Ian on Forbes on April 8th, 2019

Leading vs Winning: Dave Anderson

The beginning of your career at a tech company is focused on not drowning. You need to figure out how to do your job competently. Work to understand what is important and what can be ignored. Discover your way to impact your team and beyond.

Young overly happy tech employees from Pexels.com

Assuming you are successful getting past the filtering stages of your early career, you will also begin to understand what processes are behind career advancement. I’m not referring to career development, or ‘how do you improve yourself’. I’m referring to how you get promoted.

I’ve enjoyed coaching others on this, and beating myself up for the mistakes I’ve made on my path. Similar to interviewing, there are two main areas measured to determine if someone should be promoted.

  • Functional skills — Do you have the skills necessary to lead at a higher level?
  • Leadership — Do you lead as we’d expect from someone at a higher level.

People are often so focused on proving their functional competency that they shoot themselves in the foot when their leadership is assessed.


I had two engineers at the same level working on a project. Lets call them Sally and Fred. The more senior one (Sally) was getting close to promotion, and she and I were regularly discussing functional and leadership gaps for her future promotion. One day, Sally and Fred were presenting a design review for the leadership team. During our Q&A, it became obvious that Fred hadn’t considered the scaling impact on a couple of key decisions. In the meeting, Sally essentially said “Fred, I considered the scaling impact on my part of the design, I’m surprised you didn’t. I’ll help you later on it.

Quite a rude employee from Pexels.com

Later in our regular 1:1, Sally said she was disappointed in Fred’s performance. She said she was concerned that his designs weren’t high enough quality, missed requirements, and in general showed a lack of attention to detail.

My response is below, as best I remember it —

“Do you want to be the best <level> engineer in our group, or do you want to lead our group? I don’t need you to find failure from your teammates, I need you to make them successful. You pointed out Fred’s failures in public. This helped us avoid a single design mistake. You say you already knew Fred was not performing well. This isn’t about winning, this is about being a leader. Your best proof that you were a strong leader and needed to be promoted would have been for Fred to have presented his design successfully.”

If you’re focused on having better functional skills than your peers, you’re trying to prove that you’re the best of your existing peers. If you can instead make your organization, team and peers better, you’re being a leader. You’re showing that your attention isn’t on winning, your attention is on being successful. We don’t build our leadership teams with the most competent, we build them with those who will make those teams successful. A critical distinction so many people either forget, or don’t understand.

My general message is that next time you’re letting a peer fail, or feeling proud that your work looks better than your co-workers, consider instead how you might act if you were to help them look better. It might seem that your “higher” competence will be less obvious to your leadership in the short run, but it will reward you in the long run. Partially because it’s what everyone is looking for in a leader, and partially because it makes work much more enjoyable.

Answer the Unasked Questions: Dave Anderson

Imagine you’re writing a document, responding to an email, or writing a quick memo. You have a story you’d like to tell written out in your head: We should do X, Y costs this much, and we’re planning on doing Z.

How you tell that story is all about anticipating questions and answering them before they’re asked.

One of the clearest differences between junior and senior employees is how they approach communication. Often, a junior employee will lay out the details that feel important to them, answer the questions important to them,and propose actions they would like to take.

This effectively screams, “I’m inexperienced!”

A senior employee, writing the same communication, lays out the details important for their audience. They answer the audience’s inevitable questions. They propose actions that can be understood by their audience and explain why the audience would care. They go a step further by anticipating and answering the clarification questions their audience will inevitably ask.

The one tool that makes all the difference is empathy—the ability to understand others from their perspective. This includes the ability to understand what information they’re interested in, what their needs are, what their priorities are, what information they already have, and what knowledge they don’t have. Essentially, empathy puts you on the side of your audience: I understand you. I can feel your needs. This is about you, not me.


Ilove developing new leaders at Amazon. When mentoring others on this topic, I always propose a simple tool to use to know when they’re nailing or missing the mark: If you get follow-up questions to your communication, you’ve made an error.

At Amazon, leaders are encouraged to be self-critical. In this situation, if we get follow-up questions to an email, it means we should assume we’ve failed to provide a complete communication. Similarly, if we receive a question that could have been answered in a document, we consider the document flawed.

The perfect document, email, or memo should require no follow-ups, other than the ones intended. If it requires replies, this is an opportunity to learn and communicate more clearly in the future.

Of course, it’s possible some questions couldn’t be anticipated, you’ll receive unreasonable data requests, or your audience might not have read your whole communication. Still, I believe a strong leader will assume they’ve failed by default, and a junior leader will assume the other person failed.


Acommon form of communication at Amazon is the “we have a problem” email. Usually, it’s a junior manager’s email to their leadership team: “FYI, the XYZ service is currently experiencing an outage. We believe the impact is minimal and will send an update later.”

What this says is: Not only is there a disaster, but it’s not under control.

Let’s look at the obvious questions that will be sent back immediately: What is the impact of this outage? Full outage or partial? Do we know what caused the outage? How do we measure minimal? What does “later” mean for the next update? Who’s going to send the update?

When coaching leaders on improving their communication, their frequent knee-jerk response is, “But, I was too busy to write a full explanation.” My answer is that providing a tiny bit of context does not take a long time, and the inevitable flood of follow-up questions is a much larger distraction. Also, now you’ve lost credibility and you’ve failed to reassure your audience that you know what their concerns are and can handle them.

Here’s an example of a senior manager’s email to their leadership team on the same topic: “FYI, the XYZ service is currently experiencing a 50 percent outage, approximately. We do not know the cause yet. Customers impacted are those registering for a new account. We do not yet know the number of impacted customers, but we’re investigating. Customers who attempt to register have a 50 percent chance of receiving a ‘try again later’ message, and they can click retry to complete their registration. I will send an update within one hour with our current status and further updates on the above.”

What this email says is: There might be a problem, but someone’s in charge.

The above email didn’t take significantly longer to write and it anticipated the inevitable questions. To break it down further, “We don’t know the cause” is significantly better than not mentioning the obvious question at all, and the statement removes the necessity of your audience emailing you back. You’ve clarified the impact to customers. You’ve set a concrete deadline for follow up, so no one is left hanging. You’ve identified yourself as the person following up, so there is clear ownership over the communication. Basically, the manager here has answered pending questions and likely bought an hour to figure out what the heck happened.


When writing a document, there’s more time to think. But also, your audience will have higher expectations and have more time to come up with questions. This requires multiple levels of empathy.

Similar to the “Five Whys” when writing a document, continue to ask questions from your audience’s point of view until you feel you’ve exhausted all reasonable questions. For example, take this statement: “Younger children use applications less often than older children.” Keep clarifying, using the Five Whys as a guide:

  1. Children ages 2–6 use applications less often than children ages 7–12.
  2. Children ages 2–6 use applications 23 percent of time spent compared to 38 percent of children ages 7–12.
  3. New FAQ item referenced in a footnote: “Time spent on content types by age is XYZ.”
  4. New FAQ item referenced in a footnote: “Top content used by each age group is XYZ.”

It is often clear when you’re reading a document written by a senior employee versus a junior employee. After reading a senior employee’s document, you’re focused on the big questions the document presented to you; for example, should we approve the recommended option A or consider option B for our long-term strategy? When you’re reading a junior employee’s document, you’re likely to get tangled in follow-up questions, clarifications still needed, and missing data. I’ve been in dozens of meetings that needed to be rescheduled for a second hour due to a document that was not clear.


Learning the skill of empathy is one of the easiest ways to improve your communication. It’s about being clear and anticipating how other people think. Consider what your peers, junior team members, and leaders know, think, and need. Remove additional work from the desks of your peers and management because you empathize with their needs. Once you’ve demonstrated that you care for them, you will spend your valuable time on the important topics, and less time clarifying what you should have done properly the first time.

“Maybe part of our formal education should be training in empathy. Imagine how different the world would be if, in fact, that were reading, writing, arithmetic, empathy.”—Neil deGrasse Tyson

Technical Skills Are Overrated. Focus on Your Attitude: Dave Anderson

walked into the interview room, and an energetic young guy (we’ll call him Chen) ran up to me and shook my hand frantically with both of his. He was interviewing for a software engineering position.

“Hi, I’m Chen!” he said brightly. “I’m so happy to meet you!”

During his interview, Chen overwhelmed me with his enthusiasm. He was open to feedback, asked clarifying questions, and stayed extremely upbeat. Staying upbeat was impressive because he could surely tell he was doing a poor job solving my design problem.

During the final five minutes, when candidates can ask questions, Chen posed as many as he could fit in (I let the interview run over). He demonstrated a knowledge of Amazon’s business and history and explained how he would put in any energy necessary to be a successful part of the company.

When we did our debrief at the end of the interview, every interviewer had the same impression. Chen was below the bar on all technical measures (design, coding, algorithms). On the other hand, he was enthusiastic, energetic, self-critical about his technical gaps, and excited to hear constructive feedback, and he demonstrated a drive to improve himself.

In leading many hundreds of Amazon interviews as both a bar-raiser and a hiring manager, I’ve seen all types of candidates. I’ve also seen all the ways that candidates miss out on an opportunity to get hired.

When candidates prepare to interview at a company like Amazon (or Facebook, Google, Apple, etc.), they almost always focus on the functional aspects of the job. Software engineering candidates spend hours refreshing their knowledge of common coding questions. Designers build a beautiful portfolio of every UX they’ve worked on.

Soft skills don’t require the same type of preparation, but they’re just as essential to the interview process. Do you care about this being your career? Do you understand the company you’re thinking about joining? Are you able to demonstrate that you’ll be a great co-worker, not just a knowledgeable one?

Employees with soft skills provide leverage to a team. They don’t just contribute their work, but also improve their coworkers’ efforts.

I’ve seen dozens of people fail at Amazon, and 80 percent do so because of soft skill issues. They fail because they’re jerks. They fail because they don’t listen to their co-workers. They fail because they can’t take feedback. They fail because they don’t handle mistakes well.

In training new bar-raisers at Amazon, we emphasize that excellent leadership principles are at least as important as—if not more important than—functional skills. While failure or success at functional skill interview questions are easier to judge, we insist that the loops look very carefully at the soft skills as measured by our leadership principles.

A functional team is more valuable than an individual with functional skills. An amazingly skilled jerk does not add nearly as much value as a team member who encourages the team and helps drive them to do the right thing.

Functional skills can be taught. Coursework, books, and experience are great at filling in knowledge gaps. It’s significantly harder to teach a person not to be offended when someone says their code needs better documentation or their project plan doesn’t cover important milestones. I haven’t seen a ton of success in teaching people empathy.

Employees with soft skills provide leverage to a team. They don’t just contribute their work; they also improve their co-workers’ efforts. They inspire colleagues to stay on the team longer, which adds to institutional knowledge, improving productivity even more. These people are aware they can always learn more and are therefore open to new ideas. Soft skills are critical for growth, and in the long run, growth potential is more important than existing functional skills.

As I’ve written about before, there are ways to demonstrate soft skills in an interview. You can show that you’ll not only be a skilled worker, but that others will enjoy working with you. You can demonstrate that you’ll not only add your functional skills to the company, but also improve the productivity and happiness of those around you.

In our debrief for Chen, we agreed that he missed the technical bar across the board. On the other hand, we also agreed that we would love to work with him. We made him an offer. He has been at Amazon for years, has been promoted a couple of times, and has repeatedly demonstrated that enthusiasm and soft skills are powerful tools for long-term success.