Introduction

In this wall of text, I will try my best to share my learnings, experiences and whatnot from the last 11 years. If you have 10-15 min to spare, feel free to tag along and hopefully you’ll enjoy the ride.

TL;DR

Having a technical role or a delivery one doesn’t make the other your enemy. Everyone has its own challenges and to overcome them to the best of our abilities, we need to embrace the relationship.
I was given advice regarding marriages and it was that it’s not you VS her/him but you AND her/him VS the problem. This same can be applied to any team : you are and should always be supportive of each other and face the challenges together.

Let’s start with the beginning

The beginning

My adventure began when I joined Bouygues Telecom as a mobile developer intern in 2013. During this very first experience, I started working on a set of 5 applications intended for employees, allowing them to synchronize their work with their Cloud space (note-taking, document consultation) as well as access various services (professional social network, news, directory).

The biggest change compared to school projects was the autonomy and responsibility that immediately fell on my frail shoulders. I had very little coaching or mentorship; I was provided with mockups and some vague documentation of the APIs to be used. Agility wasn’t yet adopted, so there were no daily meetings, no Sprints, no estimations, etc…

I went through all sorts of emotions, starting with a feeling of drowning and abandonment. Where are the teachers? Who are my project teammates? How will I manage to deliver these applications? Then came the imposter syndrome, which followed me for quite a few years (spoiler alert), where I felt I didn't deserve the opportunity I had and that maybe I simply wasn't good enough…

Finally, I asked myself the right questions: Do I want to advance in this path of Software Engineering, more specifically as a Mobile Software Engineer? Will I always need someone to hold my hand? I realized that if I was given a chance, it was because I was worth it and I could prove that I belonged.

I then took the initiative to set up a meeting to show the progress of my tasks and even do demos. The feedback was very positive, and the negative spiral turned into a positive one. At the end of my internship, I continued with them as a Consultant, always maintaining this proactive dynamic and making the most of the challenges presented to me.

After a year and a half, it was time for me to say goodbye and see you soon ?

Sprinkle some “agility” in it

My next mission was going to be with RATP in 2015 and what they call the mobility unit. Its purpose was to build Android mobile applications for their employees. This was my first experience with boilerplates.

This was my first experience working with a team that has multiple developers, Product Owner and a Scrum Master. Yes you’ve heard it, we were adopting Scrum methodology, and what a change it was. We also faced one of the first biggest changes from Google regarding their Android platform : Material Design.

So how did we manage all that?

Let's start with the first challenge that was more personal. Well to be honest, it quickly turned into a strength because I fell in love with the methodology and what it represented.
We’re finally thinking about the users! No more V-cycle; we deliver at the end of each Sprint, continuous improvement, and most importantly we deliver VALUE to our customers.
In retrospect there was so much room for improvement as we didn’t hold a daily meeting but rather once every 2 days, there wasn’t a proper Poker Planning as estimates were basically 2 SP = 1 M/D and some other misimplementations.

As for the second challenge, the circumstances were that I worked almost alone on the migration to Material Design for our boilerplate. Empowered with the satisfaction of being involved in the product, I cruised through it and everything went as smooth as it could’ve been.

At the end of my mission, I was so grateful for this opportunity as it basically shaped my view on mobile applications and cemented what Scrum is really about : we are working on a product and not code only, and we need to deliver value to our customers.

Responsibilities

Home sweet home ?
In 2016 I came back to Bouygues Telecom as an experienced developer and agility enthusiast rather than the skinny, frail intern I was 3 years ago. To give some context, I was asked to come help the same team I worked with before but this time on their biggest mobile application that had (at the time) between 1 and 1.5 millions users monthly. No stress right ?

Well the good news was that they’re using Scrum methodology. The bad news was that they had a variable Sprint duration (depending on the PO’s needs), no Sprint Retrospective and a team that never worked properly on said methodology.
Regarding the technical side, we had no CI/CD, no internal testing platform, everyone pushed to the same “master” branch.

