‘How to set the right foundation for engineering teams?’ with Gregor Ojstersek, CTO at Zorion

Kshitij: Hello everyone. I’m Mohan your host back with a new episode of Beyond the Code by Typo. Today we have a very special guest with us, Greg. 

Greg is an engineering leader, has had almost 10+ years of engineering experience across the startups. Today, he works as a CTO at Zorion, Singapore. The best part, he’s highly passionate about sharing his knowledge, his experiences, and runs his own newsletter, engineering leadership.

Welcome Gregor to the show. Thank you for being here. 

Greg: Thanks a lot for having me. I’m excited for this. 

Kshitij: Perfect. Thank you Gregor. So Gregor, given your kind of experience and your expertise today, we would love to talk about how to set the right foundations for engineering teams. And when we talk about foundation, I guess the first aspect always is hiring.

We would love to understand from your experiences that what’s the right set of assessments, challenges, what do you think are the right ways? In order to hire right. Engineer into a team. Your thoughts on that, Greg? 

Greg: Yeah. Creating a good hiring process is always, a work in progress, right?

It’s never going to be okay, we reset it like this and then it’s always going to work, right? It’s always about putting something in place and learn from it and adjust it and, try to make it better.  I have a good kind of a process now that I’ve been interviewing more than about, let’s say more than 200 engineers in general.

And, what works really well for me is to have, for example, a first kind of initial call with engineers that, for example, does like a recruiter, or hiring manager.  And, just to check if there’s an overall fit right? For us. On the both sides… And then once, once we have that,  we move to, a hiring manager interview.

And that’s where I like to talk about all kinds of things in terms of soft skills, and technical skills as well. Behaviors and things like that. And, once we have that, obviously technical assessment is, where it’s, where we can stop a little bit more and we can talk about, some fine details there.

And because I think, if technical assessment is done correctly, it’s really a good kind of indicator of how successful is the candidate going to be in a particular job. Right? And I always suggest to do a great preparation for a technical interview, that means that you need to understand what kind of skills are you looking for and what kind of aspects of the role do you want to do, they want to fill. Right. And I always suggest creating a scorecard before doing a technical interview. And, don’t just put there any kind of technical skills, but also some soft skills as well skills like collaboration. Is a person team player? Is a person keen to take ownership in general, right? Those are really important aspects of an engineer as well. And once we have that,  it’s good to understand what type of technical interview you wish to do. I prefer myself personally, I prefer to ask a lot of open-ended questions.

And then, we drill down to find details later on. Things like, Hey, what have you worked on a previous project? What task was the most, and the hardest task that you worked on a previous project? And then we talk about it and then we drill down to find details on certain queries, certain endpoints, and things like that, that tells me, like gives me a lot of insights of,  what is the thinking process of a particular engineer. Right? And, if in case you need to do any kind of coding tasks on a technical interview. I found out that, we all know in bigger companies like all of the main companies, they do algorithmic interviews, right? That’s the best way to go with the technical interview. And that’s because, in most jobs that we do, we don’t actually work on algorithms on a daily basis. Right. So I would try to suggest if you need to do like a coding task like we would give a simpler task and we would ask a lot of follow-up questions on that particular task. And in order to make it more collaborative, not just, okay, hey, here’s a task, you have 20 minutes to solve it. Okay, here’s the solution. If you believe it or not, you know, it’s not that much important that the candidate actually solved the task a hundred percent. But what’s more important for me is that the candidate is asking a lot of clarifying questions. He’s trying to understand the expectations and trying to assess different options and not just immediately trying to jump in the implementations. Those kinds of things, I value quite a lot.

Kshitij: Basically, approach is more important than the actual outcome.

Greg: Yeah, exactly.  

Kshitij: Perfect. And like when you talked about this process, right? So I could hear that there is a very clear indicator that soft skills also are an important aspect to do that. And it’s always tough to actually, gorge the right set of soft skills. Right? So any specific practices on that, how you have been doing so? 

Greg: Yeah. As I mentioned, things like responsibility and ownership and teamwork and team mentality, and helping others. Those things are really important. And whenever you’re having an interview, you try to assess that kind of a previous experience if the person has shown that experience in some previous roles or previous projects. That’s why we like to talk about what was your role in the project. What did you do here? How did you help the team? How did you help others? Did you mentor any of the engineers? Did you do onboarding as well, did you do any kind of presentations to share your knowledge with others? Things like that are really helpful to trying to assess and overall, how does a personal approach to problem-solving? Do they immediately just jump to implementation or they’re trying to really understand what is the pain point behind it? What is the business value that we are actually trying to resolve here, those kinds of things we need to always keep in mind.

Technical skills can be learned quite fast, especially in a good environment. But, being a good person to work with and a good teammate, those skills are a lot harder to learn.

Kshitij: Perfect. Makes sense Greg! Moving forward Gregor, so you have always been an advocate of remote work, right? And you yourself have been working remotely for so long. So this is what the biggest question that has always been running around is, right, how do you get developers give the right onboarding experience to them, especially while working remote? How do you help them assimilate in the team, get the right info, set up things in? So any thoughts on that, Greg? 

