Contents

Should I Stay or Should I Go?

The inner clash

I read an article (or was it a podcast?) years ago from the perspective of a reporter that was often in war-time scenarios. The reporter did a lot of interviews over many years with refugees from those wars. The refugees that were most “successful” were those that seemed to have a sixth sense for when to stay in a particular location and when to move on.

Your career won’t ever have those sort of stakes, but it’s a skill to know when to stick it out on a team and when to move on.

Traction

It’s tough to know exactly when to jump ship, but it happens most often when I feel I’m unable to contribute major ideas back to the team. This has manifested in multiple ways for myself.

  1. No buy-in for your ideas.

    Sometimes it may be your own inability to form a convincing argument. I still struggle with this all the time. Self-awareness is crucial here - was your argument the problem, or did it fall on deaf ears? A peer to someone you’re presenting to is a great way to check if you’re off base. If a peer is out of reach, consider a trusted peer of the person you’re presenting to. Imagine you’re trying to convince your manager your new service will fill a big hole for customers. There may be no one to run the doc or presentation past. Does your manager work closely with a PM? What about a business analyst? Do they feel more approachable? That’s a great person to ask. It’s also possible that your argument is totally sound, but the business isn’t interested in what you have to say. For me, that’s a clear time to move on.

  2. Wrong part of the phoenix cycle.

    “What’s the phoenix cycle?” Build-Improve-Maintain then the whole team turns over and everyone is confused about everything that came before. You may have joined a team during the wrong part of it’s lifecycle; it may not match your career ambitions. It happens. Try to give the team at least a few months before deciding if there really isn’t any interesting work. The cycle will often tick ahead while you’re busy working on things. It may be that leadership does want to fund your projects, but it doesn’t make sense at that time.

  3. Exhaustion.

    This doesn’t have to be burn out. Sometimes you can accomplish all of your goals and be content. When asked “What’s next?” you may not have an answer. No shame - might be time to move on. This is similar to the next point.

  4. No personal growth.

    Maybe you aren’t getting the sort of growth you think you need. That’s worth a lot of conversations with your current manager, but if you still aren’t getting what you think you need, it’s time to move.

What do I want?

I have no idea what you may want, but I do suggest you create a list of things you’re looking for, or at least things you aren’t looking for.

Here’s my list:

  1. Team needs to have code that runs reasonably close to a paying customer. Can’t be so far removed that we’ll never get a customer ticket. Generally the closer to the customer the better.
    • This motivates me. Customer connections are important for me to care about my work.
  2. The services need to directly make money. There needs to be a billing model - pay per request, subscription, enterprise contract, whatever. The point is the specific service needs to actually charge dollars.
    • This makes it much easier to ask for a bigger team, new initiatives, etc.
  3. The service should be critical.
    • In Amazon parlance this is considered “tier 1”. I want to work on things that force a high engineering bar; I think it attracts folks I can learn from.

Finding the next thing

I’ve found two effective ways to find a new team or company: trusted peers (and some times that’s a gamble because it can be tough to give critical feedback to friends), or putting on your 1337 hackermans hat and using all of the data you can find to pick your next team.

The peer approach is pretty simple: “Hey friend, do you like your team? Oh cool, can I work with you?”

The other approach, not so much. Think of every resource available to you:

  • Company job boards
  • Aggregate yearly reviews
  • Repo stats
  • Docs - roadmaps, planning
  • Public presentations
  • Operational queues
  • Dashboards

Internal job boards (or even external ones!) may not deduplicate job listings. Some quick scripting skills can yield total positions open for a given hiring manager, showing relative demand on that team. A high ratio of open:total job listings for a particular manager makes me nervous. It could indicate growth, or it could mean high turnover. Find a way to dig deeper - check the commit histories for the repositories for the team to see if there’s a lot of names that are no longer on the team but recently active. If you can’t view the repos, what else can you check? Consider finding folks that worked with the hiring manager on LinkedIn and seeing if they have recently changed teams.

Repo stats can also help in their own way. You may be able to identify a particularly productive engineer on that team. Buy them a coffee and figure out what they work on, if they like it, what the challenges are, and so on. They’re not as strong a reference as a known peer, but I like to assume folks are all trying their best. If they’re a strong contributor they probably have good insight.

The internal docs are all self-explanatory. Use em! Cross-reference this whenever possible with the job boards and repo info and you’ll see a broader picture of how healthy a team is.

This is the sleauthy, passive approach. Unless you’re buying that engineer a coffee, you aren’t getting any human feedback here. That leaves no room for manipulation, but it also leaves no room for explanation. I do my due dilligence, but if I’m serious about a team I also make sure to give them a fair chance to explain whatever they’re working on and the challenges they have. I have yet to have someone lie about the challenges they were facing. I use the data as an early filter, but that’s where it ends.