This interview was originally published for the Developer to Manager project, which is collecting experience and advice from engineering managers about their transition from software development.


Hello! What’s your background and what do you do?  ¶

My name is Kevin Deldycke and I was the VP of Billing, Payment and IAM at Scaleway, a cloud infrastructure provider. During my time at Scaleway, I led an engineering team of 11, and was one of the people in charge of the architecture, implementation and operation of the whole stack. If Compute, Storage and Network are the three pillars of the product ecosystem, then we, the Billing, Payment and IAM team are the core components of the platform. Our motto? Make complexity trivial from the outside, while streamlining the business.

The team I formed. I am the overly happy guy with the blue shirt at the center.

My story starts in 2003. The world was different back then. The dot-com bubble had just popped up and was still casting its shadow on the industry. After five years studying for a master’s degree in software engineering, the safest path was to join a big, traditional IT consultancy firm. I did the opposite, and joined a risky startup, with values I believed in: the philosophy of free/libre software.

That’s the first lesson here as a manager in the making: developers are not just looking for an occupational programming activity. They are seeking a culture, shared by like-minded peers. Guess what? As a manager, it is your role to create the conditions for a sustainable culture to emerge and persist.

So that’s how I started my 15-year journey as a backend engineer, in what was an esoteric language at the time: Python . I got the chance to work with smart professionals in various industries: brick-and-mortar retail, transportation, food processing, financial, energy, … This wide spectrum of projects made me realize that organizations and management styles are diverse, and mostly situational. But there was a pattern. The happiest people I encountered were the ones given autonomy, mastery and purpose , echoing Daniel Pink’s thesis on what motivates us  .

The majority will not breed the next unicorn; we statistically have a better likelihood of dealing with enterprise frameworks. That’s fine and can really be valuable in a career. But once in a while ambitious startups and business software intersect. Enter Scaleway  .

How was your transition from software development to management like?  ¶

In 2013 I joined a brand new R&D team as a founding engineer. We worked in total secrecy on what would become a cloud computing ecosystem, akin to AWS, GCP or Azure.

Scaleway’s founding team (I was behind the camera). All engineers & tech leads, no managers.

After a successful launch and incremental iterations, we got a huge investment to scale the whole thing up - both the platform itself and the organization around it. We not only had to grow, but also merge with the 20-year old established hosting company we were attached to. It was explosive, but in a good sense; it put new life in our venture.

The original founding group was disbanded and people were spread out in a massive reorganization. It’s like the job of the vast majority of employees changed overnight. Everybody was busy structuring the company, planning products and recruiting. There was so much to do. I loved the frenzy.

The system I designed and produced alone had to scale as well. And it had to absorb some existing legacy services. All the while keeping the business up and running, making sure those damn millions of euros were flowing right back into the bank account. On time. We’d better have a resilient team for that piece of critical pipeline. Right? So I was naturally propelled as manager of a brand new team, without fanfare, murky negotiations or pompous ceremony . I guess I was the only one with the vision to see all the fun (both technical and functional) there was in these contraptions! :)

I had no one to manage yet. But I felt empowered by a mission of bringing meaning and purpose in a place where everything had to be invented. We had the money, we were in the right industry, we already had customers, and competent engineering talents. The missing pieces were management and leadership. And I was just empowered to positively influence all that up at my humble level.

The last photo of the initial R&D team, right before it was disbanded and I (on the far left) became manager.

What does your day-to-day work look like, and what motivates you to do it every day?  ¶

The first phase of my activities as a front-line manager, was mainly inward-facing to the team. Because there was none yet.

So here I went for a year:

  • Recruiting a team of six developers;

  • Training them to take over engineering and operational duties (including my former ones);

  • Mentoring some into Tech Leads and Product Owners;

  • Trying to make myself optional and reduce the bus-factor;

  • Of course loads of project management was involved too:

    • Organizing and planning upcoming sprints;

    • Tracking delivered features;

    • Writing newsletters to share achievements and milestones;

    • Keeping in sync and aligns with executive’s priorities and fellow managers;

  • Writing the 3-year roadmap and business plan;

  • Designing a full revaluation process to assess and document engineer’s level and pay grade;

  • Helping other managers interview candidates and review profiles in hiring committees;

  • And all the other management tasks:

    • Leave of absences planning,

    • Frequent 1:1 with everyone,

    • Trial period assessments,

    • Experimenting with remote work,

    • Yearly objectives and target reviews,

    • Bonus and awards distribution,

    • Weekly travel to the regional office (the team was split in two).

It was not a place for routine, and the day-to-day was a varying mix of all of the things above, depending on the yearly/quarterly/monthly/sprint cycle we were in.