What we had is a young motivated team that lacked some leadership and decision maker. Well I guess I have to fill this role (and I don’t mean it as a flex, but it was basically what the team needed).
Being 25 years old at the time, I was basically considered a senior or even Tech Lead in the team and Scrum Master at the same time. I was thrown back to 22 years old me, lost in the sea of what needed to be done with a sprinkle of Imposter Syndrome yet again, but this time I had the agile methodology with me, and the very first thing I started with (after taking a deep breath) was splitting in small tasks and prioritizing them.

I started with 1 “agile” task and 1 “tech” task :

• The agile task was to decide, as a Scrum team, the duration of our Sprint. The duration will be set in stone and will not change depending on the backlog or what was needed to be delivered. It was done after explaining the reason behind the concept of a Sprint is to maintain predictability and consistency, which is an argument that speaks to upper management.
• The tech task was implementing an MVP of a CI/CD. I’ve started to install Jenkins / Fabric (yes it was a thing back then) and create a job for each platform (Android / iOS) that deploys to Fabric for internal testing every time something is pushed to master branch, and a manual job that generates a signed APK/IPA. A consequence of this task was to lock master branch to force every developer to have their own feature branches to work on and create a Pull/Merge request after they’re done.

Now you might ask how in the hell were you able to convince them to let you work on these tasks during a Sprint ? Well the answer is that I didn’t, I took it upon myself to work on this in my personal time and show the result when I had something that is showable. I do not advocate using your personal time to work on your professional stuff, but sometimes this might be the only way to go forward and make a positive impact on the team.

With that in place, it was much easier to propose other improvements and make time to implement them, whether it’s to improve our “agile” life or “tech” life, and to this day, this might be my biggest and proudest accomplishment and can peacefully move on onto my next chapter.

Now onto the delivery

Before we go to the next chapter, I’ve skipped the latest mission in SNCF from 2017 to 2018 as it was the same role as I had in Bouygues Telecom a year before.
The team was working perfectly fine and it was the embodiment of what I tried to help Bouygues Telecom’s team.
The biggest challenge was the scale up, as we started as 9 developers and ended up with 40+.

Home sweet home ?

As you might’ve noticed, all of my previous experiences were in France, but in July 2018 I decided to come back home (Morocco) and joined the Nespresso team as a Technical Project Manager. After 5 years working mainly on the “tech” side, let’s dive into the “delivery” side.
Do you hear it ? Yeah it’s the music of Imposter Syndrome coming back for a third episode !
For 5 years, I worked with different products, people, even companies. I even thought of myself as a pretty experienced person.  How have I never, even remotely, been aware of what was waiting for me?

I came to my personal home, but I’ve never been so far from my work home in my life.

Here I am, a Project Manager of a team of 12 people (Tech Lead, Devs, QA and myself), some of them more experienced than me, working on one of the biggest eCommerce websites of the world, generating more than half a billion dollars a year. No pressure.

This might be the most important part of this article as this is the exact moment I’ve gotten  the answers to so many questions I had before : why is the deadline being imposed ? Why are we pressured to do X, Y or Z ? Why do they prioritize this over that ?

Deadlines here, deadlines there, deadlines everywhere

The answer is so simple yet so difficult : money. I know this is a controversial take, but I will die on this hill : Everything is about money but not the way you think.
Of course every client wants to optimize their budget but not to the point of being greedy, and this is the difficult part of the answer. Every team costs money, and if you’re working in a consulting firm, your whole firm costs money to the client. There are competitors that will gladly snatch the client from your hand because they’ll try to sell the same workload with a bit less money. This is where I understood what is REALLY at stake here. We’re walking on a very thin thread that might snap at any time.

Do you know what costs a lot of money ? Bugs. So you not only have to optimize the team’s cost, but you also have to deliver top quality work to avoid bugs.

Now if you’re not depressed yet, there is some silver lining in this. When we talk about money, the client (and by client I mean the people you work with on the client’s side) don’t pay it from their pockets. So as long as you keep them satisfied, you should be in the clear. And how can we do it ? By making their products the best !

Imagine a world, as a client, where you have a dedicated team working with you, understanding your needs and anticipating them, delivering top quality products, being transparent and proactive with you, I will consider them my best friend. I made my goal to be that best friend.

