Welcome to FictionalSoft! I hope your first week is going well? Great.

As you start to find your feet, I want to make sure we have a shared understanding of what success looks like here. Apologies in advance if I’m telling you something you already know, but it’s important to be explicit about this early.

You were hired to write code. Many developers make the mistake and think that their job stops there. That’s not true. In fact, you have two jobs:

  1. Write good code.
  2. Be easy to work with.

The first part tends to be the easy part. Coding can be challenging at times, but you’ve made it this far in your career so clearly you know this bit. The bit that many engineers struggle with is the second part, but it’s that second bit that tends to be most critical to success. Solving technical problems, or learning new tech – that’s is easy with support. People who are great to work with get that support. But people who are difficult to work with struggle. At best their careers stagnate; at worst they get fired.

Being easy to work with doesn’t mean being a sycophant or a pushover. It doesn’t mean not having and expressing strong opinions. In fact, some of the people I find easiest to work with are people who consistently disagree with me! “Easy to work with” means that you act professionally at all times. You disagree respectfully. You seek to understand before looking to be understood. You communicate clearly. You value your commitments.

Mostly, it means that you understand the value of relationships, and build them as carefully and intentionally as you build frameworks and libraries. Strong relationships with your colleagues will make you – and them – more effective. It’ll give you both common ground to build on when you don’t agree on something, and ensure that you can resolve conflict professionally.

One of the most effective engineers I worked with spent her first month here very intentionally taking every single one of her new co-workers out to coffee, listening carefully to what they did, what they struggled with, and what they hoped she’d do in her new role. That was a great investment for her and us: it meant that she could join any team and instantly be productive, because she had a relationship to build on. She quickly became a key “fixer”, someone we relied on help solve our hardest problems. Part of this was her technical skill, of course, but her relationship power played an even greater role in her success.

You don’t have to copy this specific tactic. Just like there are many ways to write good code, there are many ways to be an excellent co-worker. I expect you to be effective at both of your jobs, in whatever way that works best for you.

Most of the hardest problems we face have both technical and human components, and the best engineers know how to solve both.

I think you’ll do great – we wouldn’t have hired you otherwise! I’m here to support you, and help you be successful at both your jobs.

Any questions?