A Few School Lessons You Should Cheerfully Forget
A Few School Lessons You Should Cheerfully Forget
School teaches some good lessons, and some bad. Here I walk through a few lessons you should unlearn.
Most of us spend around 17 years in school before we move into our career. School can teach us some valuable skills, but there are aspects of school which we need to unlearn as we progress in our careers.
Amazon hires thousands of college hires each year, and some small percentage of them each year ended up on my teams. I would see the below behaviors consistently applied, particularly from the better students. These are behaviors that schools encourage or reward, which will hurt you in your career.
I wanted to walk through some assumptions from school, and why you need to change your behaviors in the workplace.
Put in the effort to get A's on everything.
In school, you're rewarded for putting in excessive effort into every task. The school grading system encourages high achievers to ensure that every bit of their work is excellent.
Once these high achievers start working, the first thing they need to learn is that the speed and efficiency of accomplishing tasks is often more valuable than perfect quality.
I could imagine schools could imitate this by saying, “Turn in your paper this Friday, and you'll get a 20 point bonus. Turn in your paper next Monday, and you get a 10 point bonus. The paper is due next Wednesday.” Schools don't tend to do that.
When you have ten questions to answer, some employees will fire off ten quick emails, and move onto their next task. Other employees will agonize over their exact wording, phrasing, formatting, and they'll finish those emails 30 minutes later.
Your first job is to learn the difference between the work you need to get an “A” on (an important presentation to your VP), and the work which needs to be good enough (a minor question over email about a project you're working on).
This also applies to technical work. The engineer who hacks up a quick script in 30 minutes to solve a problem tends to be more valuable to the company than the engineer who spends 5 days writing a beautiful, extensible solution. Sometimes beautiful, extensible solutions are the right answer, but not always.
Companies value delivering results.
Someone will tell you how to determine scores on assignments and classes
In school, they often provide rubrics to explain how the teachers will determine your score on an assignment. 10% will be your grammar, 40% will be the content, 30% on the organization of the assignment, etc.
Your grades work the same way. 20% of your grade will be assignments, 40% will be tests, and so on.
One of the hardest things to learn in the office is that there is massive ambiguity on what exactly needs to get done, and how that result will be measured.
"Please give me a regular status update."
Do they want a document? A spreadsheet? An email? How often? Weekly? Monthly? Do they want a meeting? How soon do they need it?
What's tricky is that people aren't vague on purpose, they just don't know the answer themselves. They're relaying their need, and they want you to solve it.
You'll be evaluated based on how well you anticipate their needs, timeline, requirements, and level of quality. Over time, you'll get better at guessing people's needs.
It's as if in school, your teacher said, “Please write something relevant to this topic, and turn it in some time.” But you could lose points if you didn't write long enough, detailed enough, on the right topic, or turned it in too late.
There's a reason that work operates this way. As a leader, I recognize a problem. One of my teams is working on an important project, and I'm nervous that I don't see enough updates.
I could spend time coming up with a specific solution, and give it to the manager in charge. That has two major issues. 1) I just spent a bunch of time working on this that I could spend on something else. 2) I just took away agency from my manager, who might have a better solution for keeping me updated.
A better solution is to say, “Hey manager, I don't have enough regular info on this project, and it's making me nervous. Solve that please.” A good manager will solve it.
Similarly, a product manager might not have the technical skills necessary to specifically explain a solution, but they know there's a gap to be filled. “Customers need a faster experience on this website. Can you make it faster?”
How much faster? In what way should you make it faster? How do you measure speed? This product manager doesn't know, they just know that the website feels slow. If they tried to dictate how to measure speed, or dictate a solution, they'd be doing the engineer's job. Instead, they're relaying a need, and it's the employee's job to figure out how best to fill it.
Experienced employees learn that ambiguity in the workplace signals valuable autonomy, and that success comes from being able to navigate that ambiguity successfully.