Mohamed Gamal: The Art of Architecting Strategies for Future-Proofing Tech

00:08 - 00:21
My name's Matt, and I will be talking to Mohammed Gamal about architectural decision making and transitioning company cultures. Hey, Mohammed. Good morning. Happy to have

00:21 - 00:23
you here. Hey, Good afternoon.

00:23 - 00:25
Happy to have you as well.

00:25 - 00:28
Good afternoon. You're right. You're right. It's 2 PM.

00:28 - 00:32
We are in Europe, so and it's Friday, so it's almost a weekend.

00:32 - 00:37
So it's, like, a good point to start the weekend or interview. Right.

00:38 - 00:43
And, Mohammed, I'm, I'm not especially passionate about the interest.

00:43 - 00:47
I think, like, people know you, they will know you from the description.

00:48 - 00:54
But what is interesting, and I would, would love to start right away with the question, you

00:54 - 00:58
worked for a sum up, pretty, like, successful Fintech recently.

00:59 - 01:08
You've got, like, a quite a quite a big round, so I hope you have a lot of money to spend on technology in your department. Everybody holds

01:08 - 01:09
so. Yeah.

01:11 - 01:18
And, so we recently talked, it was really interesting in what apartment you work because you

01:18 - 01:20
work in a platform in that department.

01:20 - 01:22
So maybe could you tell a few words about it, and what do you

01:22 - 01:25
do there? Yeah. Of course.

01:26 - 01:30
So the platform team by nature is more foundation team.

01:30 - 01:38
So, you need if you work in tribalized world, which is Spotify model, we can, go through later.

01:39 - 01:45
When the team gets much bigger, you in the end need 1 team that's responsible for the architecture,

01:45 - 01:52
the architecture vision, the architectural or engineering direction you are going to.

01:52 - 01:59
So it should kind of oversee all the products and how products work together and be the center of this.

01:59 - 02:03
So actually, the platform team doesn't own feature by nature.

02:04 - 02:11
The plat the platform team owns tooling, services, to help engineers to deliver better products,

02:11 - 02:19
more stable products, observability, for example, to always have track over the data, over the crashes, everything.

02:19 - 02:27
So it's more a gain of foundation team that have simply architecture vision and providing tools

02:27 - 02:32
to engineers to help and support them through their engineering process, the coding, and so on.

02:33 - 02:35
So, yeah, in few words, is that what it means?

02:35 - 02:39
And the platform tribe, it's still a tribe as every other department.

02:39 - 02:41
It's it has different teams.

02:42 - 02:45
So the team I work for is called the mobile platform.

02:45 - 02:50
So we are more dedicated or only dedicated, dedicated for the mobile.

02:50 - 02:57
We don't own any features that you can see as a user in the end, but we own again the foundation,

02:57 - 03:04
how the products work together, how things should align, how to add a new library, new dependency,

03:04 - 03:11
how it's going to affect the other dependencies, to have, libraries to provide engineers with libraries for observability.

03:11 - 03:16
For example, as I mentioned, also being the DevOps for the mobile.

03:16 - 03:23
So we own the CI and CD and all of these processes, the release management, with the Play Store

03:23 - 03:25
and Apple, Store and so on.

03:25 - 03:30
So more or less, that's what we it depends, of course, on everybody role, but in the end, we

03:30 - 03:36
are kind of, I'd say, the lubricant between the tribes. So yeah.

03:38 - 03:40
Well, thank thanks for thanks for that.

03:40 - 03:46
I think it's, like, clever solution, but I'm just wondering what kind of challenges, what kind

03:46 - 03:49
of typical challenges on or pain points do you have?

03:49 - 03:52
Like, because you have a huge impact on the whole organization, on

03:52 - 03:58
the whole application, but what are the typical challenges and pain points? Yeah.

03:59 - 04:06
So, usually, the challenge is that by time, people feel I mean for every platform team, I don't

04:06 - 04:11
mean necessary in my case, but by time people might feel that they don't really have full responsibility

04:12 - 04:16
or ownership over what they are shipping and how it impacts other things.

04:16 - 04:21
Because with teams, usually they focus on their own product to deliver their own product in

04:21 - 04:24
the best way, but they don't see how it affects the others.

04:25 - 04:31
Having platform team also helps in this because you still know if I broke something the platform

04:31 - 04:34
team is gonna know about it, so they are gonna take care of it.

