Junior Engineer Career Guide: Are You on the Wrong Team?

Do you have the manager and the right teammates at the right company?

Dan Fabulich
Code Red

--

Dan Fabulich is a Principal Engineer at Redfin. (We’re hiring!)

This is a guide for software engineers working in their first “real” job at a software company.

As a junior engineer, you still have a lot to learn. You’ll need to develop more technical skills, like debugging other people’s code, estimating how long a coding task will take, and detecting “code smells.” You’ll also need to develop people skills (“soft” skills), like how and when to ask for help (and when not to), how to summarize technical ideas, and how to give and receive feedback.

However, you also have an important decision to make: are you working with the right team?

Hopefully, you put some effort into researching this question during your job hunt, but since this is your first job, you may not yet know what you really value in a team, and you may not know what to expect and what not to expect on a “normal” software team.

This article is intended to give you some vague but plausible sounding advice for making that decision.

photo: Pat Loika

The perfect is the enemy of the good

If you’re fresh out of college, you may have recently heard a motivational commencement speaker advise you to find your one true passion, to follow your dream, and never to settle for second best. This is bad advice.

Asking if you’re “truly happy” can paradoxically reduce your happiness. In work as in personal relationships, you will not find a perfect team, and if you spend your life pursuing it, you may never be satisfied.

Think of the job you have now in the same way that you might think of your first friend in high school. Odds are, you’re not going to be best friends forever. But you’ll ruin it if you’re always looking over your shoulder for a better friend.

Your first job is probably not the purpose of your life. Instead of “true happiness at work,” try to enjoy the time you spend at work, and to learn about the job and yourself.

But misery at work is unacceptable

If you have a full-time job working 40+ hours every week, you spend more time working than anything else that you do.

On any given work day, you sleep six to eight hours, commute one or two hours, and work for eight to ten hours. That leaves at most six hours for knitting, break dancing, and caber tossing. If you share an office, you probably spend more waking hours there than you spend in your own home.

You’re probably going to spend more time sitting with your office neighbors than anyone else in your life, so picking a good team is really important. The person with the most direct influence on your satisfaction at work is probably your manager, so working with a good manager is really important.

(Many people think that we should change the world to fix this ubiquitous work/life imbalance, but that, too, will require a lot of time and work with a team you can trust.)

If you’re miserable at work, the majority of your waking hours will be spent in misery. You don’t have to put up with that. Even as a junior engineer, in 2017, your skills are in demand. You can find a better place to work.

Even as a junior engineer, in 2017, your skills are in demand. You can find a better place to work.

Are you working with the right teammates?

Research at Google shows that psychological safety is one of the most important common traits of successful teams.

[Psychological safety is] a group culture that the Harvard Business School professor Amy Edmondson defines as a ‘‘shared belief held by members of a team that the team is safe for interpersonal risk-taking.’’ Psychological safety is ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up,’’ Edmondson wrote in a study published in 1999. ‘‘It describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.’’

It can be really hard for teams to develop psychological safety together. You can’t just tell a random group of engineers, “Please mutually trust one another ASAP!” and expect results.

At Redfin, we regularly survey our employees. One of the questions we ask is, “Do you feel that you can be your true self at work?” We hope that our engineers “strongly agree” with that sentiment.

Optimizing for “being your true self” may strike you as a bit strange if our goal is psychological safety. Sometimes the pursuit of psychological safety (and professional decorum) can paradoxically require us to avoid being our true selves at work, to give other people the space to be psychologically safe. If you feel that your true self is a Disney villain—particularly Yzma, Gaston, Ursula, or Hades—you’ll probably need to restrain those impulses when you’re at work.

But psychological safety isn’t a fixed quantity that one person has to give up in order for someone else to have it. Teams can and should work together to develop mutual trust. (In a future article, I’ll talk about steps you can take to build trust and safety on your team; it’s outside the scope of this article.)

