How We Get More Done with Fewer Engineers

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.