04:34 - 04:39
So I think this kind of minimise a little bit the responsibility of seeing the big picture.

04:39 - 04:44
So that's the big the biggest challenge for us is to not do that.

04:44 - 04:46
So we want to solve things.

04:46 - 04:50
We want everything to be integrated well integrated.

04:50 - 04:56
But on the other side, we want also teams to feel responsible for what they do and see the big picture.

04:56 - 05:02
So I'd say, in my opinion, that's the biggest biggest challenge you have, is that you need to do both together.

05:04 - 05:10
And, who is your partner in crime of who you usually work and where you can solve your decisions?

05:11 - 05:16
Yeah. That's a very tough question, I said. Okay.

05:17 - 05:24
Basically, our team is really, really self driven, so we never make individual decisions, for example. Everything comes through documents.

05:25 - 05:26
We challenge each other a lot.

05:26 - 05:28
We are very, very honest together.

05:28 - 05:32
We don't have this political thing like, yeah, okay.

05:32 - 05:33
And then we change things.

05:33 - 05:35
No, we we are very challenging peeps.

05:36 - 05:43
So I'd say all, but the closest one, of course, because I'm more into Android. There is, Tiago.

05:43 - 05:45
Now he is engineering manager of our squad.

05:46 - 05:48
So we work together all the time.

05:48 - 05:54
Also, because we firefight a lot, so there is, something happening in release and so on.

05:54 - 05:57
We pass we keep passing, things to each other very freely.

05:57 - 06:02
So I would say, yeah, if it's a partner partner of crime, it's him.

06:02 - 06:05
So and for this reason, we really firefight a lot.

06:07 - 06:10
And why do you firefight a lot? Why is it so?

06:10 - 06:15
Yeah, because, again, we oversee how everything works together.

06:15 - 06:20
So firefighting, it's not necessarily, something about the app performance in production.

06:21 - 06:28
This rarely happens, but it's more of how things are integrated and what's the direction teams are going.

06:28 - 06:35
For example, only talking about Android team, it's more than 40, 45 engineers. Same for iOS.

06:36 - 06:44
So all of these engineers don't know that others are working maybe on the same thing or maybe something that will conflict.

06:44 - 06:50
So this when you go advice, sometimes you need to kind of, yeah, be very patient.

06:52 - 06:58
Really try to coach people that they need to learn about how everything is connected and work together.

06:58 - 07:06
This I still call firefighting because when you add, for example, new dependency to, your project, it might break everything.

07:06 - 07:11
But you don't know that because you want to shape your sense, you test, it works, but you don't

07:11 - 07:12
see what's happening behind the scene.

07:13 - 07:15
And that, yeah, that happens a lot.

07:15 - 07:21
So overseeing this, yeah, we need to pass, problems to each other and yeah.

07:21 - 07:23
Okay, Thiago, you are tackling this. Okay. No.

07:23 - 07:25
I'm tackling this now and so on.

07:25 - 07:27
So, yeah, that's why I choose.

07:28 - 07:34
And you mentioned the tribes, tribes are squad, so, like, in a in a Spotify kind of manner.

07:34 - 07:38
So could you tell me more about it?

07:38 - 07:39
How does it work for you?

07:40 - 07:43
Are there any down side of that kind of approach?

07:43 - 07:45
Because this is a really popular model. Right?

07:45 - 07:53
It is. I mean, I wouldn't understand a company with 100 employees size applying this, to be

07:53 - 07:56
honest, like, because it doesn't make sense.

07:56 - 08:01
So I also work it in different, styles, I'd say, not only the Spotify model.

08:02 - 08:10
But when some company like SumUp, I think we are more than 3.5, k employees, so it makes more sense.

08:10 - 08:17
So what exactly it does is that it offer you good, team structure, it's autonomous approach,

08:17 - 08:20
how to scale the agile, and so on.

08:20 - 08:25
So, basically, you have tribe each tribe is responsible for its domain.

08:25 - 08:29
In big companies, this domain might be a small company inside the company. Yeah.

08:30 - 08:33
And then this tribe has its own teams.

08:33 - 08:39
So, also the responsibility is shared across teams and the beauty of Spotify models that it

08:39 - 08:42
doesn't force all teams to work using the same methodology.

08:43 - 08:44
So every team is autonomous.

08:44 - 08:48
They can work as they like, In the end, they contribute to the big vision.

