Involving Engineering Early is Hard

It seems sensible to say that not involving engineers early on in the project discovery process is risky. And at the very least it’s demoralising for the engineers.

The primary advantage of getting engineers involved at the start is seen as lowering risk by allowing them to advise on feasibility, make early decisions about the technical architecture for the project, look for edge cases, ask interesting questions and so on.

But how far away are we really from the behaviour of the waterfall-based past?

With  some projects (particularly involving third party systems, or in micro-service architectures), engineers might not know enough about the technologies involved in a new project to give much advice until they start the work. And by then at least the first design iteration has probably completed.

Not only that, but in most businesses of any size, perhaps three or more months before anyone needs to code anything, it’s too hard to know which engineers will be doing the work.

And when a new project is being started by UX and product, engineering is typically finishing off, refactoring or bug fixing the previous one.

So it’s common for designers to meet with some resistance to the idea of including a bunch of devs on a week’s design sprint. Or even just a few hours sketching. Those engineers have real work to do right now!

My usual compromise is to tell senior engineers what’s going on and giving them the option of attending the activities I’m planning. My experience is that most will attend a couple of meetings (or nominate somebody who can) at the start, but then fade out until we need to build things. Whether they communicate what they’ve learned to the people who eventually do the work is something I tend not to get involved with.

Experiment through it

One way out of this is to look at handling the problem in the project process.

Lean experimentation, for example, says that you should thinly slice your projects in terms of learning about your problems. I like this approach because it doesn’t matter to begin with how little you know about the technical feasibility of something, or whether you’re missing an important issue, as long as you’re continually learning by experimentation (preferably daily, in code or not as the case may be) about as much as you can, and willing to change course once you detect a problem. This of course implies that the idea you start out with may be completely different from the one you end up with – but that’s good. Changing your mind proves you’re thinking.

So while it seems like the benefits of involving engineers early are in fact largely illusory, that needn’t be a problem. Instead, apply your energies to learning about what you want to do: the market, the demand, the customer, the ideas you have (Do your ideas makes sense? How do you know? Keep asking!), and your design solutions. With luck you won’t end up where you started out. And when engineering arrives you’ll have ideas that may not be about to radically change under the weight of further experimentation. You won’t be wasting their time.