10% engineering. I expected a lot more engineers.
It really drives us to be efficient and productive, not
allowing everyone to choose their own database.
Not every technology should be incorporated in our products.
We have a four day work week, 3 days off the floor.
You're on the office. There's no room to discuss that.
This is what we're going to do. If you win the job in, if you
start over, I want to do Scrum and I have to introduce it
everywhere where I come. That's kind of a red flag.
You don't know what you're stepping into.
Engineering Culture is one of my favorite topics, and I'm
especially interested in how engineering can contribute to a
company and its success. That's exactly what we discussed
today. Joining me is Mikhil Ofrem,
Engineering Manager over at AFOS, and he shares what goes on
behind the scenes. The company that has millions of
revenue, thousands of customers, and a relatively small
engineering team, about 70 people, actually a lot less than
I expected. He shares what makes a team
successful, what great engineering looks like at Afos,
and what the mindset is of great engineers as well.
So enjoy. I did a bit of research into
AFOS specifically, and I was actually really surprised.
Like I know you and you and I spoke before the show, but then
I did my research and AFOS has hundreds of millions in revenue.
It has thousands of customers, about a little bit over 700
people, and 10% of that is engineering.
And from my outside perspective, I'm like, OK, software company,
software is bread and butter, but the staff is like 10%
engineering. I expected a lot more engineers.
Like I have no clue what you do with the engineers that you
have. How do you do what?
Yeah. That's really interesting
because at at on one side I'm always asking for more and we
should be bigger. Otherwise it really drives us to
be efficient and productive and make hard choices in what to
invest in what not. So one of the things that I
think is fundamental to Afos core values is working in
standards. So what we've done over the past
years always is create standardised ways of creating
our software and focusing on that.
So not allowing everyone to choose their own database.
Not every technology should be incorporated in our products.
Let's focus on what we have and how we built and focus on the
value that we can deliver to customers.
Got you. I value freedom and autonomy.
Does that mean if I would work at office I would have less
freedom and autonomy on the technology side or?
And it's a really interesting question because what I've
experienced over the years is that there is freedom, but that
freedom comes with a responsibility and a balance in
learning how AFAS works, functions and where it gives
something extra. So we introduce new things like
a Securus architecture of a single page app framework.
We did that over the past, but always in such a way that we saw
the vision of, OK, this can be the next standardized thing that
we do. So let's invest and go that way
and see where it brings us, but then focus on it.
So not every week a different framework or every year a new
architecture. Let's go for this one and see
how far it can brings us and apply it at as much places where
we can. Interesting.
And the standardization from your perspective is that what
really allows you to do more with a smaller team of
engineers? Yeah, yeah.
Because there are a lot of questions that you don't have to
ask and answer anymore. When new people arrive and we
introduce them to the frameworks that we have and we come up with
a new project to build a new surface, we can just say we have
a framework, we have a front end framework, we have a whole
deployment infrastructure. Let's go with this and then you
can focus on adding value, business logic and what does the
customer need and not on all the other aspects.
Does that also ensure that you have a certain type of engineer?
Because I in my career I've seen two types of engineers.
People that love software engineering for the craft, let
me build a rocket ship even though we don't really need a
rocket ship. And then people and I think I
see myself in there that I, I really don't want to build
anything complex if I don't have to.
Like for me, that's a wasted effort.
I want to understand how the business makes money.
What is my role in there so I can think along and software is
the way I execute? Yeah, Yeah.
I think that you're perfectly right.
And yeah, we see those two engineers within Alphas, the
more technical engineering, craftsmanship kind of people.
We have them also. We need them, but we put them to
work on the architecture, on the patterns, on the frameworks, on
the infrastructure part. And then we have the more
product engineers that like to build something that they can
see, that they can use, that they experience for themselves
and are involved with customers. And we put them in the product
teams. And of course, that creates a
kind of conflict kind of attention on a well, the product
engineers also like technology and how can we make our job
interesting. And on the other side, the more
technical people also have to be aligned with customers and
cannot go on their own and build Rocketship without any use for
it. But it really works those two
roles. Yeah.
So you need both. Yeah, from your perspective,
interesting. And they are not necessarily in
the same teams. They're actually sometimes more
focused with the rest of what they do.
Yeah. In general, we separate them in
teams, but there are teams where that's more of a mix.
But most often we have product teams that are more product
engineering and then we have the more technical teams that work
on back end frameworks and front end frameworks.
Got you. If I were to compare Afos and
still everything from my side is from an outsider's perspective.
But with somethinglikebull.com, I've had guests on and I know
they have thousands of engineers and their teams.
They are responsible of part of a bigger organization because if
you have 2000 engineers, you're not going to be end to end
responsible for any customer journey.
The end to end responsibility is going to be a slew of teams
back-to-back. And I'm wondering if you look at
your teams, how responsible are they or how are they set up in
the 1st place with regards to responsibility?
Well, they are not responsible end to end because there are
things that we separate out in platform teams like an
architectural team or maybe even an infrastructural team.
But they are really tied to the customer because also the
operation is relatively small. So they are really directly
influenced by the customer and its requirements.
So that gives them well really a sense and urgency of
responsibility. Although they aren't responsible
for everything, they feel like they are responsible and they
should drive the solution to its end.
Interesting. I didn't expect you to say they
might not actually be responsible, but because they're
so close to end users in the 1st place and customers, they do
feel that responsibility and I recognize that in what I had.
I don't think I've ever been end to end responsible.
I think it's very rare outside of startup environments.
I mean, if you talk about Alphas, hundreds of employees,
millions of revenue, thousands of customers to be end to end
responsible. But you can have that feeling
where you are responsible. And I feel like the way you do
that, the way you empower engineers specifically, can be
very motivational as well. Yeah, yeah.
We see that with in general, the more effective people are those
that feel responsible, although they aren't, but they will find
people that are responsible for a part that they need and they
will track them down, hunt them down and tell them what they
need and make sure that it happens.
Although they are kind of dependent on them and and the
other people might say, no, we don't going to do this.
We have don't have time, we don't have capacity, but they
still feel responsible and they'll fight for it.
Exactly. Yeah, your role in office has
evolved from hands on to more solution architect and our
engineering manager. Do you miss the more hands on
part or how much hands on are you in the first place?
I I kind of keep hands on by doing some side projects and
tooling and so I I hope that I'm not.
Too rusty? Not too rusty yet, I still have
a chance to to dive in some code, but it's less handsome.
But I do really like the overview of how components
interact with each other and that vision of how to align the
teams to work towards a certain goal.
So as you can imagine, we have well kind of a lot of legacy
code and things that came up 20 years ago and still are running
and how are we going to transform that into a new
architecture and a new platform. And those are always baby steps
and and evolve evolutions of what we have.
But I really like that challenge to getting people on board and
setting a goal and an innovation to work towards something.
What have you seen that makes teams?
Because my assumption is you're overseeing multiple teams as
well as a bigger picture of the organization, so you can see
teams that outperform others or are more effective in what they
do. What is that secret sauce within
a team that makes people effective?
I think the teams that are more effective than others are those
that have the responsibility for their solution, but also feel
the balance between where do we need to fight for new
technology, quality something more and where do we need to
fight to just get a deadline, get a product out to make sure
that people can use it because we have something to deliver.
And that sense of urgency. Responsibility is think I think
really important within Afos because it will always be
product number one. It'll always be product is
first, technology comes after that.
But we also understand and and know that the quality is
important. So if you only say product is
important, then you might losing quality in the long run.
So you have to have the sense of quality and how to do that.
But there are times that we need to rush and we need to make sure
that something happens to keep the customer satisfied.
Do you then see the technology also as your product?
Because you're saying product first.
Yeah, it might be kind of the platform and the features aspect
of things or from a listener's perspective, that's what I would
assume. But I've also said people where
I want to work in a technology first environment, I ask a few
more questions, then it turns out that technology is basically
the product. I, I, I think and I hope that in
the platform teams, we do make sure that they understand that
indeed what they're building is a product for the other teams
and they need to support it and make sure that things happen.
But it's harder to keep that in mind.
Yeah, you can see that. How do you motivate people when
it comes to working within a team?
They are not part of a cock, right?
They're actually having quite a lot of responsibility within
that team specifically. I don't know anything about team
sizes, but I do know a little bit of people management
experience that I've had. And it's very hard to motivate
people if they are either not in their place or they have a lack
of clarity or anything with regards to that.
I think from a a product perspective, we always try to
make sure that people know what we're building for, who we are
we are building and what the end goal is.
So we do that with a lot of customer stories, taking them in
and bringing them in and showing what we're doing and why we're
doing that. Do they do that only from the
product side or are you, for example from engineering all
sources? No, we.
Try to do that for everyone. So also, if you're in a platform
team, you still need to hear what the customers are doing and
why we are doing it. So since next week we have our
internal conference dev days and we always make sure that we
visit companies if we do that and every, every engineer has to
join. Even if you're a platform team,
you will visit the customer and see what they're doing.
And for instance, every month we have our quarterly meetings or
our monthly meetings numbers and stuff like that.
But we also bring in a lot of user and customer stories to
show what they're doing with the software, how the how do they
experience it to show why are we building this product.
How hard is it for you to set that up?
Because I can assume that a lot of listeners don't have any
numbers for their for their company, don't really talk to
customers or don't really go off site to actually see what's
happening with the software they're building.
For instance, a department it's really easy because the monthly
meeting for instance, that's a company wide, yeah.
So the CEO and CFO and the other directors bring in customer
stories. So we don't even really have to
organize that because they already will do that and they
know and then we'll hear stories from consultants and sales and
so on. And often engineering is like,
oh, here we go again. But it's really important that
they hear, hear the stories from customers.
So that's something that's already been solved by company
wide. So for instance, the dev days,
that's really a thing that we have to organise.
We have to find customers and see where we can go on visit.
But in general, our customers are very open and willing to to
tell and show what they're doing.
Yeah, interesting. When it comes to then hiring,
getting new people into Afos you mentioned, there's always a lot
of things to do. We can grow probably faster, but
it is still a team of 70 people. Are you planning on hiring a lot
more or is it actually in a in a good sweet spot as it is right
now? I, I think we're in the future,
we will, we will keep on hiring, but it's not something that we
want to grow from 70 to 90 to 110 in, in, in steps like that.
But we have a continuous flow of hiring that we are doing on the
other. On one end, of course, to make
sure that people that are going away to, we have to keep up and
otherwise we want to grow, but we do it on on the kind of
steady level. Yeah.
And what do you look for in engineers that you are hiring
with regards to the qualities you mentioned a certain sense of
urgency and feeling of responsibility.
What, for example, on the technical side are you looking
for? I think on the technical side,
we're of course you're looking for the things that we are using
OS somebody hasexperiencewith.net or C# or
something like that. But I think the more important
one is do you have a passion for the craftsmanship?
Do you like what what you're doing?
Do you want to build stuff? Do you want to keep on learning?
I think learning is a really important thing because well,
our job is so much in flux and there is always new stuff.
So you want people that are open to learning and are eager to
learn. And I think that's more
important than do you know C# because if you want to learn, C#
is no problem. So I think on the engineering
side, learning is key, the passion and learning and
otherwise on the more product side, we are always looking for
people that are understand that we're building a product and
that we do it for customers and that for another a Research
Institute. We are not a a tech company in
that sense that we just want to build tech for the tech.
We want to build a product and you have to understand that that
drives decisions that we make. Let's start with the technical
side. You mentioned a passion for the
craft and a hunger for knowledge.
If I'm interviewing and you're across from me, how, how do you
see that I have that? Well, we're always looking for
do you have side projects? That's one indicator.
Do you read? Do you listen to podcasts?
Do you do you few movies that kind of stuff and do you talk
about that, that you're learning a goal on the side or that
you're involved with Rust or something like that and might
not even be interesting for us, but the fact that you mentioned
that you're doing that, that's really a good indicator.
Yeah, I can see that. The side projects are something
that I think throughout episodes are something that people have
noted. Find a passion doesn't
necessarily matter what it is, right?
It could be sports, anime, movies, crafts, whatever.
And create a site project out of that because that's something
tangible that you can show that you've done.
And although you don't have potentially any production
experience in the company you're applying for by virtue of having
done that step. I also see people that interview
and that say, I think this is a good opportunity for me.
And when I come in, I'm going to do XY and Z, but then they
haven't actually started yet. So then I'm like, this is kind
of a weird conversation here because I just have to trust
you. Indeed, if you want to have that
opportunity, start the show that you're doing that.
Exactly. And then what on the product
side makes you think people are really good for specifically a
product engineering role? So one of the things that is
kind of a an indicator that you're not a fit is if you win a
job and if you start over, oh, and I want to do scrum and I
have to introduce it or, or I do this XYC at this company and I
have to introduce it everywhere where I come.
That's kind of a red flag. And I'm thinking why you don't
know what you're stepping into and you have first have to learn
before you can start with doing suggestions and stuff like that.
So understanding that we are that we have customers and that
we have deadlines and that you have to sometimes work against
the deadline, that's really important, yeah.
Can you share a little bit more about the inner operations of a
team with regards to the way of working?
So how big is a team? How do they work, how they
operate? Do they demo every other week
or? So what we for the, the bigger
project, project that we have, we have 2 releases in a year.
So that's kind of conservative you could say.
We have a general planning for those versions that start with
product management, with market research, customer requirements,
stuff like that. Then there follows a list of
projects, features that we want to build.
Those are dropped into the right teams.
A-Team can generally be quite large, like 15 people, but in
general those are also. Then we are split in sub teams
where a project can be done by 1 developer and one designer in
the list, maybe 2 developers if one is more junior than the
other one. So the projects themselves are
built with relatively few developers, but they're part of
a larger team. So they can ask, always ask for
guidance or help from other people that also know their
specific components and set of features.
But they developed them in their own.
And in general, they start demoing when they're almost
done. And most teams don't really work
with iterations. So some teams have weekly
meetings to keep on track, other ones do that biweekly.
That's kind of team specific. OK.
And they also have the autonomy to decide what works for them
within that team. Yeah, interesting.
What I've seen in many organizations that have been in
Scrum is like bread and butter. If you're not doing Scrum,
you're trying to do Scrum. And then the engineers, because
it's not really Scrum, they're like, yeah, we're kind of agile.
And there's this negativity around it.
And I'm quite surprised that you're saying teams are
autonomous. They do whatever works for them.
We have a big team. Like if you're looking at agile
and like that's the the stretch of the maximum size of team
people within a team and then they have sub teams and they
execute and that's it. It sounds quite simple.
Yeah, I think we try to keep it really simple.
So we've experimented with Scrum.
We also have people in the teams that really like Scrum and want
us to do do that. But what we've learned is that
there's a lot of ceremony that really doesn't fit what we're
doing. So for instance, the whole we
have two versions in a year. Well then that your Sprint
planning. It's kind of limited because you
already know what you're doing for this version.
So the Sprint planning is then only a follow up in meeting to
show that we're on track, that we're doing the right things,
but we already know what we're doing.
So we try to do that in that sense.
So it's kind of agile within that road map, but we don't
really like the ceremony before that.
And also the daily stand ups. Well, we've learned that doing a
daily stand up with 15 people is not really useful because you
get a lot of chatter and it always takes longer and there's
really not much information in in that sense.
So what we try to do is enforce people that work together on one
project. Do the stand up with you, do it
with three, do it with two. And then you don't really need a
stand up because you're sitting next to each other.
So just turn your chair, tell what you're doing, ask what the
other one is doing, and go work. Interesting, like I've seen
companies try and look online with what what type of
information is out there and then try and beat that
organization, but they completely mismatch in the
context for me, very mature organizations, they know who
they are. Like the fact that you're
saying, OK, we have twice a year releases, you can have an
opinion on that, but that that's it.
That's what we have and then your other ways of working kind
of orchestrate and they tailor towards that and it shows
maturity to know who you are and this is what we have and but
probably that has evolved organically as well.
That has evolved, yeah. And it, it's also, it could be
a, a, a danger because we're stuck within what we're doing.
So we try to experiment and the teams kind of walk out of that
structure sometimes just to experience.
What does it do? Does it help us?
So some people are working with more structured daily standups,
but then it kind of dissolves after a while.
Some teams do retrospectives, but they don't do them once
every four weeks or something like that.
But it's really dependent on the team.
So we're trying to get some flexibility in the team, but
limit the the get the structure through the road map and the the
planning of the team, the projects.
Yeah, I mean, you've been at Alphos, It's it's going to be
close to 15 years, right? And you've seen a lot.
Then for me, what my assumption is, is if you have an
organization that's growing and it's growing organically, I've
also seen organizations crash and burn.
And typically it's because leadership either didn't
understand their business or they tried something, it failed
and they didn't want to take ownership and it just spirals
and cost fallacy, etcetera, etcetera.
Is that also how you see it? Has the organization become what
it is due to a strong leadership?
Yeah, I think the the strong leadership within office is
really one of the causes for the growth and the steady growth of
of the organization. How, how do people see that?
And then especially from an engineering side, how can they
see that OK, our, our leadership's actually capable in
what they do. We have trust in them.
So we're going the right way. I think what what Arvos has
shown is that the leadership is willing to make decisions and go
for it. And it's kind of a really
interesting paradoxical situation where there's a lot of
freedom and it looks really well, it's family owned and,
and, and kind of go see and but on the other hand, there's a
strong leadership that tells how we work and how we're going to
do it. So for instance, we have a a
four day work week and with that they've said three days off the
floor, you're on the office, there's no working from home,
there's one day that you can work from home and that's it.
So there's really a strong leadership in we think that this
works. So we're going for it and there
is no room to discuss that. This is what we're going to do.
Yeah, this is it. No, OK, this four day work week,
I actually saw an article, I think it was like yesterday.
Talk to me about that. Is it actually people get paid
five days a week, They work four days a week is as simple.
As that, yeah, that's exactly what it is.
That's not bad. Yeah, that's a pretty good perk.
Yeah, it is. And how long have you been doing
that? Since January this year, so it's
actually the first year that we're doing this.
Gotcha. Any statistics or measurements?
Any upside for people listening? Yeah, well, the upside is the
day off that really gives you a lot of freedom around.
And so we call it induction Entreklebach, a self development
day, you could say. So it's we try to bring it not
as a free day, but as a self development day.
Well, people can do with it what they want.
They can Netflix, they can go do sports, do be with a family, but
they can also take part of the day to listen to podcasts, read
articles, read a book, develop yourself in your craftsmanship,
in whatever you want to be. And that really gives you a lot
of freedom. Because before that was stuff
that you had to do in the evening on Saturday, Sunday, but
then you're also with your family and then you also have
your other stuff to do. And now you have a whole day to
kind of mix. That gotcha.
And from your side, you don't have any expectations on what
people do on those? Days, No.
There's one expectation and that is when the customer calls and
there is shit hitting the fan, then we have to do something.
Be on the ball, yeah, OK. So for instance, what we do is
if you fix a bug and you want to release it on Thursday evening,
that's fine, but then on Friday you're the one that I call.
You're there. Yeah, exactly.
I like that a lot. Where I've seen things go into a
wrong direction is where there is indeed announced you can do
whatever and the people have certain expectations on that
day. And then the people that
actually have that, they're like, whoa, this is this wasn't
part of the deal, right? Because you're saying it's free.
And then all of a sudden I have to do things according to your
expectation. And, and it's, it's something
that we are evolving in this year.
It's really searching how are we going to use this day.
But I can say from my perspective that there is a,
there hasn't been a lot of priorities that that needs to be
fixed and people are willing to do something on their own.
So sometimes there is something they're working on and they want
to dive into something and they have the room to do that on
Friday without discussing, oh, is this the right thing to do
right now? Or are there more urgent stuff
to do If the freedom to just dive in it, experience,
experiment, come up with solutions that we might have not
thought about, stuff like that? Gotcha.
Yeah. As a last thought, I was
wondering, there's a lot of tooling nowadays, especially
with AI. How have people kind of embraced
tooling or how do you distribute and make available certain tools
for people to experiment with? So we we are a Microsoft shop,
so we have Visual Studio, the the old DevOps suite and so on.
And I think last year we started using Copilot.
So everyone has a Copilot license and we try to organise
knowledge sharing hackathons to get people involved with
Copilot. So you can you see that there
are people that are just curious and want to experiment and and
go all in. And there are people that think
it's a tool, it doesn't really match how I work.
So they don't really use it. And those are the people that we
try to inspire by giving examples, by organizing A
hackathon or knowledge sharing to get them on board.
Scotch everything revolves kind of around sharing your
learnings. I feel like to make other people
excited and people that have a passion for this thing, they
would also love sharing. Look at this cool thing that
this thing does, or we've tried this thing and this is how it
works and this is actually what it's really bad at.
So we dropped this. I've seen that go organically,
but especially when it's organized and orchestrated, it's
very powerful. Yeah, exactly that.
Yeah, as a last piece of advice, there's many engineers
listening. They want to grow as fast as
possible, either in their career or in their craft.
Is there a piece of advice you want to give them to kind of
close off the episode? I would advise you to stay close
to what you like and what your passion is and just dive in as
deep as you can. Just put your energy into what
you like and what your passion is and that will be picked up by
people around you and that will give you opportunities that you
didn't thought about that helped you grow.
Awesome. Thanks so much man.
Welcome. Awesome.
We're going to round it off. If you're here with us, let us
know in the comments section what you've thought of this
episode, and otherwise we'll see you in the next one.