08:49 - 08:52
But on it on their own way, so it's not forced.

08:53 - 09:00
And then because also all of these teams are kind of cross, functional teams.

09:00 - 09:03
So you also need to have kind of chapters.

09:03 - 09:08
So every team has back end engineers, front end engineers, mobile, blah blah blah.

09:08 - 09:10
Then you have chapters for these domains.

09:10 - 09:12
So for example, you have mobile chapter.

09:12 - 09:15
Inside it there is Android chapter, iOS chapter, and so on.

09:15 - 09:21
So you always also get everybody together sharing knowledges, sharing knowledge and so on.

09:22 - 09:23
And it has many other details.

09:23 - 09:27
Let's not I think there are lots of people can talk about this way better than me.

09:29 - 09:40
So the downside in my opinion is prioritization, because in the end each entity, which is tribe

09:40 - 09:42
in this case, has its own priorities.

09:43 - 09:46
So the alignment becomes a problem sometimes.

09:46 - 09:50
You need always to be aligned and it's it's I think it's the hardest mission ever.

09:50 - 09:57
To be aligned on the vision, to be aligned on the priorities of your team against the priorities of other teams.

09:57 - 10:00
So I think this is the biggest, challenge.

10:00 - 10:06
So you need always to work on this because I think this is the biggest deal in my opinion.

10:08 - 10:14
So, yeah, I think also maintaining a shared vision is kind of problematic because, again, like,

10:14 - 10:19
with different domains, it's very hard to come up with a shared vision for all together.

10:20 - 10:23
So this also is a little bit challenging, I'd say.

10:25 - 10:32
Also, hiring, for example, is a is a challenge because when it comes to this and each tribe

10:32 - 10:41
is very big, big enough, they have their own, let's say hiring, process or standards.

10:42 - 10:48
So you also need to work on this kind of standardizing the hiring process across all tribes,

10:48 - 10:52
not only, each tribe is free to do whatever they want.

10:52 - 10:54
Because in the end, you care of the quality.

10:54 - 10:59
All engineers or all employees will be with the same quality, with the same titles in all tribes.

10:59 - 11:01
So this is also a challenge.

11:02 - 11:09
The last thing in my opinion is the resource allocation, or talent distribution, what I mean.

11:10 - 11:11
So some tribes are overstuffed.

11:12 - 11:14
They have enough people, other tribes no.

11:14 - 11:19
And but with this tribe tribalized world is very hard to share the resources.

11:20 - 11:25
Because sharing the resources is kind of changing the entity you work for.

11:25 - 11:30
It's not that easy, that you just in your tribe need mobile engineer, another tribe has maybe

11:30 - 11:32
2 more than they need.

11:32 - 11:34
No, you cannot share this easily.

11:34 - 11:36
So this is also something to work on.

11:36 - 11:40
But once you take care of these things, once you already know the downsides and you work on

11:40 - 11:48
them, I think it's, in my opinion, the perfect setup. Thank you for that. That's really interesting.

11:48 - 11:49
I haven't so for the

11:49 - 11:53
first time, I'm hearing the downsides of the of the working in tribes.

11:53 - 11:59
I heard a lot of, like, advantages, and I haven't heard about this of the hiring process and,

11:59 - 12:02
like, you know, moving people from one on one side to another end.

12:02 - 12:06
That this is so difficult, so, I think this is invaluable knowledge.

12:07 - 12:12
And recently when we talked, we talked about the, a few technical concepts.

12:12 - 12:20
So, and the one that, stuck in my mind was the discussion about the polyrepo versus monorepo. Yep.

12:20 - 12:27
So if you remember if you still remembered our conversation, maybe you can elaborate on that because this was yep.

12:29 - 12:36
So, like, for example, talking about the back end, what is the biggest architecture trend now is more of microservices. Yeah.

12:36 - 12:38
So each service is stand alone.

12:39 - 12:42
It's still connected somehow, but stand alone.

12:42 - 12:44
So in mobiles, that's different.

12:44 - 12:49
You cannot really apply this because in the end, you ship 1 app.

12:49 - 12:53
It's one product that you ship, you upload to the Play Store. Everything together.

12:53 - 12:55
It cannot be cut into pieces.

12:56 - 12:59
Architectural wise, yes, but delivery wise, no.

13:00 - 13:06
So most of the mobile development goes through the mono repo pattern, which is everything in

