FlowCon 2024: 3 great thematics for tech leaders

A few weeks ago, I assisted to FlowCon 2024, a conference centered around “flow” in software and tech industries. I finally found some time to think about what it brought to me and to write about it: through the “engineering leader” track, this 2-day conference and its speakers delivered valuable insights and welcomed reminders on modern best practices, including empowering engineering teams, productivity in tech, and culture.

Many speakers shared real-life experiences and several networking time slots allowed participants to go further than theoretical talks, which makes the experience much more valuable! Those conferences are always a good opportunity to take a step back from your day-to-day, get reminders about trends and best practices of the moment, and reflect on your own next steps.

Flowcon’s opening keynote with Sander Hoogendoorn: directly to the heart of the matter

To start this 2-day conference, I had the chance to discover Sander Hoogendoorn: if you are working in tech and don’t know about him already, stop reading this post and go to his website. Thank me later.

Over a bit less than 2 hours, Sander covered hot topics that resonated directly with my experiences in Tech: the innovator’s dilemma, technical debt (leading to “technical death” as he calls it), the importance of a culture empowering teams, experiments and accepting failures, need for clear goals and alignments, and finally feedback loops and iterations. Sander navigated quickly through those different topics, relating personal experiences with some quite interesting analyses to showcase how all those aspects, while hard to measure, directly impact productivity in tech.

This keynote felt too short: I felt like we only scratched the surface of impactful but hard-to-grasp topics, but Sander managed to introduce themes that would be further discussed during the rest of the conference.

Tech & Engineering are surrounded by complexity: it can’t be measured traditionally

KPIs, metrics, and OKRs are often a go-to of management meetings to ensure alignments within companies. There have been many tentative to provide relevant metrics for engineering and tech teams from lines of codes to DORA metrics. None of them have managed to become commonly accepted standards, and the community consensus tends toward accepting there is no easy measurable way to measure Tech & Engineering productivity per se. Tech leaders must therefore face the challenge of providing insights about their team’s efficiency through proxies, measuring more abstract yet critical aspects of their team’s work, and deriving actions and incentives to lead those teams to improve continously.

In the following, I will go through main themes that emerged from the different talks and that can help navigate the complexity of crafting software.

Empowering teams

Software crafting is complex. Anna Panagiotou discussed complexity and how it could be navigated: To navigate complexity is a journey, we often start with just a sense of direction, and continuous re-evaluation of where to go is needed to avoid failure and adapt our trajectory. This echoed a lot Karim Harbott‘s book The 6 Enablers of Business Agility: How to Thrive in an Uncertain World: top-down approaches to set directions often fail as leaders can’t fully capture all aspects of this complexity, and the further away the decision is from “the field”, the longer the iteration cycle and the more chances there are that the context changed faster than directions evolved.

Therefore, to navigate complexity, tech organizations should rely as much as possible on the teams. Tech leaders therefore must empower their teams to sail: Sander Hoogendoorn mentioned the need to simplify the rules to amplify autonomy; up to a point where his teams don’t have engineering managers per team, nor Product owners or QA. His teammates decide what they want to work on, what matters according to them, and how they want to work on it. Sander favors experiments, mob programming, open discussions and spontaneously forming groups based on who wants to contribute.

Technical freedom to the teams

Empowering engineering teams also calls for greater autonomy on technical stacks and architecture decisions.

Mathieu Corbin, Senior Staff SRE at Qonto gave a presentation about how developers are autonomous even on production environments. While production can be scary for some developers, they are actually the ones best suited to operate on it directly in many cases, as they know what it actually does. Long gone are (should be?) SRE teams that you have to go through systematically to run a small script on production, or to provision a database: SRE have often low added values in those tasks and are just button pushers. Worst, developers may have to wait for an SRE to be available, hence reducing velocity and breaking the flow.

Mathieu Corbin described how, at Qonto, his job is mostly to build a self-service platform that developer teams can consume and use to meet their needs. From provisioning a Kubernetes namespace to accessing a pod in production and rows of a database, everything can be done without SRE. This requires SRE teams to shift their focus from managing production to building a platform so that managing production becomes a commodity. When this is achieved, developers get a complete ownership over the application they build and also how it runs, which reduces lead time, increases ownership and facilitates troubleshooting, maintenance, on-call escalations and so on.

Ownership at team level

Fathi Bellahcene, principal architect at Veepee shared his experience of scaling the role of architect into a department of 650 tech-people, with 3500 deployments to production per month. Veepee’s main challenge here has been to keep velocity at scale: too many decisions relied on architects, slowing down the whole organization: “Indecision is the thief of opportunity”, he quoted. His role as an architect moved from making decisions to ensuring tech teams had the right environments to make decisions themselves. Through guidelines, focusing on objectives rather than enforcing tools and methods, clear delegation and responsibility levels, and oversharing vision and strategy, Veepee’s teams are autonomous in most decisions.

The main risk of delegating technical decisions is punctual mistakes: Fathi observed that the marginal error rate when increasing reflection time goes quickly to zero. Hence, tech leaders and their teams should embrace a Fail Fast approach: be prepared for failures, accept errors, be transparent, and make sure to learn from them. This last part resonated quite well with Jean-Philippe Denis‘ speech about Qonto Tech and product operating system in which he described how Qonto teams are continuously learning and perfecting the art of just-in-time delivery, failing fast and never failing twice for the same thing. Among the main takeaways from his talk, I particularly recall:

• Continuous post-mortems: whenever a failure or even a friction is identified, Qonto’s engineers ask themselves “How can we make sure this never happens anymore, anywhere in the company?”. They log it in a database accessible to the whole company and take the time to fix it.
• Visual management: This principle is at the core of the lean management principles, from Toyota in the 50s and they are still key. I like to remind my teams that 50% of the surface of the brain is devoted to processing visual information: to understand, manage and improve something, make it visual. If your AGILE board is messy, that’s probably a good place to start!
• Just-in-time delivery: Crafting software is complex and involves many specialized people: from product to developers, QAs and support teams. Keeping the flow going and the velocity high requires a great attention to idle time. Moving fast does not necessarily mean working faster, but smarter, and being there right when it is needed.

Productivity in Tech

“Measuring performance of development teams”. I feel like there is always a talk about this in any tech conferences. I think it shows how this is a common matter, and often complex issue for tech leaders. Clément Rochas and Anis Chaabani from Scaleway humbly described how they introduced performance measurements at Scaleway.

They directly started with SPACE metrics, but decided not to necessarily cover all dimensions to begin with. In fact, they searched for volunteers within teams to identify and adopt just a few of the SPACE dimensions, and start a bottom-up approach. This allowed them to get support from early-adopters within the impacted teams, and have allies to push for a change that is not always well perceived by all teams.

My main takeaway from this talk is that, quickly enough, they realized that no metrics are good by themselves, but that the added value was for teams and their leaders to observe the evolution and trends of those metrics, and discuss around them to build a interpretation of those metrics: the varying context from one team to another highly impacts the values of the metrics in complex environments, hence variations should be leveraged rather than the metrics themselves, and even then, the most valuable information comes from the interpretation of the variations by the teams themselves. Once again, ownership at team level comes out as a good way to navigate complex environments… Both speakers concluded that their next steps would be to investigate the DevEx framework, recently discussed as a follow-up of the SPACE framework.

Arnaud Porterie brought a talk about going beyond developer productivity and actually looking at engineering success. He stated that we are often unable to measure tech success, so accountability does not grow as much as the need for tech ; and that can bring trust issues within organizations. From his experiences, developer productivity is often not the bottleneck of organizations, but just the visible result of other points of failure. Once again, complexity is invoked to explain the specificities of tech organizations. To overcome those difficulties, he introduced three components to engineering success: alignment, delivery and health.

• Alignment requires clarity and stable goals. Shared incentives between Product and Engineering are critical here. Every daily task should be linked to those goals, and everyone should be able to see this. To achieve this, a quick and always closing feedback loop is needed to keep planning and execution fully aligned.
• Delivery: Metrics such as DORA, SPACE and so on can be good proxies to grasp this component. However, he insisted as well on the importance to interpret those metrics, with the context, and to use them to reflect and improve rather than to grade people.
• Health: With bad health, there is no alignment. And with no health, there is no delivery. This component is also included in SPACE metrics (S: Satisfaction & well-being). Tech & engineering are demanding domains, people should be at their best to perform. Companies must ensure they do all they can to allow people to be at their best.

Pure benchmarks and metrics don’t work: Engineering success is relative. This calls for a specific involvement and particular attention from leaders into their teams’s dynamic to continuously improve and navigate complexity.

All comes down to culture

Roland Flemm and Alexey Krivitsky gave a keynote about “Organization topologies in the era of DIY-frameworks”. One of the first point they tackled is again the need for continuous adaptation to the context: there are many frameworks out there trying to provide efficient ways to run software development: AGILE, SCRUM, Kanban to name a few. They stated that there are no absolute answers addressing the complexity of crafting software, and that teams can only get optimized to their context. But what if the context changes? Continuous adaptation is needed, and leaders must always re-invent their own framework, hence the “Do it yourself” ; picking best practices from various “standards” and putting together something that works for their context.

They also addressed an issue I have personally been facing several times already, and it feels good to hear others mentioning it: Tech KPI are often misaligned with Business KPI. A business can be running badly while the tech team is excellent, with short lead times and great delivery rate. Without providing an answer to this matter, I think through FlowCon 2024, the need for relative interpretations and continuous feedback loops, within teams but also with stakeholders has been put forward as a way to identify those misalignment and work on improving them.

During the keynote, they recall a basic notion of optimization: to optimize the whole, one must sub-optimize the parts. This is a clear statement for leaders to take a step back and continuously try to put together “the big picture” when trying to measure success and to improve.

Getting into this state of mind of continuously re-inventing the way we work, and finding ways to make everyone (teammates and stakeholders) comfortable with it are probably two of the biggest challenges tech leaders are facing nowadays. There are no absolute answers, and even given a specific context, chances are no individual can get the answer as the context complexity is too important for a single human brain to grasp. Only collaboration can get us through, and achieving this should be leaders’s first area of focus: building safe places for teammates to collaborate and grow, fostering autonomy, involvement and ownership, facilitating feedback loops, and embracing failing fast.

And then… back to the reality

I had a blast spending two days thinking about Tech & Engineering complexity, and getting hints about how one can help teams to navigate it. While most those topics are somehow familiar to me, conferences are always a good opportunity to reflect on them once again, and to take the time to ask myself: “Where are we on those topics?”, “Are we moving in the right direction?”, “Are we missing out onto something?”. Many ideas, and a rejuvenating flow of initiative came from this.

And then, I logged back into Slack to discover down-to-earth issues about an incident on one of our services, and an unforeseen issue on an upcoming release. It can be hard to keep the direction and the “big picture” clear in your mind when dealing with your day-to-day, especially in small companies where leaders are never far from operational matters. But I feel like those day-to-day struggles are probably the best place to start infusing ideas and practices within teams, to steadily set the direction and navigate the complexity the best way we can.