Mapping the immovable objects in engineering projects

It can be frustrating when a project is moving too slowly, especially when it’s for reasons you can’t control.

Maybe every step forward is mired in the ball of mud your teams created before they discovered deliberate architecture. Maybe your project is in dire need of a program manager or a technical writer, but there isn’t going to be one available any time soon. Or, maybe the road ahead would be clear if it wasn’t for that one person who won’t commit to a direction, who seems to be withholding information, or who just seems to hate their job (or you?) and won’t let you schedule a meeting with them.

Whatever the problem is, it’s an immovable object on the path to the thing you want to get to. Everything would be so much easier if it wasn’t in the way, but here we are. What now?

There be dragons

I used to work with a lead who would come from a meeting with our director and announce sadly that the path ahead was blocked and we would have to change course. We spent months reacting and reorienting before our team realized that the lead was treating every offhand comment from the director as an unarguable hard fact. Once we encouraged him to bring some of the on-the-ground context and to push back a little, the director’s point of view changed to be much more in line with ours. It turned out that the obstacles were quite movable: we just needed to push on them.

Be clear about whether pronouncements from more-senior people are intended as suggestions or marching orders. When your local authority figure describes a path forward, they may be advocating for it, or they might just be enjoying the thought exercise of solving the problem because they miss doing the kind of work you do. Either way, make sure that they’re aware of the tradeoffs of any direction they propose.

Glen Mailer, a software engineer at CircleCI, says that when someone asks him, ‘Will it be ready by X date?’ he always says, ‘What would change if I say no?’. Any time you’re hemmed in by an inconvenient fact, it’s worth asking some questions about it. If you’re friendly and curious, you’ll often get a lot more context than you would if you just objected, and the path past the blocker may become clear. Your coworker is also more likely to feel invested enough to help you find a solution.

Does anyone have a crowbar?

Seemingly immovable blockers can sometimes be budged by approaching them from an unconventional angle. Busy teams might prioritize your request if you share some of the work or take something off their plate. A team maintaining a hostile, convoluted API may be willing to give you early access to the sleeker service they’re still developing if you promise not to overload it. It’s worth a few conversations to find out. 

The written word is one of the strongest forces we have against immovable objects. I don’t just mean making a persuasive argument – though that can work too – I mean just writing down what’s going on. There’s tremendous clarity that comes from multiple people looking at the same document with the same context and the same big picture: what problem you’re trying to solve, which requirements are critical and which are just nice to have, what’s happened so far, what paths you believe are blocked. When someone sees their name listed as the only stakeholder for a feature, they might re-evaluate their need. ‘Oh, you meant that system? Sure, we’re fine with not implementing support for it. We’re going to turn it off next year anyway.’

Requirements from other departments can also shift once you’ve added more context about what’s difficult and what’s not. For those outside engineering, it’s not always obvious which things are a trivial call to an API and which are eighteen months of integration hell. The legal department may be willing to change the nuances of a policy that’s difficult to implement. A product manager might be quite happy to leave out a feature or to downgrade ‘real-time’ to ‘near real-time’ once they understand the magnitude of what they’re asking for.

It’s not good or bad, it just is

But sometimes the immovable object really is immovable, or at least it would take more horsepower to move it than you’re able to find. There’s a giant boulder in your path, but the project has to continue anyway. It’s easy to get mad about that. It can be tempting to think of the difficult situation or ridiculous person as an unreasonable thing that’s standing between us and the problem we’re trying to solve. But often these constraints are fundamental to the project. Maybe they’re the reason there needs to be a project at all.

I think of it like the later levels of a video game, where the game keeps getting harder. We don’t get angry with the game for ratcheting up the difficulty and putting more obstacles in our path: we expect it, and it’s more of a triumph when we beat the level. If you’re a staff-plus engineer or a senior manager, sure, maybe you could go find a project where you’re not constrained by budget, time, existing technology, disagreeable humans, or other difficulties – but then are you sure that project needs one of you?

The reason the job is hard (and often the reason it’s interesting) is because of the immovable objects in the terrain. You’re not playing the level ‘completing the project’, you’re playing ‘completing the project when two directors have announced different goals for it and the only person who knows the core code just quit’. It’s a different level. It’s going to need different skills.

A persistent gap between expectations – even very reasonable expectations – and stubborn, immovable reality just causes anger and frustration, so it’s worth setting your expectations appropriately when going into a new project. If you accept the constraints as part of the game you’re playing, you’re less likely to spend your days being mad at things you can’t control.

That said…

Making peace isn’t always the right choice. Not all levels are winnable and not all project situations are acceptable. Maybe you’re dealing with someone whose toxicity will linger with you long after the project is over, or you were sold a vision of the project that has turned out to be a lie. Maybe your attempts to rescue a doomed project would just be wasting a quarter that could be put to better use. Beware of being a ‘boiling frog’, continuing to struggle on through something that you can’t possibly succeed at, or believing one too many promises about the thing becoming better in the future.

In particular, if you find yourself thinking, ‘I guess I’ll tough it out and just be a hero one more time’, you may be playing a game that’s not good for you. Checkpoint it at intervals, be clear about whether you’re making progress or just burning yourself out, and don’t stay in a situation that’s hurting you. A mentor or career buddy can be a useful sounding board if you’re in so deep that you can no longer be objective about the project.

In conclusion

Whether you’re a theist or not, there’s a lot to be learned from the Serenity prayer. There’s wisdom in accepting what you can’t change, changing what you can, and running like hell when you realize the description of the project was a lie. Okay, the prayer goes a little differently, but do understand what’s changeable and what’s not, and make sure your mental map of the project includes all of the boulders in the terrain. If you can treat the immovable objects not as barriers but as part of the puzzle you’re trying to solve, you’ll have a more enjoyable time and a smoother journey.

Thanks to Sam Schaevitz and Kristina Bennett.