13:06 - 13:09
one place, everything in one, GitHub repo.

13:09 - 13:15
Everybody contributes to the same thing, and in the end, everything is shipped together.

13:15 - 13:16
The poly repo is a bit different.

13:16 - 13:21
It's more like microservices, but for more I mean, it's more like microservices.

13:21 - 13:26
So you can cut for example, you have domain, some app app, for example. It has bank domain.

13:26 - 13:29
It has checkout domain, it has big domains.

13:30 - 13:36
You can cut these domains into SDKs, and each SDK is separate repository and has its own version,

13:36 - 13:39
and in the end, these things integrate together.

13:39 - 13:46
So in the end, in my opinion, both of them work very well, but both of them have lots of downsides.

13:47 - 13:53
So the monorepo, it gives the engineers the opportunity to see everything because they have

13:53 - 13:58
open pull requests, for example, for every change of the code, and it's all in one place.

13:58 - 14:00
So that's a very good, thing.

14:00 - 14:04
But the downside is it's also it also gets overwhelming.

14:04 - 14:09
It increase, the build time so much because every and this is the most painful thing you will

14:09 - 14:12
hear from any mobile dev, especially Android dev.

14:12 - 14:16
Especially in big company, the build time, and it takes me forever to build the code.

14:17 - 14:22
So this is also one of the downsides of the monorepo because you need to build everything together.

14:23 - 14:28
The polyurepo is a bit challenging because also you need to align the versions together.

14:28 - 14:31
The version how all of these SDKs work together.

14:31 - 14:35
So that's the challenge part the challenging part, but in the end, it's much faster.

14:35 - 14:38
You are free to do whatever you want in your repo.

14:38 - 14:40
You are free to test the way you want.

14:40 - 14:50
You are free to do whatever, and then you ship new version, maybe weekly, and you put it in the app, integrated, done. Cool. It comes with downside.

14:50 - 14:53
Again, another downside is with testing.

14:53 - 14:56
It's because you it's you don't test the integration all the time.

14:56 - 14:58
So, I mean, both of them are good.

14:58 - 15:04
My personal opinion is to go through polyurepo and try to minimize the side effects of it.

15:04 - 15:08
There are many ways to do that as that's how I see it.

15:09 - 15:13
But in the end, both of them work the most important thing to keep maintaining, and this is,

15:13 - 15:15
biggest deal in software engineering in general.

15:15 - 15:21
Because, anyway, whatever you do is legacy, it's gonna be legacy very soon, so you need to make

15:21 - 15:26
it a fine legacy, not not the legacy that people will suffer in 5 years here.

15:28 - 15:34
And you tackle the the the the trends, in software development, like the microservices. Right? Everybody's going this way.

15:34 - 15:39
And another question that I wanted to ask you to give you a bit of a background, so this was

15:39 - 15:44
with what with, something that I was struggling before, like, running the the the company.

15:44 - 15:49
So, like, my my company that I'm running, the Brain Hub, we are, like, the JavaScript dev shop. Right?

15:49 - 15:55
And when we started it, like, I think it was, like, 8 or 9 years ago, the JavaScript was growing like crazy.

15:55 - 16:00
So, like, each week each day, you have, like, a new framework, new library, and the developers,

16:00 - 16:03
especially the developers, showed up their study.

16:03 - 16:05
This is their first job or they are just studying.

16:05 - 16:07
They are not so experienced.

16:07 - 16:13
They just, you know, trolley with you, like, with all those libraries, frameworks, that we should go with this way.

16:13 - 16:17
We should go this way, this way, and you have, like, plenty of those.

16:17 - 16:25
So I'm just wondering, how do you approach saying no to new things, and keeping devs happy developers

16:25 - 16:26
happy at the same time?

16:26 - 16:29
Yeah. I would say it's a muscle you train.

16:32 - 16:38
Because yeah. In the beginning, especially when I joined platform because this is the teams

16:38 - 16:41
that usually say no, but for a reason always.

16:41 - 16:45
So, hopefully, people understand that it's for a reason.

16:45 - 16:51
So, yeah, in the beginning, I used to say, like, okay, maybe that doesn't work. Okay?

16:52 - 16:54
But maybe without giving enough context.

16:56 - 17:04
After that, time by time you learn how people would get more interested or how they will buy in your idea.

17:05 - 17:08
When you share context, when you share yeah. You know what?

