In the beginning, one of the first things we agreed upon as a company were our values (literally representing what we value e.g. in people). Later, Design Principles were added (derived from our values) which represent more practical requirements for building our organisation. Both of these form the foundation on which Lightyear’s company structure would be built.
In the process, Lightyear kept growing, which has us continuously looking for the right trade-offs between hierarchy and individual empowerment, innovation and established solutions. Our values (which I will explore in my next column) and design principles help us not to lose focus on what we truly value. This sometimes requires mental juggling to come up with solutions that fit Lightyear’s ambitions, goals and size.
"At Lightyear, we’re applying the same process of holistic design that we are using to build Lightyear One, to our organisation".
Empowering people through structure
The origin of our company structure can be traced back to Solar Team Eindhoven (2013), where a group of students which included Lightyear’s founders, set out to build Stella. The students were experts in their own domains but had little collective experience in designing a car from scratch. Not only did they have to join their expertise and domains, they all had to be able to understand the bigger picture and prioritise the whole system (instead of their own subsystem). I truly believe that this is why they are unbeatable in the World Solar Challenge.
In a way, they adapted the Dutch ‘poldermodel’, a consensus-driven decision making process, to their own engineering needs by including a data based component to it. The main lesson that we took from this when designing our company structure, was to give people the tools to succeed by enabling closer collaboration. An example of that is working online/in the cloud in Google Drive and people having open agendas to each other. The result is a team that’s able to iterate quickly, uses relevant data and discussion in decision making, and is able to set the system as the number one priority. This does not only count on a product level, but also on the organisation as a whole.
Holacracy as a way to facilitate decision making
If you want to give our organisation structure a name, we get closest to the holacracy model, which is a decentralised way of setting up an organisation. It offers quite a few advantages especially in terms of flexibility, but most importantly, it offered a balance between central decision making and empowering local teams.
Our ambitions require us to set strategic goals (including also performance objectives for Lightyear One) top down. For execution, we use a bottom-up approach to empower the individual. As a result, the agreement found somewhere in the middle. This way we can keep ourselves up to speed in both decision making and execution.
The intrinsic flexibility within Lightyear means that as a whole the basic structure changes very little: instead it is built to handle repetitive updates when needed.
Lightyear’s Matrix Structure
In the design process of one of the most complex parts of the organisational structure we got help from Deloitte. Together with an engineering structure workgroup and by our Design Principles and Values we set up a structure that facilitates optimal synergy in the product creation process. This is reflected in Lightyear’s matrix structure.
The matrix structure follows the logical breakdown (Systems Engineering approach) of the Lightyear One by representing her different (sub-)systems. The systems are taken care of by both a systems architect (having responsibility over the technical architecture) and a project manager (keeping control on time, scope and money). This is represented by the vertical axis in the matrix.
The horizontal axis represents the different knowledge domains which need to be represented over the different systems. For example, when designing a battery, talented engineers with different focuses need to come together to develop it: electrical engineers to wire it, thermal engineers to cool it and embedded software engineers to programme it. The system architect is responsible for delivering the system according to the requirements and thus will request certain FTE’s, which forms an ‘agile’ system team.
The Domain experts are responsible for the representation of their domain throughout Lightyear and to make sure Lightyear’s technology stays ahead of the market. In order to have enough engineers from every domain in every system, the Domain experts collaborate with the ‘Groupleads’ who are responsible for the personal development, training and allocation of the engineers at Lightyear.
Learning to accept growth and the change that comes with it
While writing this I’m already thinking about new structures which will evolve while we keep on growing and developing as a company. I believe -just like Darwin used to tell us about species- embracing change is one of the aspects that makes companies able to survive. Therefore, we keep on adding incremental updates as soon as we see this is needed to stay up to speed.
Sometimes (actually quite often) that even involves ‘killing your darlings’, projects or part of your way of doing things that you hold dear but have to let go if you want to move on to the next phase. The tricky part here is that what helped you in a specific phase of growth often can become your bottleneck for your next phase. Recognising, acknowledging and seeing goodbye to these aspects will enable us to deal with future growth too.
As an example: When we were less than 15 people we all had full freedom in the tasks we executed. This worked really well for creativity, speed and ‘getting things done’. However, while growing, we noticed that giving ‘too much’ freedom can result in people getting lost. Therefore, while still having high levels of autonomy, we now define the (broad) lines which one is responsible for. While for me at first hand it felt like giving less freedom, the people evaluated this to give their freedom to operate and take responsibility. I personally think that the only way to build an organisation that's resilient to change and that's willing to engage in dialogue with its employees, is by empowering a strong culture.
I recently recorded a podcast with Dutch insurance company Achmea (in Dutch) about building the Lightyear organisation and my story so far. You can watch that on demand here.