Greg: Yeah. In remote work, you’re trying to get better at it. I think we’re still not there yet where we can have a fully-fledged process that well in place. For a successful remote work. But, it’s important that we strive towards getting better at it all the time. You know, for any kind of onboardings, it’s really important to have good documentation in place.  And, what I really like to do is if we bring a new engineer to the team, I like to appoint an onboarding buddy, one or potentially two. And they would really be helping that engineer, in general, to get onboarded – a lot easier, a lot faster. Because, if you’re starting and joining a company, you don’t potentially know a lot of people. And if you already have one person that you can go to and that any kind of questions, yeah, I can just ask and learn about a lot of different things from that person, right? So, yeah, documentation, onboarding buddy, and also, good processes in place in terms of like a daily meeting. And, I try to focus a lot more on goals and not so much on tasks and details. That means what we try to do is to create sprint goals. And that is two weekly or weekly sprint goals. And, that means that we are all trying to focus on delivering these goals after the end of the sprint, right? So it’s not about the details of particular tasks, but hey, I know we are all professionals here. I know we are all great engineers. We all love what we do. You know, results are what matters and if you define the outcomes that should be successful, then, you don’t need to go in details in every task in order to make sure that everything is going according correctly, especially in a remote environment, right? You’re not working with people directly and you don’t have a person by your side all the time, right? And the best way is to define goals and hold people accountable, define ownership, define responsibility. And, people are going to do well if they’re assigned ownership and they take ownership themselves and they try to do the best job as possible. Often times you get surprised on how well do they actually perform doing that.

Kshitij: Basically empower them more, and they’ll definitely perform the way even much more than your expectations.

Greg: Yes, exactly. 

Kshitij: Perfect. And Greg, Are you completely relying on Slack as a communication channel or any other channels that you feel are really effective in communicating across teams?

Greg: Yeah, we use Slack a lot. And Slack is obviously probably the number one go-to tool for any remote company. And, yeah, it’s good to do some automations on Slack in terms of like,  let’s try to put some action items, for our daily meeting. What could be done? What are we trying to do? And so on. Also tools, for example, What works really good, for me in a lot of, different examples was collaboration tools such as Miro or Figma. Right? And, that works really well because you can do collaboration on these tools together, like a brainstorming session or a good pros and cons list altogether. Everyone jumps on this tool and, we’re collaborating on it and we all are able to put things in there. Right. So it’s really good to proactively do it together as a team to brainstorm ideas, to define pros and cons. Maybe we try to define a technical specification or a design decision together on this. So yeah, mirror or Figma, those tools are really important. And obviously, any kind of video meetings or any kind of tools where you can jump on a call anytime are really great. I’m a big advocate for having a camera on and not just jumping on a call because it feels a lot more personal. And, I feel like I’m connecting a lot better with people when I actually see them.  If you’re just, speaking about things and just talking without a camera, then it’s similar like being on a phone, right?

But you don’t get to see any kind of nonverbal communication, right? But you get to see a lot of nonverbal communication from being on a camera and, it’s a lot better way to get to know people a little bit more. 

Kshitij: Let’s share raw emotions, basically.

Greg: Yeah. 

Kshitij: Perfect. And, while building all this, so there is always an important aspect of culture, right? How do you set the right cultural practices even when you are not together? It’s so important to ensure that everyone stays together, aligned, follow the right set of values. I think that’s the biggest challenge.

How do you cater to that in these remote scenes today?

Greg: Yeah, it all starts with the mindset of the team and, you know, having people in the team that understands that software development is a team sport and only great teams build great software. That’s really important to understand. When speaking about mentality, I always like to have driven and motivated people that always like to learn new things. That kind of mindset is contagious and everyone benefits from it, right? Understanding that software development is a constant evolving industry and that we all need to learn is obviously a great mindset to have. And then,  it’s important to understand for great teams. Great teams are autonomous. They don’t need or want to be micromanagement. They don’t want micromanagement, therefore, they’re not afraid to take ownership and responsibility of their tasks. And, customer is at its core of what they’re focusing on. Great teams should always think of ways of how to find out what the customer wants, and then prototype and deliver the functionalities that customer needs.

Kshitij: Sure Greg.  I think while building remote teams, there is always an important talk about how do you set the right culture,  when people are not together, working remotely. So there is always a concern on how do you set the right cultural practices so that everyone’s aligned with common set of values, collaborate better. Any thoughts on that? Greg? How do you set these culture practices right? 

Greg: Yeah. It all starts with the mindset of the team and having the people in the team that understands that software development is a team sport. And, only great teams build great software. And, when speaking about mentality, I always like to have driven and motivated people that always like to learn new things.

That kind of mindset is very contagious. Right. And, everyone benefits from it. And,  understanding that software development is a constant evolving industry. And that, we all need to learn is a great mindset to have.  And,  then it’s important to understand that the great teams are autonomous, right? They don’t want to be micromanagement.  Therefore,  they’re not afraid to take ownership and responsibility of their tasks.  And also customers always on their minds. Customers is at its core of what they’re focusing on.