17:08 - 17:10
This, this, this, they don't work together.

17:10 - 17:16
Like, something feels very trivial updating library version, not even adding new library, adding

17:16 - 17:18
just updating the dependency version.

17:18 - 17:24
It might break every cycle easily, because in the end there is there are transitive dependencies,

17:24 - 17:28
and if every dependency has an other dependencies with different versions, whenever you update

17:28 - 17:30
one version it might break everything.

17:31 - 17:35
I think now, by time, also most of engineers now understand this.

17:36 - 17:42
So now to be honest, it's not hard to say no because sometimes even before going and saying

17:42 - 17:45
no, I see other people already did this and they already understand.

17:45 - 17:51
And to be honest, this is the best thing here is that I think the people from the past before

17:51 - 17:57
even me coming here, they developed this culture that people now understand and have kind of

17:57 - 18:02
shared knowledge about the app or about our products, these products we ship.

18:03 - 18:09
Also, there is something that makes things easier is that, you always have something called

18:09 - 18:12
dependence trees that mentions all the versions and everything together.

18:12 - 18:18
So whenever you open a pull request for some changes, you see what all the how all the versions

18:18 - 18:24
change it, and it's very easy for you, very visible to understand the impact of what you have done.

18:24 - 18:30
The problem only happens when maybe new engineers join, so it's it should be a part of the onboarding

18:30 - 18:34
that they need to understand that whatever they do, the impact is very high.

18:35 - 18:40
But in the end, they really accept it very, in very friendly way, and it's very fine.

18:41 - 18:46
So even we keep, challenging each other, like, okay, maybe it becomes a negotiation or kind

18:46 - 18:51
of, like, okay, I want to update to version 5, but, yeah, we have version 3. Okay.

18:51 - 18:53
What about updating to version 4? Would it work?

18:53 - 18:58
You know, like, it's like trading. Yeah.

18:58 - 19:00
That's that's exactly what I mean.

19:00 - 19:02
It's a muscle you train. So.

19:04 - 19:08
And let's talk a bit more about the technical aspects.

19:08 - 19:14
I heard once from the CTO that, from one CTO that you mentioned that architecture decisions

19:14 - 19:17
should be the last one to make, like, as late as possible. Right?

19:17 - 19:21
Because it has a huge impact, and it stays with you for a longer time.

19:21 - 19:26
So I'm just wondering in your case, because you already mentioned, the legacy. Right?

19:26 - 19:28
At some point, everything will be legacy.

19:29 - 19:34
But do you have any actionable tips, how to plan properly the architecture?

19:35 - 19:43
Like, how to do it before other leaders, what they should avoid maybe, or what are the common mistakes in this area? Yeah.

19:45 - 19:50
So to be fair, it's impossible, as you said, it's impossible to avoid legacy. This is gonna happen.

19:50 - 19:53
This happened in the past, happening today. It's gonna happen.

19:53 - 19:56
We are building legacy code for future.

19:57 - 20:05
So I think the word legacy is kind of misused because legacy itself is not a bad thing. It's fine.

20:05 - 20:08
If it's working perfectly, it's fine.

20:08 - 20:14
There are new trends that make things work easier, but that doesn't mean that the old ones weren't bad.

20:14 - 20:18
So I I always don't take legacy world as a bad thing.

20:19 - 20:25
But you need to reduce, the bad impact of the legacy in future.

20:25 - 20:28
To be honest, with doing this, it should be easy.

20:28 - 20:34
Anybody who studies software engineering, it should be easy, but it's not as easy as it sounds

20:34 - 20:36
because in the end you need to ship things.

20:36 - 20:37
And this is the main goal.

20:37 - 20:39
We are a product company.

20:39 - 20:42
Most of the companies are product companies, and you need to ship.

20:42 - 20:46
So usually you make your decisions based on the timeline you have and so on.

20:46 - 20:50
Like, there is always a fun joke that, okay, I will fix this later.

20:50 - 20:52
I will just deliver this and fix this later.

20:52 - 20:55
This fix this later would never happen.

20:55 - 20:59
So he's just like, yeah, okay, I misdeliver and we will optimize.

21:00 - 21:06
I never seen somebody who revisited the codes they have done just to optimize.

21:06 - 21:07
I thought this is not happening.

21:08 - 21:15
So I think, in my opinion, they everybody, including myself, is also a reminder reminder for myself.