If you’re constantly afraid that your teammates will blame you for failure, if you’re afraid to speak up or ask questions for fear of embarrassment or retaliation, if it doesn’t seem like anybody on your team cares about you as a person, you might be on the wrong team.

Personal Caring

Kim Scott gives talks about an idea she calls “radical candor.” (The name sounds similar to Blanton’s “radical honesty” movement, but it’s a totally different thing.)

The core idea is that when you care about someone personally, and they know you care about them personally, you can challenge them directly to help them grow and help both of you achieve your shared goals. Scott calls that kind of direct feedback “radical candor.”

When you challenge someone directly without caring about them personally, that’s “obnoxious aggression.” (In the video, Scott calls it “being an asshole.”) People try not to listen to assholes when they make noises! We reject obnoxious, aggressive feedback out of hand, without taking it seriously. Nobody benefits from that kind of feedback.

On the other hand, if you care about someone personally without challenging them directly, Scott calls that “ruinous empathy.” You’re withholding feedback that the other person needs to hear, just to protect their feelings. (If you don’t challenge them directly and you don’t care about them personally, that’s “manipulative insincerity.”)

Personal caring is a prerequisite for communicating directly and effectively.

Do people on your team care about each other? Do you care about them? Do they care about you? If not, maybe you can build rapport to fix it, but you might just be on the wrong team.

Values Fit

As you get to know your teammates, work especially hard to figure out whether you share many of the same values. What are your moral beliefs? What are their moral beliefs? What’s the ultimate purpose of the work you’re doing together? What’s really important to you, and what’s not a big deal?

(To be abundantly clear, I’m talking here about people who share your values and not about people who share your background and upbringing. Diverse backgrounds are absolutely good on any team.)

Some values may be irrelevant to the work that you’re doing, but disagreements like these come up more often than you’d think. The Star Wars vs. Star Trek debate may not be relevant to your work, but the role of rugged individualism vs. teamwork will come up a lot. Do you believe in natural-born Jedi knights, or is sustained practice more important? How far are you willing to go to protect the personal privacy of your users/customers? How do you value invisible craftsmanship? Is it safe to put a thermal exhaust port right below the main port? How do you value learning for its own sake? Is it more important to ship faster or clean up more bugs?

Pay particular attention when people on your team ask, “What’s the big deal?” That question implies, “Your issue doesn’t really matter.” Disagreements about what matters are disagreements about values. “What’s the big deal?” is a really big deal.

“What’s the big deal?” is a really big deal.

Having some disagreement on values can help a team refine its consensus on what the team values as a whole, but if you disagree with your team about really fundamental values, it may not be possible to reconcile with them. Fundamental disagreements about values will lead to insoluble, interminable arguments, undermining your team’s effectiveness and psychological safety.

This question of values applies to your boss and your boss’s boss, all the way up to the CEO.

Your company has probably posted its official “company values” somewhere on its website. Does the executive team live by those values? Do those values match up well with the values of the people directly on your team? If not, you might be at the wrong company.

Do you have the right manager?

Your manager has a huge influence on the team and your career. Even if you have good rapport with your peers on your team, you also need to have a good working relationship with your manager.

Just like any other relationship, you’ll find that your personal style fits well with some managers and not others; even “great” managers aren’t great (or even good) for everybody. When you have a bad experience with your manager, avoid assuming that the manager is objectively Bad™. They might just be a bad fit for you, your team, or your company.

I recommend that junior engineers read books and articles on how to be a good manager, not necessarily because you want to be a manager yourself, but so that you can know what to expect of your manager. (Plus, maybe you’ll want to become a manager some day. Basic management training can help you decide whether that’s what you want in your career.)

