Build a shared technical vision

Nicolas Dupont
Akeneo Labs
Published in
2 min readJan 25, 2016

At the end of 2014, we formed a very new core team, welcoming people with very different backgrounds, experiences and expectations about the architecture of our existing software, an open source Product Information Management system (PIM).

At this point, we strongly felt that we needed to build a common technical vision and a teammate Julien Janvier had a crazy idea, “let’s prepare individual talks about our ideal PIM”.

During a couple of weeks, we’ve seen really interesting presentations, everybody putting emphasis on something important for them : modular architecture, performances, standardization of import/export system, internal API to ease customization, decouple frontend and backend, etc.

From these talks, several explained ideas became totally obvious and deeply accepted by the whole team. Some of these ideas have already been implemented. Others ideas have generated a lot of interesting debates without reaching unanimity.

This exercise to build and share a technical vision has been a game changer. Once better aligned, the team naturally pulls the product in the same direction. Everything becomes simpler.

Moreover, it creates a collective product ownership, as well as easing communication and giving a deepest understanding of whatever feature we’re developing.

Retrospectively, we had some difficulty to sustain such a positive momentum, the team had grown a lot since then. What was obvious for “older” teammates became less and less understood by newcomers.

What’s wrong here?

Build a common understanding is not a one-shot exercise!

Three months after we hired a new teammate, we asked him what surprised him the most so far. He raised good and bad aspects, thus we learnt a lot from this exercise by benefiting from a fresh outlook on our work.

We should push this exercise further! By supporting each newcomer to prepare and explain to the whole team his own technical vision for the product.

We strongly believe that our product is a collective construction, it does not mean “an anarchic patchwork resulting from everybody is doing whatever they want when they want” but means “the best design that we can build together by gathering ideas, skills and expertise of all the teammates”.

Two heads are always better than one!

--

--