And, great teams should always think of ways of how to find out what customer wants and then prototype and deliver the functionalities that customer actually needs. Another thing that, I found out is that for individuals to focus solely just on their task, that does not do well in a great team. Great teams are always trying to help each other in making sure that if someone is stuck, others are there to support.  And, good teams also enjoy doing things like pair programming, more programming because first of all, it’s fun. Second of all, you can resolve problems a lot faster doing it this way. And at the same time, you also focus just on that particular task.  And, especially like if you have any juniors on the team doing kind of any pair programming is really a good way to onboard or just share knowledge with a more junior engineer in general.

And,  the last thing, what I would say regarding this is that we as engineers,  we are here to provide as much business value as possible to the company, that is our focus why we are here. Therefore focusing on that how to provide that value should be the number one motivation for a great team. Not just focus on building great technical solutions, but finding out,  what pain points does a business have and how we as a team can resolve some of this pain points. That’s really what is really important for a great team.

Kshitij: Fair point! I think in the end, we are all trying to serve to our customers. So business impact is what matters the most. I think, one question here Greg, so I think the biggest challenge is how do you keep on imparting this thought process right back and forth again and again to the team members, any specific processes that you have been following that, Hey, you know, let’s just stick to what the common goal is.

Greg: Yeah. We talked a little bit about sprint goals, but also I think, what is really important here is to, me as a manager, it’s important for me to have one-on-one meetings with my reports that means, and engineers, right? And, it’s important to make sure that, we always are trying to focus on these values, right? And whenever we see that potentially, like someone is maybe doing something differently or is not focusing on these values, you know, you need to give feedback as soon as possible to that particular engineer. 99% of the times engineers is going to really appreciate giving that feedback because it’s not only for him or her to get to do better on the job, but also they grow a lot more as an engineers. If they’re focusing on these values, because a lot of times people don’t actually understand what do they need to do in order to be successful in a position, right? Whenever someone starts, you need to set the expectations correctly, like hey, these are our core values, is that we’re following, and things like that. And then you need to assess and need to give constant feedback on. I love to give feedback on one-to-one meetings. I don’t like to wait for performance review meetings. We should give them more frequently. It’s a lot better than less frequently. 

Kshitij: Perfect. Greg, this is really insightful. I think just one last thing that we all viewers, as we would love to hear from you. So what’s that, Gregor’s magic sauce or what’s that Gregor’s advice to the leaders to learn how to help their members shape their right career path?

So they go more towards the, EM focus, the management part, or they’re more aligned towards the tech, the architect part. Your thoughts on that, Greg?

Greg: Yeah. That is the number one hot topic when I’m talking with any of the engineers and, there’s a lot of uncertainty like we just, which is the direction that a certain engineer wants to grow and that’s perfectly fine, right?

And what I suggest to engineering leaders, it’s really important to have conversations with engineers and talk about their career progression in general and, try to give them options in which direction they wish to grow, give them more insights and, they should be discussed frequently on one-to-one meetings. And, a manager should provide different options. And,  an engineer should try to put themselves in that particular position and see how they would actually see themselves in that position.

What I like to see here as well is that engineers also show their motivation and drive and already do like a research. Particular roles and different paths ahead of time. So they already show I’m motivated and driven. I wish to grow. I wish to progress as an engineer. I wish to move to another path.

Hey,  what do you suggest? And then, the conversation is a lot better and a lot easier when the engineer actually shows the motivation and drive. You already know that engineer is willing to grow. And it’s a lot easier to help that person. 

Kshitij: Definitely. But I think, it would be more tough for, from an engineer aspect, hey,  what could be that right path for me? I think that’s always a yeah. And right. So any specific thoughts on how I, as an engineer gets to evaluate myself better? 

Greg: Yeah.  That, that’s a good point. I’m a big fan of trying and see how it goes.

I like to say trying is the best way of knowing, right? If you don’t try, you don’t know how it actually feels. What does it feel for you? In general. And, does this work actually fulfill you?  I would suggest for every engineering leader to provide like opportunities for engineers to take on a role like a manager or architect for at least some time to see how it feels if they enjoy it in general. Right. 

For example, would be like a give an engineer like a week or two to be a team lead for that particular team and,  just see how it feels for you and, maybe for an architecture path,  maybe give an assignment to an engineer to create a design specification that would be focused on a particular functionality.

That’s how an engineer can actually see how does it feel to actually be doing the work of an architect, obviously. Put some mentorship in place and give some guidance for maybe a more senior person that would be really and you mentioned that engineers don’t know yet in which direction to grow most of the time.

That’s also been one of my findings as well. And what I always like to suggest is that if you don’t know in which direction to grow, focus on leadership skills because in every path you are going to grow, leadership skills are going to be needed. And the reason for this is that, the more you grow, the biggest impact they have on the organization and, on the business in general. And, you can’t have a big impact without having good leadership skills. 

Kshitij: Perfect. Greg, this is insightful.

Thank you so much for your time today. It was an amazing conversation with you.  We would love to keep on supporting you in this entire journey of helping managers, leaders be better at their work. So thank you so much, Greg. Thank you for being with us. 

Greg: Thank you for having me.