Selon un sondage récent de l’Ifop, 91 % des jeunes cadres français pensent que leur entreprise est en train ou va se transformer. Mais pour 47 % des entreprises, la transformation reste aujourd’hui synonyme de « digitalisation ». Elle ne concerne l’évolution du style de management que dans 21 % d’entre elles et la relation client dans seulement 20 %. Pourtant, ces cadres pensent que la priorité devrait être mise sur l’évolution des modes de rémunération des salariés (37 %), l’évolution des styles de management (33 %) et la formation et le développement de compétences (33 %).
Les jeunes cadres français ont bien compris que loin de se cantonner à la digitalisation des processus, la transformation concerne de nombreux aspects de la vie de l’entreprise, et surtout sa culture et son organisation. « Une entreprise ne peut réussir sa transformation digitale si elle n’a initié une profonde transformation en interne » explique Jean-Christophe Conticello, fondateur et CEO de Wemanity.
« L’apparition d’Internet et des technologies associées a bouleversé en profondeur le monde de l’entreprise. Les modes de consommation ont évolué, le temps s’est accéléré, ce qui a entrainé également une profonde évolution des modes de travail. La nécessité de changer est devenue vitale : on ne compte plus les entreprises qui, en hésitant à changer de recette, n’ont pas réussi à se renouveler et ont disparu : Kodak, Virgin Megastore, Nokia, BlackBerry, Yahoo!, etc. Non seulement, la nouvelle génération a compris cette nécessité de changement, mais elle le suscite avec les nouveaux modes de travail qu’elle privilégie. »
« Spark the Change » : décrypter et inspirer les bonnes pratiques 
Pour illustrer et expliquer cette évolution, l’événement « Spark the Change » a été créé à Londres en 2014 par Helen Walton et ses associés de Gamevy, avec le soutien de Wemanity, puis décliné en Australie, aux Pays-Bas, en Inde et au Canada. La première édition française sera organisée à Paris, le 26 juin prochain au Théâtre de la Madeleine.
Centré sur le futur du travail et les moyens de repenser l’entreprise de demain, « Spark the Change » propose aux entreprises françaises un programme de conférences de qualité, basé sur des retours d’expérience.
18 experts se succèderont sur scène pour décrypter les tenants et aboutissants de la transformation des entreprises. Parmi eux : Ludovic Huraux, CEO et fondateur de Shapr ; Dirk Ahlborn, CEO Hyperloop Technology ; Anthony Gooch Galvez, Directeur de la communication et des Affaires publiques à l’OCDE ; Anamita Guha, Product Manager, IBM Watson ; Marianne Syed, Executive Director chez Positive Planet UK. Et bien sûr, Arie Van Bennekum, seul rédacteur européen du Manifeste Agile, aujourd’hui Agile Thought Leader chez Wemanity et Jurgen Appelo, CEO et fondateur d’Agility Scales et expert du management 3.0.
3 thèmes principaux
Animées par des professionnels de toutes nationalités qui souhaitent faire évoluer le monde du travail, les conférences « Spark the Change » sont réparties dans trois sessions principales :
- Créer l’entreprise de demain : les différentes étapes pour insuffler un véritable changement dans l’entreprise, sur la base d’un apprentissage continuel, d’une maîtrise totale des technologies et d’une organisation plus agile et réactive.
Jurgen Appelo, CEO et fondateur d’Agility Scales, expliquera notamment dans quelle mesure il est essentiel pour une entreprise d’aider ses collaborateurs à maîtriser continuellement le changement, par exemple via la ludification et d’autres nouvelles pratiques. - Libérer les talents : développer le potentiel de chaque collaborateur, instaurer le bien-être au travail, booster la collaboration et créer un environnement de travail basé sur la confiance.
Anthony Gooch Galvez, Directeur de la communication et des Affaires publiques à l’OCDE, détaillera ainsi « l’Indicateur du vivre mieux » de l’OCDE qui permet de comprendre ce qui contribue au bien-être des individus et des pays, et d’identifier comment susciter plus de progrès pour tous. - « Sparking disruption » : privilégier l’innovation, voire la disruption ; remettre en cause le statu quo ; et valoriser le progrès social, technologique et culturel.
Dans cette session, Dirk Ahlborn, CEO Hyperloop Technology, dévoilera la genèse de la création d’Hyperloop qui, au-delà des records de vitesse et des nombreuses innovations qui le caractérisent, propose surtout de révolutionner l’expérience des usagers du train.
« Spark the Change a été créé pour inspirer les entreprises, à l’heure où elles sont confrontées à plusieurs évolutions stratégiques : la transformation numérique, l’évolution démographique, la co-innovation voire la “coopétition” sur des marchés mondialisés » explique Sabri Ben Radhia, Responsable de l’événement chez Wemanity. « Si Wemanity était présent lors des premières éditions internationales de Spark the Change en tant que sponsor, nous avons repris la marque et sommes devenus son organisateur principal. Réservé à la fois aux entreprises et aux institutions publiques, l’événement a pour objectif de couvrir l’ensemble des aspects relatifs à la transformation des entreprises, sur la base de très nombreux retours d’expérience. Il vise également à aider les entreprises à développer les compétences nécessaires pour mener à bien leur transformation ».
Le programme de la journée a été construit pour privilégier l’échange d’expériences et le networking. 750 personnes issues de l’ensemble de l’écosystème de l’innovation européen sont attendues le 26 juin prochain au Théâtre de la Madeleine.
Aurons-nous le plaisir de vous compter parmi eux ?
Plus d’information sur l’événement : http://sparkthechange.fr/about-us/
Les experts qui interviendront dans les conférences : http://sparkthechange.fr/speakers/
Inscription : http://sparkthechange.fr/tickets/
Also published on Medium.
Your Engineering Team Is Not an Island: Success Demands a Holistic View of the Business
I just re-read the awesome post from my friends David Loftesness and Raffi Krikorian, What Does A VP of Engineering Do Again? And while I agree with everything that they say, I think there is one crucial item missing, which has been present in every job I’ve had because all of them were user-facing internet services and a majority of my job has been working with product teams. Collaboration with stakeholders (especially with product) is key, but if you take it one step further, a VP of Engineering is actually measured by execution in a wider context across many teams or departments. You cannot look at engineering in isolation for your successes or failures.
But first a short story about my first months at SoundCloud. The CTO wanted more front-end work done because an important release was nearing. He asked me to hire more engineers to accomplish that goal. I started recruiting, but then I looked at why the velocity of the existing team was not meeting expectations. So, I went to all of the front-end teams (at that time it was Web, iPhone, and Android) and asked a very simple question “What slows you down the most in your day-to-day work?” To my surprise, everyone gave the same answer “We only have one designer.” They went on to say that although the designer was very good, she was completely overloaded so designs, changes, and simple clarifications took forever to get done.
Now that I knew design was actually the cause for delays, the solution to my problem was not to hire more engineers (which might have even made the problem worse with more work for the designer), but to start building a design team.
Engineering leads need to look at the whole product process (together with the responsible stakeholders) and not just at engineering in isolation. What I did was a very simple (but, in this case, effective) form of value stream mapping. Our self-improvement at SoundCloud continued. You can read Phil Calcado’s excellent post about the organizational aspects of microservices at SoundCloud.
The Best Engineering Leads Will Stop and Assess the Situation
Continually assessing situations in a holistic way isn’t just the job of an engineering lead — everybody involved should take responsibility. But, in my experience, the problem usually surfaces in engineering because when things are not moving fast enough (and when do they ever?) management’s first reaction can be to throw more engineers at the problem so more work will get done, but also (and this is the not so nice scenario), management thinks the engineers are not working hard enough. Other common responses from management include reorganizing the teams or adopting new methodologies. However, as an engineering leader, you are a lot like a doctor: you need to diagnose the illness before treating the symptoms.
Engineering leaders need to look at the whole value chain and to sit with the leaders from affected departments to review at the problem. The solution to a problem might not be to hire more people (which a lot of startups do), but to organize product development in a better way. And if you have to hire, it might mean that you have to move headcount around. When everyone has the same goal goal — delivering more business value — shifting headcount from engineering to design or to recruiting shouldn’t be an issue. Afterall, the goal is more business value, not having the biggest department. So, when I realized our problem at SoundCloud wasn’t going to be fixed by adding more engineers, we created a design team. But this was just the first step towards a better setup.
Even after creating a larger design team, it remained isolated from other departments and was not fully integrated with our workflows. The problems of turnaround and wasted resources were exacerbated by the increasing risk of misalignment between product, design, and engineering. Therefore, the next logical step was to improve the organization by creating a delivery team per product.
Shifting Organizational Structures to Deliver Business Value
A delivery team is a team that can deliver the vast majority (95%) of its backlog items to production without dependencies on other teams. Unlike more horizontally-oriented teams (for example, a front-end engineering team that relies on the back-end engineering team for any back-end changes), a delivery team has all the necessary skills inside their team. So, depending on your company and your product, these teams can look very different. In engineering teams that are infrastructure focused, these teams can consist of only engineers; but if you look at a team that delivers a consumer-facing web app, then the team looks more like this:
Creating these delivery teams and then making sure you have the right staffing for them should eliminate a staffing mismatch between the affected departments. Some team members (like support) might just be a pointperson for the team, e.g., the support person only attends the daily standup and reports what is going on.
So, don’t look at engineering in isolation when trying to solve delivery problems. It is critical that each engineering leader (and especially the VP of Engineering, who can really influence the organizational setup) ensures that the overall product development process is set up in a way that reduces waste and delivers value to the customer which is the whole point of product development in the first place!
This post includes material from the upcoming book “Scaling Teams” by myself and David Loftesness, which will be published by O’Reilly in 2016. In this book, we will explain in detail the various scaling challenges of software startups.
Thanks to Laurel Ruma and David Loftessness
By: Alexander Grosse from issuu
Save the date
Get ready to Spark, we’re happy to announce Spark the Change 2018 will be happening next June in Paris. We will announce speakers soon. We can’t wait to see you there!
Self selection – How to restructure your team for greater autonomy.
One of our largest departments within Ocado Technology recently undertook a revolutionary self-selecting restructuring exercise, changing the entire structure of the department whilst allowing all team members to choose which team they would like to work in going forward. The need came about because multiple teams were stretched, working across two major business propositions and context switching between them. The goal was that following the restructure there would be a clear split between teams working on two different business propositions, such that each of those teams could really focus on that product.
The overall aim of this restructure was to achieve greater alignment, autonomy and purpose.
Following the principle that a collaborative and distributed approach is often the best way to solve a complex optimisation problem, we decided to take a full day as a whole department to stop work and have a facilitated event to negotiate the moves amongst the five new teams. We did a lot of thinking and preparation prior to this day and the teams used a set of constraints around team size and experience levels to guide their decisions.
The plan going into the event was shared well ahead of time to allow people to get their questions in (and added to a shared FAQ forum) and to be sure the concepts were clear going into the day. Alongside this, we ran multiple “townhall” sessions where people could air their concerns and ask their questions openly. We hoped that at the end of the process we would have well-rounded, committed teams ready to face the new challenge.
There was a certain amount of ad-libbing and practical adjustments on the day, but on the whole it unfolded according to the plan:
– First, a pitch for each team by the Product Owner, covering the vision/roadmap and why the team is super cool and awesome. There was also a set of target criteria for each team as a guide for what we were looking to achieve in each area.
– Next, multiple iterations where we:
1. Assigned or moved ourselves/each other between teams until we’ve addressed any identified issues in the previous iteration.
2. See if we had met the pre-defined criteria for each team.
3. Repeat until we run out of time or we meet all of the requirements and everybody is happy and committed to the team that they are in.
Fuelled by 18 pizzas, we completed three exhausting rounds of moves and peer voting. At the end of each round, we (everyone, including Product Owners and Team Leads) voted on the viability of each team. From this we measured two scores: an intra-team score (the people in that team scoring the viability of the team), and an inter-team score (the rest of the people scoring the viability of that team). This lead to a few interesting dynamics, for example one of the teams gave themselves a high intra-team score, but scored low on the inter-team vote. They then gave a pitch justifying their viability as a team, and were able to dramatically increase their inter-team score in the next round.
The first round was deliberately obviously suboptimal, so that everyone was motivated to suggest changes and improvements and become comfortable with doing so in a very “safe” way. Naturally, this configuration had dramatically lower scores! This encouraged a large amount of movement in the following rounds, as we had hoped.
Essential to finding a viable solution was an appreciation from all of the ‘greater good’ of Ocado Technology. On the day, some people chose to make some really big compromises in order to serve the greater good and allow us to form balanced teams that are all capable of smashing out quality software.
After the final round of voting we then took a quick anonymous happiness reading by each dropping a green, yellow or red lego piece into a box. Although they were not perfect, we were extremely pleased the results, considering that our original goals was “at least 50% happy”.
The very next morning we did a big-bang desk move:
We’ve since kept a close eye on the impact of the shuffle-up by measuring the things that matter most to us: throughput and team happiness. There was an expected initial dip in throughput as many people got up to speed on new products they had not worked on before and as new teams gelled and got to know each other. But the throughput three months on has risen higher than before the change and still rising. Improvements in team happiness (measured before and after by Spotify’s “health-checks”) were noteworthy from straight after the restructure.
In terms of the solution itself: we are delighted. Every team has a reasonable level of experience whilst a healthy number of people have chosen to change domain. It is a vastly better result than we could have hoped for had we chosen a top-down approach and the sense of autonomy it has created is invaluable. It seems that teams and individuals have a stronger sense of ownership than ever before and that they are taking quality more seriously than ever before. This did have an up-front cost in terms of short term throughput, but the long term benefits certainly justify it.
James Lohr, Ocado Tech Department Head