And the team in all of this ? Should I go all in for my client ? Should I go all in for the team ?

Well neither, my goal was to find the perfect balance between my team and my client. At first, I needed to understand their needs, independently. What made the client pushy? Why do we need 4 days to deliver that feature ?
On one hand, through communication, you’ll have to learn what’s at stake for the client.. For example, if he gives you an impossible deadline,  you can try to deliver an MVP instead and explain that you can work on the enhancements on the next iteration.

On the other hand, you’ll have to understand your team’s difficulties and challenges. Are they recurrent ? Are they temporary ? What are the impacts of the product ? The answers to these questions should be shared with your client with transparency as he should be involved in your team’s work the same way you’re involved in his. This is a partnership ! Of course you’ll also have to take some actions to amend these challenges in order to improve.

If your team understands your client’s challenges, and the latter understands the former’s, that’s it. This way, you won’t have 2 or more “entities” anymore,  but one that is working towards the same goal : enhancing the product(s). The client will be more keen to understand why X or Y needs time, and your team will understand what’s at stake.

Something is missing…

After spending my last 5 years as a Project Manager, I started to miss developing and being close to my IDE. The thing I’ve omitted before is that I wasn’t that close with the code when I was a project manager. Yes, I did get involved and did help when I could my team, but at the end of the day I had to manage the finances, delivery, impediments, communication etc… which left me almost no time being close to coding again.

Back to where everything has started (just a bit older)

Alrighty, how does an IDE work again ?

Joking aside, in the summer of 2023 I joined Nimbleways as a mobile Tech Lead to return to my roots. I’ve never forgotten about mobile development, even as a Project Manager and I really missed talking about Activities, Fragment and AsyncTasks (again joking).
Well long story short, I’ve joined BPI as a Tech Lead of a project using Spring Boot and React/Angular as its technical stack. Yes, I'm talking about a web project.
Should we bring back imposter syndrome number 4 ? Well yes and no.

At first yes, I think there was a bit of it because I was supposed to be a Tech Lead of not only a technology that I’ve barely touched, but it was a whole new environment. Mobile is very different from Web. To put it simply : I don’t have the technical requirement that a Tech Lead should have.

So why the no ? Well I’m not entirely useless as my 5 years as a project manager helped me a lot regarding communication with a client, involvement with his product and most importantly : understanding him. Since we were the newest team working with our client, this was pretty much our biggest priority at first.

Then, thanks to my other 5 years as a developer, I’m trying to catch up on the technical side and widen my knowledge especially on web development while maintaining the balance between prioritizing the client’s needs and making sure that our team is shining and having a work environment that suits us.

Finding the perfect balance, as all things should be

If you’ve read up until now, all I can say is thank you for reading about my life and work experiences. I don’t even know what to call this, is it a blog article ? a diary ? both ? You’ll be the judge, but what is certain is that this is my journey through the challenges that life has brought me and what lesson I’ve learned from them. Even if I’ve helped you the slightest bit, I would consider this wall of text a success and please feel free to share in what way if you like, if not, feel free to tell me why, I’m all ears (or eyes).

At the end of the day, this is also my life and I would not be me, if not for all the people that trusted me and endorsed me so I would like to thank everyone I’ve worked with, closely or not.

Takeaways

Imposter Syndrome

You’re never an imposter, if you were given an opportunity you should seize it and make the most out of it. If you think you’re not good enough, give yourself the opportunity to become good enough and you’ll feel the satisfaction of being the man/woman of the situation

Tech vs Delivery

Please, never ever take them as 2 entities. Remember that you’re one team, and even though it sounds cliché, this is true. The only thing preventing you from reaching this state is communication. Be transparent, share your difficulties and don’t be afraid of challenging and being challenged.

Adapt, Improvise, Overcome

Our journey is a never ending path that is strewn with pitfalls, some you’ll see and some don’t. Never lose sight of your goal. We’re never prepared for everything, and even after 11 years of working in the industry, I still discover new subjects that really challenge me (some in a good way, and some in a bad way). So take it easy, enjoy the journey while it lasts and find every possible way to improve, whether it’s your skillset or your mindset.