When I first started in the software industry, I had only a vague idea of what to expect of my boss. Here are a few things I didn’t clearly understand.

  • Your manager should help you figure out your career goals. You probably don’t yet know what kind of work you like and what you dislike. Maybe you like working in React and hate working in SQL. Maybe you like working with Kafka, but you can only bear to work on front end code if you’re doing it in Swift. Your manager can assign you a variety of tasks to explore the landscape, show you some possible role models, and help you figure out why certain projects are easier for you than others.
  • Your manager should help you to achieve your career goals. Your manager should set clear guidelines establishing what you need to do to get a promotion, and make it straightforward for you to do that. For example, if you need to learn more deeply about how your site’s login code works, your manager should give you enough time to do that research. If you feel “blocked,” unable to progress for reasons outside your control, your manager should help to unblock you. (Sometimes there’s nothing your manager can do, but it is their job to try.)
  • Your manager should help you to stay happy and productive. There’s no way to measure the productivity of an engineer. Instead, we have to use our instincts to decide whether we’re being productive or not. Your manager can help you to train those instincts and to follow where they lead you. Your manager should be trying to improve your job satisfaction, arranging for you to work on projects that you prefer and where you feel productive. If you’re struggling to fit a trapezoidal peg into an oblong hole, your manager should try to set you on a better path.
  • Your manager should ensure that you’re not working too hard. If you’re working too hard, or if you’re switching between tasks too often, you’ll be much less productive. In the worst case, you might even burn out. Your manager should be trying to prevent that, and especially to prevent “crunch” time where you or anyone on your team has to work 60+ hours in a week. (I believe they call it “crunch” because that’s the sound your health makes when you work that hard over long periods of time.)
  • Your manager should help the team to establish mutual trust and psychological safety. Your manager gets to decide who’s on your team, and sets an example for how everyone should be treated. A tyrannical manager can destroy a team’s psychological safety. The manager’s role is to nurture your team, not to rule you.
  • Your manager should understand your team’s strategy and should help you understand it, too. Which is to say, your team should have a strategy, which your manager should have helped to establish. The strategy should fit in with larger company objectives, and your manager should know what those are. Your manager should understand your team’s charter and how it differs from the responsibilities of other teams. And, over time, you should know these things, too, with the help of your manager.
  • Your manager should meet one on one with you regularly. You should have a standing regular meeting at least every other week, if not more often. Within reason, your manager should make an effort to preserve that time, without skipping one just because they’re “busy.” Your one-on-one meeting is when you can tell your manager that you’re overworked or blocked. It’s also when you’ll talk about your career growth.

You’ll often find that folks within a team have very different views of how well their manager is doing. It’s normal for one person on a team to have a great fit with their manager, while someone else on the same team has a worse fit.

And don’t forget that your manager can’t do any of this stuff without your active participation. If you don’t tell your manager when you’re feeling unhappy, mistrusted, or unproductive, your manager can’t help you fix that. (This can create a vicious cycle where your manager makes things worse, so you mistrust your manager, so your manager makes things even worse.)

If you tell your manager that you’re blocked and they don’t do anything to fix it, if they ask you to improve in vague terms without concrete steps to take, if they assign you too many tasks and expect you to get them all done in an unreasonable timeframe, you might have the wrong manager.

If you’re on the wrong team, change teams

If you’re at a big company, you may be able to switch teams to another team that fits you better. (I generally recommend finishing out at least a year at your first job, but if you’re in an extremely bad circumstance, do what you need to do to take care of yourself.)

But if your company is too big, that may, itself, be the problem. You might prefer working at a smaller company with less communication overhead, or a larger one with better infrastructure.

Either way, get to know people outside your company, at meetups and conferences, to find out where people seem happy, and to learn the differences in values between various companies. (And don’t forget your friends from school. Where did they end up working?)

If you’re at the wrong company, find a new company to work for. I’m very happy to work at Redfin, but no company is a perfect fit for everybody.

I hope this guide can help you develop your career. In future articles, I’ll talk more about the technical skills and soft skills you’ll need to become a senior engineer.

Discuss on Hacker News
Discuss on Reddit

P.S. Redfin is hiring.

--

--