21:15 - 21:19
Just follow the solid the very basic solid principles.

21:19 - 21:23
When you follow principles, when you follow clean architecture, you when you keep this in mind

21:23 - 21:30
all the time, you will not have bad impact of whatever you write now because it's always open for change.

21:30 - 21:33
It's only, it's always scalable and so on.

21:33 - 21:37
So when when you keep this in mind, I think it works and that's enough.

21:37 - 21:41
So that's how I I take it.

21:42 - 21:45
You need also to learn how to plan the architecture.

21:45 - 21:50
Of course, as you say, the architecture is not the first thing you think about.

21:50 - 21:56
So you need to learn about the business, how the business will be shaped in 2 3 years. It will always change.

21:56 - 21:58
You can learn about it, then tomorrow it will change of course.

21:59 - 22:05
But you build the architecture based on the business needs, because maybe in the end you don't

22:05 - 22:07
need to have fancy setup.

22:07 - 22:10
Maybe the the simple setup will work better for you.

22:11 - 22:18
Because whenever also you try to build fancy things that's more complicated than needed, that

22:18 - 22:20
will end up with bad legacy.

22:20 - 22:23
Because later why why all of that and we don't need it.

22:23 - 22:24
You know what I mean?

22:24 - 22:32
So, yeah, in in in summary, I don't think legacy is bad, but we need to make sure as much as

22:32 - 22:34
we can that it's not gonna be bad.

22:34 - 22:36
It's gonna be a legacy. Yes. It will be.

22:36 - 22:41
So I don't know if this answered your question, so please correct me.

22:41 - 22:42
More or less, I cannot correct.

22:42 - 22:46
I'm not well, you know, educated enough, like, in this area. So

22:50 - 22:55
No. I I think that's, that I think that's no. It's a good answer.

22:56 - 23:03
And, Mohammed, I wanted to ask you, like, a tough question because, like, everybody of, each

23:03 - 23:07
of us, we learn from, like, really hard things at work.

23:07 - 23:13
So I'm just wondering what was the hardest thing or situation that you have experienced in your

23:13 - 23:16
career impact, and what you have learned from that?

23:19 - 23:27
I think the biggest step, the hardest for me, and it took lots of time to adapt, is moving from

23:28 - 23:36
the software house culture and environment and, yeah, To the product company.

23:36 - 23:39
So software house is very different with very different mentality.

23:40 - 23:44
You need to you you don't care a lot about the future of this product.

23:44 - 23:46
It's not your product in the end.

23:46 - 23:51
I used to work for a software comp a house, for 5, 6 years.

23:52 - 23:59
I worked on 9 different projects in these 5, 6 years. It's very different mentality. It's very different mentality.

23:59 - 24:02
All of what you want is to ship.

24:02 - 24:07
All of what you want is to ship with without crashes because this is a problem for the client.

24:08 - 24:12
And also you need to deal with the client, you need to understand the requirements, and so on.

24:12 - 24:14
You are in the end in the end you are doing everything.

24:15 - 24:17
I learned a lot from there.

24:18 - 24:21
But moving to product, that's totally different world.

24:22 - 24:23
Things are not the same.

24:23 - 24:27
You need to understand very well what the product is because it's your product.

24:27 - 24:32
You really care about the product because in the end, you are the one who is responsible for it.

24:32 - 24:35
You are the one who is responsible for testing it.

24:35 - 24:37
You are the one who is responsible for the feedback.

24:37 - 24:45
In software house, it's the opposite because the client in the end will test and will come to you with the feedback. It's very different mindset.

24:45 - 24:48
So to adapt to the new mindset, it took me a while.

24:49 - 24:50
It it really took me a while.

24:51 - 24:54
But in the end, yeah, after I don't know, 4 years now. Yeah.

24:54 - 24:58
Maybe 4 a little bit more than 4 years working for only product, companies.

24:59 - 25:02
I think now everything together makes sense, but only after 4 years.

25:02 - 25:04
Now it's easy, of course.

25:04 - 25:09
Now I kinda connected like, okay, back then the client to me was the real client.

25:09 - 25:11
Now the client to me is the stakeholder.

25:12 - 25:16
But we both have the same vision because we both work on the same product.

25:16 - 25:18
We both care about the same thing.

25:18 - 25:22
That's the only difference for me now, but back then, of course, it was horrible. It was very hard.

