A note on AI: AI was only used for spelling and grammar after I had written a couple of drafts.

After 5 years at Zendesk, a large company by engineering headcount, I have learned what works and does not work for me as an engineer and teammate.

Having recently joined a new company and engineering team—and therefore a new culture—I have been thinking more about how I work and interact with the “world” around me.

This post will outline two facets of me as a teammate: how I onboard as a new engineer and, as an established member of a team, what I like and dislike when onboarding new teammates. It will also touch on what I look for at the company and engineering-team levels.

When I join

Every time I join a new team, my goals are to ship a PR within my first week, have one-on-ones with any teammate I know I will be working closely with, and be the best little helper overall. I don’t want to make waves. I will hold my opinions loosely because I respect the work that has been done so far, and I respect the people that did it. I don’t have any context about why things were done a specific way, so it would be presumptuous to pretend that I know better.

When onboarding, I pay attention to a lot of things to get an idea of where a team is at, where an engineering organization is at, and where the company is at. Little things show that a company has it sh*t together:

  • you get your laptop before your start date, and can get everything you need installed without much help
  • you have an onboarding guide ready, so that your first couple of weeks have a clear scope
  • you can run the tech stack locally, and get started on small tasks quickly

It might not seem like much, but it is important to get a good feeling when starting.

My goal in my first week is to start a task without using coding agents so I can absorb as much knowledge as possible.

If you are my onboarding buddy, I will be happy to sync up with you on a daily basis, but I won’t be asking a lot of questions. It is part of my process to struggle and figure out solutions to my problems on my own. Of course, if I am really stuck, I will ask for help. I am not ignoring you; I just like to do it on my own. Pairing is also not something that helps me a lot when starting. I might pair to deploy something to make sure I understand the process but do not expect me to want to code or work through tickets in a pairing session.

Finally, if I am thrown on a project quickly, expect a lot of “I don’t know, but I will figure it out” for the first few weeks, even months. I ramp up quickly, but quality matters over quantity for me. I still care about what is produced and have a lot of pride attached to it, so I won’t give you bogus deadlines or talk a big game. I need to break things down for myself, so I may not be especially eloquent when first explaining a solution.

When you join

Based on your experience and how we will be working together, I will take a different approach. If you are very senior, we will mostly have context-sharing and architecture-level conversations. I will check with you on a daily basis, but after a week, we will most likely sync ad hoc.

If you are more on the junior side, I will expect you to ask a lot of questions, but struggling with a piece of code or a new system is extremely valuable and expected. The goals are long-term growth and the ability to navigate the system independently. I will check on you, but you have to be proactive. It’s important for me to see someone taking matters into their own hands and not just waiting on me or the team to give them something to do.

Some things I would consider green flags for a junior:

  • attempting to set up the local env without being pushed to do it
  • coming with a list of questions at once instead of starting a new chat every time something pops up
  • coming with a problem, along with a couple of solutions or approaches they have tried

My communication style is a bit of a mix between French culture and US work culture. As I build trust with someone, my feedback becomes more direct, and I don’t really adopt the “shit sandwich” approach. That may come across as blunt, but the constructive feedback I give is meant to help you and your career. What it also means is that when I bring up the positive, I really mean it; I am not just saying it to cover some negative feedback. I also expect direct communication and want you to tell me what doesn’t work or could be better in our collaboration. The earlier, the better. Trust is extremely important to me.

What I look for in a team

Trust and low egos. I think those two are critical to being able to work together toward a shared vision and successfully work through new technical challenges. This lets us feel comfortable saying “I don’t know” without feeling judged. It also helps us understand each other’s strengths and weaknesses. We can then decide together when it makes sense to spend longer on a problem so someone can grow their skills, and when deadlines or project goals make that impractical. Trust and low egos help people communicate clearly and positively. There is no hidden agenda.

Conclusion

This is my personal operating manual. It has evolved a lot over the years, and I expect it to keep evolving, especially with AI becoming part of our daily workflows and reshaping the whole industry in many ways. What I can tell you is that working with me will be about trust, honesty, caring about the craft, and being open about what I don’t know and the mistakes I’ve made.