The Somebody Else’s Problem Field
By: Eugene Polonsky
Tags: Growth, Work, Management, Career Advice

Image by Karla Hernandez at unsplash.com

One of the common issues I find early-stage engineers facing is how to position themselves on a team in such a way as to be given work they’d enjoy doing. All too often folks feel stuck, feeling like code monkeys, just executing their manager’s vision.

So what do you do if the tasks your manager hands down to you aren’t interesting? What do you do when every day at work feels like a drag? You watch other engineers be given interesting, fun challenges and think “But what about me?”

A brief literary aside

If you haven’t already read Douglas Adams’ The Hitchhiker’s Guide to the Galaxy, go read it. Now. I’ll wait.

The book is chock full of fun, interesting asides that have nothing to do with the main story but that nevertheless can be supremely enlightening.

One of those is the Somebody Else’s Problem Field. As a refresher, Arthur (the main character), and Ford (his friendly alien companion) are stuck in London, trying desperately to get off planet, when Ford starts acting weird — hopping up and down on one foot, looking at something out of the corner of his eye. When Arthur asks Ford what he’s doing, Ford says “I think there’s a spaceship right there, cloaked with Somebody Else’s Problem Field. If you don’t stare at it directly, you might notice it.”

The Somebody Else’s Problem Field…

… is a field that covers an issue with a cloak of invisibility. It makes it so people ignore an issue even though it’s staring them right in the face.

Know any issues like that in your organization?

You know one of the key differentiators between a Junior and a Senior engineer? Seniors drive Somebody Else’s Problems. (Let’s call them SEPs for short.) Notice I didn’t say “Seniors fix SEPs.” That’s not scalable, especially since SEPs are often higher scope than a lone IC can fix. I really mean drive. So what does driving look like in this context? Let’s work through an example.

Example 1: The Meandering Onboarding

Image by Sebastian Herrmann at unsplash.com

It’s your first day at a new job. Your computer, your email account, and your password are all waiting at your new desk. (when does that ever happen?)

But then the problems start. Your account hasn’t been added to all the assets you need. The team Wiki is a mess. When you try to build the codebase, you hit one error after another.

<days of pain and misery later, involving asking multiple coworkers for info, banging your head against the monitor, praying…>

You have your first build two weeks later. Since you’re now feeling under pressure for not delivering sooner, and feeling somewhat stupid, you roll up your sleeves and start on your first assignment.

Outcome

Meh. Just a standard onboarding experience for most of us. The next hire’s going to have exactly the same experience. At least you got to Slack several key developers on the team.

Alternative outcome

Let’s say on day 2 you went to your manager and asked for permission to delay your onboarding by 1–2 weeks, so you could work on fixing up the documentation/script/config issues as you encounter them. Would your manager say no? Doubtful. You’re not the first team member to have gone through this pain, you’re just the first to offer to help.

So, now you’ve got a couple weeks’ leeway. What do you do with it? Well, engage key developers on the team. Validate with them that the issues you’re seeing are, in fact, legitimate, and not just you being dense. Enlist them to help you diagnose the root causes. Formulate a plan of attack, run it past your manager.

Analysis

Onboarding is the most obvious and most common example of an SEP, and, admittedly, one that can often be executed rather than driven. (It’s relatively small-scope, depending on team/etc.) But there are plenty of tasks that are higher-scoped than that, where you will need allies and contributors. Great! Those give you a chance to increase your scope at your own pace, and make friends and expand your network in the meanwhile.

Note that I’m not recommending you ignore your normal, daily tasks, in favor of chasing an SEP. That’s a sure way to earn the wrath of your manager. Instead, consider enlisting your manager in the SEP you find yourself passionate about. Ask her for help in the right approach to the problem. Ask if she’d mind if you spend 5%, 10% of your time on driving the issue forward. Assuming you’re not struggling in the day-to-day tasks, and assuming you can explain the business value of solving the SEP, it’s a poor manager who would object to you going after it.

I’m also not saying “Jump on every SEP you see.” As my friend Kurt so rightly says,

There is some risk in addressing a perceived SEP as a brand-new team member when one’s understanding of context for the problem is still evolving. Conversely, having the understanding of where co-workers are wasting cycles repeatedly on a task that isn’t a daily one but continues to be problematic and not acting is a party foul. — Kurt Heston

It’s a fine line to walk, and the key to walking it is passion: go after the SEPs you’re passionate about. There should be more than zero, but it won’t be every one you see.

Advantages

There are several advantages to this SEP way of thinking, aside from the obvious: in one stack rank meeting after another, I’ve seen folks who pick up and drive SEPs rise to the top of the stack. Why? Because they’re showing the key attributes every (good) organization wants: ownership, drive, initiative, dealing with ambiguity, communication.

Also, consider these:

You are entirely in control of the task you want to take on. Nobody will think less of you for not picking up an SEP — by its very definition, nobody expects you to. So you’re free to pick the SEP that arouses your interest. Go after the ones you’re passionate about. You’ll be more successful driving them, anyway. The failure scenario is much less likely. There are generally no timelines associated with SEPs. If there were, they wouldn’t be SEPs. So you can take as long as you want to resolve them. (Though, of course, the faster you do it, the better.) There is no real way to fail: if your drive peters out, well, the SEP is where it was before you picked it up: grudgingly ignored by everyone else. By picking up the SEP, you become the team’s recognized expert in that area. Driving the issue to resolution establishes you as the one who knows the most about it, even if you weren’t the one to do all the actual work of solving it! This then makes you the obvious choice the next time some task comes up in the same general area. So not only have you increased your scope, you’ve also repositioned your role more to your liking. Awesome, right?

So how do I find a nice, juicy SEP?

The problem is, just like in Arthur/Ford’s example, if you stare directly at an SEP it’s hard to see. In other words, if you sit down one day and say to yourself “All right, Biff, I’m going to find me an SEP to solve now,” chances are you’ll spend an hour staring at the monitor, coming up with nothing.

The trick to catching an SEP is being aware of what’s happening in your work life moment by moment. Did you just have to code around a turd in a feature area implementation? That’s an SEP. Write it down.

Did you just spend half an hour on a weird build issue on your local machine? SEP.

Did you just spend ten minutes searching through the wiki to find an answer you needed?

Did you just have to message your teammates for help with an environment issue that everyone knows about but nobody wants to tackle head-on?

SEP, SEP, SEP.

Write them down. Then, when you get into that 2 hours of carved-out time, look at this list. Pick one you’re most passionate about. And go at it!

Validating Assumptions

There are two assumptions behind everything I’m saying above.

Your organization is healthy and work culture is not toxic. Collaboration is encouraged, initiative is rewarded. Your manager is supportive, exemplifies the “got your back” attitude, and genuinely wants the best for you.

If either of these assumptions don’t apply to your work situation, I’d really recommend switching jobs. (If the second doesn’t apply, switch teams. If the first, switch companies.)

Seriously. People carry emotional scars from their toxic work environments for years. If you can manage to find something better, why wouldn’t you?

There you go, and necessary disclaimers

As usual, the views above are my own, and aren’t meant to represent Adobe or Microsoft. Feel free to hit me up on Twitter @partnerinflight, comment below, or shoot me an email at partnerinflight@gmail.com.

And if you like these posts, share them! Perhaps they’ll be helpful to somebody else, too.

Other entries in this series:

Like what you read? Want to read more? Here’s the complete list of articles so far (in suggested order of reading):