Then I was promoted to Vice-President, a fancy title, meaning I was now reporting directly to the C-level executives. The job came with the assignment of adding a layer of management between me and the engineers. It was the only way to get ready for the next stage of growth. I was an OK manager, I now had to find a better one to replace me. I was lucky to find Alexandre . He did, and still does, a stellar job taking care of the team I assembled.

Alex, the manager I managed, inherited a sufficiently hydrated team.

Then I started a second phase that was more outward-facing, in which I spent my time on coaching and managing managers, and doubling the team headcount.

Where did I get the drive to keep going? Good people to work with. I know it sounds dull, but you can’t fake it.

What are the biggest challenges you’ve faced so far? What did you do to overcome them?  ¶

One of the biggest challenges, and the first you’ll encounter right after your transition, is about managing your own psyche. Before you can improve on that, you’ll have to accept that indeed, we’re all just big bags of complicated, messy emotions . To make progress you will need to tune your response to others. And essentially to yourself. Be prepared, because it’s going to be an energy drain.

A manager with no one to manage yet, trying hard to recruit in a competitive market.

The only bearable way to live through that:

  • Turn off mails and Slack at home,

  • Plan frequent and short holidays,

  • Come out in search of regular outdoor activities.

In other words: find balance out of work, or you’re not going to last long  .

What has been the biggest surprise so far? Something you didn’t expect?  ¶

The first people I hired were key to our long-term success. I was lucky to have met proficient, dedicated and honest engineers. They cemented the backbone of our culture. I couldn’t have made it without them. It was not my team. It was our  team.

The biggest surprise is that once you get the right core of a team, the culture takes care of itself  .

The first members of the team, actively redecorating the brand new regional office. They all supplied the seed of our culture.

The payoff came a year later. A bunch of developers outside my authority were met with a case of bad management. It is sad, but in a company large enough, shit happens. They all requested to be moved elsewhere in the org-chart. And asked explicitly to join us, seeking peace, stability and a drama-free environment. You can’t dream of a better validation: we were a healthy team.

What’s the best advice you’ve received about being a manager?  ¶

I was told that starting from now on, I shouldn’t code anymore. That was an important clue. But it goes further. You’re no longer the decision-maker on your technical stack. Your team is responsible for it. You’re barely ratifying these decisions.

You probably used to make these decisions as a developer. And now that you switched positions, you have to take a step back, and have to accept the consensus reached by others. All the while being liable for the result and its impact. Now trying to reconcile the managerial accountability (which might have bad consequences for you), from the team responsibility (allowing them to move on), is borderline schizophrenia for ex-engineers. But you have no choice and have to learn to navigate in that constant duality.

What do you tell developers who are considering making the switch or new to the role?  ¶

Something along the lines of:

  • It is not a promotion: it is a change in career.

  • The expectations are different.

  • Reward will come from a place completely different from where you’ll put your effort to.

  • The granularity of your calendar will be reduced from half-day to the hour (half-hour, even).

Also, you’ll have to play the meta-game of:

  • Filing paperwork,

  • Attend meetings,

  • Repeat yourself a lot,

  • Use corporate tools (both apps and process).

All that work is not vain if you do it with the one noble goal of making your team productive.

The greatest effect you can prompt is providing them with the time and mental space they need to focus on things they do best: come up with outstanding software for the success of the business.

The final lesson I’ll share is the hardest. The higher you are in the hierarchy, the more likely you are going to step down for situations unrelated to your activity, or for things completely out of your direct control. i.e. things tend to get more political towards the top.

Final touch on our plans for the next quarter. Arbitrating priorities when every product depends on you is excruciating.

I’m happy our team ended up strong, demonstrating its capacity and functioning without me. Making myself obsolete, and still having the team perpetuating the values defining who we are, makes me proud of what we accomplished together.

The ultimate achievement during the last 24 months as a manager: nobody ever resigned during my term, while the rest of the company had the turnover expected (and planned for) of a high velocity/fast-paced innovating tech company.

My stint at Scaleway is foundational. I never stayed that long in any company before. It was the right opportunity at the right time. I’ll be forever grateful for the possibility in these past six years to not only build a crucial system from scratch, but also hire a team to take over it and bring the whole to the next level.

My transition is complete. Coding is no longer the most impactful thing I can bring to the table. Enabling engineers and making them feel productive is.

Final call to action! Where can we go to learn more about you?  ¶

I told you earlier I was super-geeky about the domains I operated right? Before going on to my next adventure, I took the time to summarize that knowledge. Here are the repositories consolidating all the stuff I gathered in the field:

Feel free to send PRs! :)