25:24 - 25:27
Now, what are your biggest challenges in 2024?

25:32 - 25:35
Okay. Technical wise,

25:38 - 25:46
the unification maybe of our, products because, yeah, we have multiple, products, and now there

25:46 - 25:53
are some mergers or some product needs some, features from the other and so on.

25:53 - 25:58
So this unification thing and sharing is is a big one.

25:58 - 25:59
It's really a big one.

26:00 - 26:07
Also, KMP, for example, if you know is Kotlin Multiplatform is new.

26:07 - 26:09
It's it's a new good trend.

26:09 - 26:10
It's not just a new trend.

26:10 - 26:11
In my opinion, it's a new good trend.

26:12 - 26:19
So introducing it to, sign up and relying on it for for big features is also a big challenge for us.

26:20 - 26:25
And there is always a big challenge we always have every year, so maybe if you ask me in 5 years,

26:25 - 26:26
I will always say the same.

26:26 - 26:28
It's about the build process of the project.

26:29 - 26:31
So how the project is being built and so on.

26:31 - 26:35
We always try to improve this, but we will always also try to improve this. It will never stop.

26:35 - 26:36
It will always have issues.

26:36 - 26:40
So those are, I think, the main three, things.

26:41 - 26:48
Thanks for sharing. And the last question that I wanted to ask and ask all of my guests, I wonder,

26:49 - 26:56
can you recommend any books, resources, conferences, podcasts, or some trials that were particularly

26:56 - 27:00
helpful to you as a particular that helped you and can shape you.

27:01 - 27:04
Yeah. Of course. So I would start first with, podcasts.

27:04 - 27:07
There is a very nice one called Better Tech Leadership.

27:10 - 27:12
Anyhow, you're Thanks for that.

27:12 - 27:13
I will use it on a website.

27:13 - 27:15
I will use it on a website.

27:17 - 27:24
Otherwise, for yeah. For other podcasts, there is, the prime time is, of course, good as well.

27:26 - 27:29
I don't, to be honest, listen to many podcasts.

27:29 - 27:34
I know about yours, like, before we, we contacted each other from Jan.

27:35 - 27:37
So that's why I became interested. I wanted to hear.

27:37 - 27:41
I like the talk and so on, so I wanted to listen to more interviews.

27:41 - 27:44
The prime time is also great, but those are the only 2.

27:45 - 27:54
For box, I mean, for bigger vision about software engineering and company and, how to build

27:54 - 28:00
lean software and DevOps and so on. I like Accelerate book. It's very, highly recommended.

28:00 - 28:04
It's called Accelerate, the sign of, Lean Software and DevOps.

28:06 - 28:12
There is one book that I think it's one of the top I have ever read, 5 Dysfunctions of a Team.

28:13 - 28:14
I really love this book so much.

28:14 - 28:16
I love I love it. I love the story.

28:16 - 28:17
I love how it's written.

28:19 - 28:23
It's really very inspiring in my opinion because you always feel these,

28:26 - 28:32
values, but you don't know that it's a common thing across all teams.

28:33 - 28:39
It it's kind it's very, very important in my opinion, to be read, for anybody who wanna step

28:39 - 28:43
up, to learn more about the team and how team work and how to build better team.

28:44 - 28:47
Unfortunately, there are not lots of box for staff engineering.

28:47 - 28:50
There are lots of box for engineering management management track.

28:51 - 28:56
So that's why the staff engineer book is called the staff engineers path because I say it's

28:56 - 29:03
one of the first one, and the other one is thus called staff engineer. So it's that easy.

29:04 - 29:11
Those were were also important to learn from other aspects, how staff engineer or staff plus,

29:11 - 29:12
staff principal, and so on.

29:13 - 29:17
How it works in other companies, in big companies, and so on. What does it mean?

29:17 - 29:22
What are the tracks different tracks for being staff, different, styles of being staff, and so on?

29:22 - 29:24
So, it was very, very helpful to me.

29:25 - 29:28
So, yeah, I think, those are on top of my mind.

29:29 - 29:34
Great. Thank you very much, Mohammed, and this was my last question.

29:34 - 29:37
You gave Amara a great answer, so thanks for that.

29:39 - 29:45
And I really appreciate your time, and I wish you a great weekend. You too. Enjoy. Thank you.

29:47 - 29:52
Follow Matt on LinkedIn and subscribe to the Better Tech Leadership newsletter.

‍