79: Balancing Managerial and Technical Responsibilities with Anand Safi of Mark43

Not all software engineers want to become engineering managers. Anand Safi is an Engineering Manager at Mark43, and while his career journey from software engineer to software manager was rather intentional, he joins the show to chat about other options for promoting your best engineers. He also shares how Toastmasters helped him become a more empathetic speaker, how to deal with non-technical bosses, and how companies can keep their metaphorical plates spinning while adding more.

In this episode, you will learn:

• Tips for building software with uptime requirements that have life-altering consequences
• How to balance managerial and technical responsibilities as an engineering manager
• How to deal with non-technical bosses who are detached from the day-to-day of those they lead
• How a program like Toastmasters can help engineers speak about their technical work in a non-technical fashion
• How companies can promote engineers without forcing them to be managers
• The difference in skill set between creators and enablers
• How to fuel innovation while sustaining your current environment
• What dual-track agile is
• The benefits of cancelling routine meetings for a week to host a team hackathon

This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.

Recorded April 15, 2021 | Edited by Jordan Daoust | Produced by Jenny Karkowski

Show Links

Anand Safi on LinkedIn

Mark43’s website

Toastmasters International website

Mentor Cruise website

PlatoHQ website

Episode Transcript:

Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at what it takes to build and grow digital products. I'm Tim Bornholdt. Let's get nerdy.

A quick note before we get into this week's episode. We at The Jed Mahonis Group have a lot of fun projects coming in the door. And as a result, we're looking to expand our team. We're looking to hire an Android developer. So we at JMG place an emphasis on hiring for fit as opposed to skills. Skills are something that can be taught and fostered through mentorship and experience. Fit, on the other hand, it's a lot harder to define. But we've outlined some of the traits we're looking for on our careers page. It's over at jmg.mn/careers. So whether you have one year of experience or 20 years of experience, it doesn't really matter. If you're interested in talking and or working with us, please reach out at careers@jmg.mn. We'll put that email address and a link to our careers page in the show notes as well.

Today we are chatting with Anand Safi. Anand is an engineering manager for Mark43, a public safety software company. Anand's career journey from software engineer to software manager was rather intentional. But for many software engineers, they don't want to become managers. So in this podcast, we talk about other options for promoting your best engineers, as well as how Toastmasters helped him become a more empathetic speaker, how to deal with non-technical bosses, that might be you, dear listener, and how to juggle innovation with maintaining what you've already got. So without further ado, here is my interview with Anand Safi.

Anand, welcome to the show.

Anand Safi 1:57
Thank you, Tim, for having me. Really excited to be here.

Tim Bornholdt 2:00
Yeah, I'm really excited to have you here as well. I'd love for you to take a chance to introduce yourself and what you do at Mark43 and just talk about everything that's led you to this wonderful podcast interview we're about to have.

Anand Safi 2:13
Yeah, thank you for giving me the opportunity, as I said, so I am Anand Safi. I currently am an engineering manager at Mark43. For those of you who are not aware, Mark43 is a public safety SaaS company. So we have some of the world's most powerful software, which is to empower communities and their governments with new technologies and solutions that would improve the safety and quality of life for all. So basically, we have a 911 dispatch solutions to record management solutions and just more products that would kind of just make our community safer, and just improve the quality of life.

Along with my role of being an engineering manager, I'm also involved in the tech community in various forums. I do mentorship and coaching for engineering leaders, and also for new and aspiring engineers, through a couple of platforms. And then I'm also a startup advisor for a couple of pre-seed, Angel round companies. And just along with being present in the tech community, that's when I came across this wonderful podcast with Constant Variables. And I thought it would be amazing to just come on the show and have a chat with Tim, and share about my experience and see what comes out of it.

Tim Bornholdt 3:41
You're too kind. I am really curious, as I've never spoken to somebody who works on software for like the 911, or like the public safety sector, so could you talk a little bit about like, are there any unique challenges or anything that you face dealing with software that could potentially have life altering consequences if things don't work the right way?

Anand Safi 4:10
Yeah, I think you put it really well. They're life altering consequences. That is exactly kind of the top thing on our mind at Mark43, that is security uptime and then also accuracy. So a huge part of our CAD software, for example, the 911 dispatch, is the location accuracy for our first responders, when they're responding to an event, actually. The other thing is the uptime, and also making sure that the more quality software is able to keep up with the demands at peak times for the dispatchers actually. So that is a core area of focus for us. That along with product initiatives. Te put a huge huge focus on the tech in those initiatives, and also trying to make sure that we are innovating and coming up with new ways to just make this secure and scalable and robust, because, as I said, like this has a fundamental impact on our communities.

Tim Bornholdt 5:16
Yeah, totally. Just any time when you're working with software like that that has up time requirements, I'm sure that there's extra lengths that you go to. Is there any tips or any advice? Like because I know uptime and security and things like all apps, obviously, you need to be secure and have a high availability. But is there any, like if I'm in the shoes of somebody that's non technical and I'm trying to figure out like, how do I build a technical team that's going to focus on those things? Do you have any tips of what to look for? Or what kind of software? Or what kind of just mindset that your development team should be in when you have that kind of a need?

Anand Safi 6:01
Yeah, I think that that's a really interesting question. Thanks for bringing that up. I think related to what some some folks could do, and a mixture of what we currently do is, I would say two things. First, be as much close to your customer or your target user as possible. So we have some wonderful relationships and partnerships with the police agencies and government agencies that we work with, or that are our customers. So trying to get feedback or trying to understand their workflows, in terms of what is necessary too, like, absolutely core workflow that they need, and making sure that those have the right tracking, the right kind of metrics, and the kind of monitoring setup is key, actually.

And then the second is also establishing internal SLA's and just goals for your own engineering practice and team that you should strive to meet and then try to work backwards. So trying to see what the current gaps are and potential improvements and performance gains that could be made. And then trying to focus initiatives along those SLA is that you feel comfortable and proud of and then are also kind of working in favor of the customer that you're catering the solution to.

Tim Bornholdt 7:21
Right, those are really good pieces of advice if you're trying to be building software in that same space, I think those are two really great tips to take away. As an engineering manager, you obviously have a lot of commitments between being a manager, but also, you know, I assume you're doing some technical work, still engineering of some sort. So how do you balance those two commitments that you have within your company?

Anand Safi 7:47
Yeah, I think that is kind of a constant challenge for any engineering manager, especially for those who come from an engineering background or who want to continue to stay technical. Because you have this new or added people management or kind of non technical responsibilities that are equally important, actually. So there is a balancing act that needs to happen. And I think there's just a lot of great approaches that people have taken. But I think what I can say is, it differs from company to company, roll to roll, and if I may even, team to team based on what you're working on, what your ideal team setup is. And there are a mix of people that would kind of just, I would say, guide on how much manager versus makers time you would have.

So for my particular role, and my experience, currently at Mark43, it rolls around wearing many hats. So while my primary goal is definitely to kind of be that engineering lead on the projects that I manage, and make sure that they are progressing from a technical standpoint, but equally, it also means that I need to be a strong advocate of my team, any considerations for work life balance, trying to not cause any burnout, and trying to just reasonably set expectations from the get go. That also means that I have to spend time doing rigorous planning and strategy work from the technical roadmap standpoint with my leadership and other stakeholders. So I closely collaborate with the product and design team in that regard. So the role keeps on getting fragmented in terms of time commitments, it's, I think, a mix of three to four core commitments in that regard.

But to your point that I still need to stay technical at the end of the day, and personally how I achieve it is with a mix of a few things. So I don't have that luxury most days where I could say, this is my afternoon blocked and for the next three or four hours, I will just be heads down time coding. I probably get segments of 30 to 45 minutes or pockets of time throughout the day or week. So during that time I do peer reviews as much as I can to see what code is going out, are we following the best practices that we have set up as an engineering organization. I do the engineering huddle meetings with my team of engineers. So trying to make sure that we are all on the same page and just kind of working towards the same goal. And I also take active part in architecture discussions or any brainstorming sessions actually. Along with that, I would love to also do some amount of coding that is either in the form of really small feature development or bug fixes, but not taking on large refactors or large feature development. Because given my time commitments, and the fact that I might spread too thin on multiple things, I don't want to end up being a bottleneck for the team's progress.

Tim Bornholdt 11:04
I can 100% relate to that feeling of like, you still want to be able to jump in and help out with the code and do some reviews. And I totally understand that. And then you know, from the other side, you also have to make sure that stuff is actually getting out the door. One thought that I had going through my head while you were explaining that was just thinking of the kind of listener that listens to this podcast is typically not a technical person, but might actually be managing technical people. And I wonder what advice you would have, for example, like if you had a new boss that came in to your work, and wasn't technical, but had all these lofty expectations of you for being both a manager of people, but also a manager of the product and the technical side of things. How would you approach a boss that comes to you and doesn't really understand what you do and trying to help get your time set up? Like, how would you wrap your mind around that for somebody else?

Anand Safi 12:05
Yeah, I think that's such an excellent question. That is the kind of most practical situation that most teams face. But as you go higher up in the leadership, they're probably more and more detached to the day to day problems or the happenings at a team level or at the code level. And there are big initiatives that we want to make happen. But sometimes the team is just not set up to deliver in the timeframe or the fashion that is expected. So the ways I have dealt with that is just early on in the role or like any new team or project that you take up, just do spend the time to establish relationships and trust with the people that either you will be managing, or whom you would be sharing information or reporting to. That will help us be on the same page in terms of just what are reasonable expectations, and what is kind of your guiding light in terms of who should be the decision maker. What I mean by that is, the fact that you lead technical people does not mean that you are the technical lead for that team, actually. There's a clear distinction between managing the team versus managing systems and technical architecture. So I think I would still very much want the most senior engineer or a group of senior engineers on the team or project to be those tech leads or the acting tech lead that will provide me key input. And I will heavily heavily rely on them to make a decision versus just because I was managing the team, whatever I feel, or I have just an assumption based on my past experience should be the way forward actually. So the fact that somebody else is a lead from a systems and technologies standpoint should be okay for you. And that will help move the team quicker versus you thinking that just because you manage a team, you also manage the engineering decisions as a part of that team.

Tim Bornholdt 14:13
Yeah, it's so hard, like, technology in general is so confusing to so many people and having somebody like you, you know, there in a position where you can kind of be like a Rosetta Stone, for lack of a better term, of somebody who can translate from what's happening and what needs to happen from a business standpoint, but what is possible from a technology standpoint. You're often in this kind of perilous situation where you you're not exactly friends with anyone because you kind of have to make both sides upset from time to time. So I think that the point that you made about establishing good relationships and just having that ability to be open and honest and garner some empathy from both sides so that it's not... It so often becomes this adversarial us versus them, you know, the upper management versus the technology providers. And it doesn't need to be that way. I think just like you said, establishing some clear communication and making sure that you know who's in charge and where the buck stops at the end of the day, those are really great points for, you know, making sure that your team is on the right track to achieving business goals and getting the job done.

Anand Safi 15:26
Yeah. And now that you say it that way, I just wanted to add one more thing. I think an easier way to just approach it would be, say, the roadmap and the vision is top down, if we may, in that sounds like the strategy and the vision setting on what we need to do is probably more top down where you can rely on your management and leadership. But in terms of how we do it, and what is a reasonable timeframe, in terms of technical feasibility and delivery, should be definitely more bottom up to people who are more closer to the day to day implementation.

Tim Bornholdt 15:59
Oh, yeah, that's a really great point. I think the more you can actually listen to the people that are on the ground dealing with the software and seeing the problems, I mean, even if they're not getting direct insight into a particular feature, or anything, just having the perspective that somebody else is coming from, whether it's the management or marketing or whoever in an organization, like just having those kinds of information coming to you, as a tech, as a technology provider, like as a developer, there's so many micro decisions developers make day to day that knowing the why behind the decision instead of just knowing the decision can sometimes lead to better outcomes at the end of the day for the product too. So I think that's a really great point.

Anand Safi 16:45
Yeah, absolutely. I agree 100% with what you said.

Tim Bornholdt 16:49
Nice. So moving on a little bit. You are a former club president of Toastmasters. I've definitely heard of Toastmasters. And I'm vaguely aware of what they do. But I'd love for you to explain what it is and and what kind of led you to get involved and what impact that's had on your career.

Anand Safi 17:07
Yeah, I think it was not something that I planned or always wanted to do. As you said, I'd also vaguely heard of it when I got involved with it. But it just presented as an opportunity that I felt was just, now that I look back, I think it was one of the most rewarding moments or probably the steps in my career journey the way it has had experience or just influence on my own public speaking communication or just collaboration skills, actually. So to talk about Toastmasters itself, it is basically a nonprofit, which is helping to empower people, literally anyone in the entire world. It's not limited to an area or country or just a state or just zones. It's basically a global nonprofit where it teaches public speaking and leadership skills. And the way it does it is has a network of clubs. So there are these Toastmasters chapters or clubs that you could be a part of. And when I joined, it was more than 15,000 clubs around the world and more than 125 plus countries. So it is there around close to 100 years now actually, I think they were started in 1924 or 5, and over the last 100 years actually, almost nine decades or so they have helpedpeople just become better at public speaking and develop confidence and be better at communication. The differentiator with Toastmasters versus other things that offer similar things is I really feel that their mission is unique that it has diversity and inclusion baked in. Toastmasters meetings were some of the times where I felt people were the most vulnerable, in terms of sharing their experiences, trying to just open up about their success and failures, actually. People were most embracing of each other's experiences. So failure was considered kind of more valuable to share because there were a lot of learnings for people to take that they don't repeat those mistakes again, in that matter. It also was very impromptu. So each club had kind of a structure of like a president, secretary, treasurer and just little kind of meetings on the day would have different actors and roles where you could be kind of leading an impromptu group discussion for that matter. You might be leading an impromptu q&a session actually. So it involved a lot of, I would say, thinking on foot. And it just helped me just become better at just street smartness, if I may, in terms of just not planning, pre planning, though, like I'm big on planning and organizing things. But the more I realized over the course of my career is that does not always work in a wartime situation, or a production incident or something, or a software kind of patch gone wrong. Pre planning and organizing does not help at that moment. You need to decide or you need to think on foot on what is the best course of action. You need to be more collaborative. You need to work with people's, I would say, unique attributes and characteristics of all the parties involved actually to reach a consensus. So those are the things that they kind of just don't teach it, there is no formal teaching involved. But just speaking and sharing and listening to those experiences from people just kind of makes you more confident about your own experiences and taking it forward actually.

Tim Bornholdt 21:04
I think there's so many things to unpack in that because there's the vulnerability and empathy side of things. I think you're absolutely right, especially in a technical role, or managing technical people, alot of times people that are technical by nature, and think very logically have a hard time with that kind of quick changing, just rapidly evolving circumstances. And in technology, like, I'm sure, you know, like the way that you thought today would go at 9am is way different than how it is right now, at 3:30pm. The day just changes and evolves.

Anand Safi 21:44
Yeah, absolutely.

Tim Bornholdt 21:45
You just have to be able to adapt, and really like the best way to train for it is to just do it. So to be around a group of people who aren't going to judge you, and, you know, I'm sure one of the things you take away is that everybody sitting in that room is probably just as terrified as you and you aren't paying much attention to other people, if that makes sense. Like, everyone's just kind of worried about themselves. And you kind of learn like that to hone that, that you can be vulnerable, and you can put yourself out there. And most of the time, people will just be indifferent. You're kind of your own harshest critic, so to speak. And I can just say, based off of our conversation so far, it's like, I can tell that you're very well spoken. And I would assume that a lot of that attribution goes right to your time at speaking at Toastmasters.

Anand Safi 22:37
Yeah, and I can share actually, I did not touch on how I got involved in Toastmasters itself. So this was through one of my previous roles at a company called Intent. So I was a part of the engineering team. We were based in New York City. And I was there for six plus years, actually. And I think during my year three or four, I really wanted to do something more than just engineering output. I wanted to spearhead or just kind of look at an initiative that I could help from a company culture standpoint. And one thing we quickly realized is engineers are great at writing code. But then they want it to end there, most of them. They don't want to go up on a stage, share their work, or speak with many people around the company. So what we were seeing in company town halls is the product people or the marketing people would say, We built this cool new feature, and this is what we're rolling out. But we also wanted engineers to take an equal part in that, like sometimes going up and sharing like, I built this, or we built this, and this is the things that we were kind of looking for when we were writing up a solution for this problem. So we wanted people to be able to speak about the technical work they did in a non technical fashion and just interact with a group of people. So that led to me and one of our product managers in the data science practice, so me and her went up to our VP and said, I think we should start a Toast, like we think we should start a Toastmasters chapter here. We will first start with just an internal company chapter, see how much traction we get. And then that's how we started just doing the Toastmasters meetings and it was amazing in terms of when I gave my icebreaker speech, I had people come up to me and said, We didn't know you were just as passionate about the things you mentioned, actually. We didn't know you're such a good speaker, because I actually am a very good listener. I might be talking a lot right now. But in most meetings at work, I used to stay really silent for the most part because I like observing and getting the gist of the situation and things going on before given my own thoughts and input rather than just adding a loud voice in the mix actually. So I'm always kind of that little bit in terms of being a listener and a little less active in meetings most of the times, because I'm trying to process and see that I can present the information in the right way. But the flip side after work hours, when we did these meetings, we realized people had so much to share and talk about, common interest and all those things just opened up, that it felt really productive as a company culture thing.

Tim Bornholdt 25:26
Yeah, it's amazing the difference in people's personalities from work to outside of work. And I think that seems like a really cool way to go about doing it is just having, like you said, doing like impromptu speeches and doing going through the Toastmasters program, I'm sure, opened up a lot of, it just opened up your eyes to other people, and then also conversely, that it opened up their eyes to you. And that I think there's something really, really beautiful about that. I wish more people that were in tech were better at speaking because I think then we would all be able to have a little more empathy with each other. And you know, usually when you're in the tech driver's seat, it's the, you know, what is it the problem exists between keyboard and user Pep CAC. I can't remember that acronym is but you know what I'm saying? Like, usually people think like, Oh, it's the user's fault. They're dumb, bla bla, bla, bla bla. But when you anybody can have a little bit of empathy by putting yourself out there and listening to other people, honestly, too then that's a really great way of developing that empathy. So you can, you know, at the end of the day, build better software.

Anand Safi 26:29
Yeah, I think that really helps to keep you and the team honest and accountable at the end of the day, versus the blame game. So I totally agree with that.

Tim Bornholdt 26:38
Well, you were kind of mentioning the previous job. And you've had, you know, a career path of going from software engineer to manager, and seemed like that was a pretty intentional way of doing it. But a lot of software engineers that I know, don't really want to get into management. But a lot of the ways that businesses have structured themselves, it's you kind of have to go, if you want to be promoted, you have to go from being an engineer into being a manager. What advice do you have for organizations with regards to finding a way to promote talented engineers, but keep them doing the engineering work instead of having to move into managerial role?

Anand Safi 27:17
Yeah, I think that's, again, such a valid point that our industry has faced, especially engineering organizations, or just the engineering practice as a whole. I think this is just a traditional mindset of just kind of the thinking that has been set up for decades that because you're manager gives you more power, authority, compensation, just the will to hire and fire people, a lot more things in terms of just seniority means management, that has been the preconceived notion for most companies, I think, till fairly recently. I actually just gave a talk on this exact topic, which said, From an engineer to a manager is not a promotion, it's just a different career path and roll altogether.

But to your point, in terms of just what organizations can do. So I do see that happening actually, nowadays, the new companies that are starting or the companies that really care about their team dynamics and culture are starting to adopt more and more the concept of dedicated career ladders. So in terms of career ladder being just a vertical climb, that is, you are an engineer, senior engineer, and then an engineering manager. They are more like kind of spread in all directions now. So not only you could go from being a senior engineer to say, a principal or staff engineer, you could go to also being an engineering manager. That being said, the number one thing that organizations should do is have dedicated career ladders for an engineering IC track, and an engineering management track. We do have that at Mark43. I was super impressed when I joined the team on how much work the team has put in and part on making this a reality. There is a clear path at each level, in terms of whether you are an individual contributor, that is who's just starting fresh as a new engineer, to a really principled staff level engineer. And on the flip side, whether you're starting as a new engineering manager to senior manager, director, VP. So each of those roles have clearly defined in a rubric fashion, the things that you should or should not be doing as well. It's really important too, like what are your core focus areas, but what are some things that are not your primary focus areas, so giving that clarity to the ngineers is key that organizations need to put a focus on.

A little bit more on that is, what would be their motivation to come up with such a career ladder is that I think you need to, like as a company, need to know exactly what keeps your engineering organization motivated and interested. It can differ from engineer to engineer. Many people would like to continue to have the ability to just have head's down implementation time or just focus time, without being pulled in too many directions, without fragmenting their role too much, without having a lot of things to just juggle between. They want to do one thing, and they want to do one thing really well actually. You also need to just kind of realize that at the end of the day, technology or working product, is your key differentiator. You might have great talking points that your product or software does various things. But when it comes to show time, or when you need to demo it, or you need to see it in working fashion, that technical kind of fitness is kind of what will dictate whether it is a winner or not actually. And for that you need to have continued engineering output, scalability and innovation from the engineering practice. If you're trying to give people management responsibilities to your most senior engineers, they are not going to have the time to equally focus and do some of their most fine work from an architecture standpoint as well. So we need to embrace the notion of like, who is a creator, versus who is an enabler, if I may. So engineering manager, I see them as enablers. They unblock the team, they guide the people on the team and the direct reports with mentorship and coaching. But creatives are still really strong engineering ICs at the end of the day.

Tim Bornholdt 32:00
And when you put it that way, it's really obvious why putting somebody that's a very talented engineer directly in charge of people is such a monumentus shift in mindset. Because if you are a very talented engineer, and you spend most of your time in the code, that is a very specific skill set of being a creator. The skill sets required to be an enabler and to remove roadblocks and set other people, other creators up for success, it's a whole different mindset. An obvious parallel would be looking at like pro athletes that move into the management or into the coaching roles. There's not too many pro athletes out there that become, you know, pro level caliber coaches. It's just they're two completely different mindsets, even though you would think that like, you know, Tom Brady, for example, might make a great head coach, because he makes a great quarterback, but there's so much more that goes into being a head coach than just being able to throw a football and you know, not get tackled a 1000 times. But that's neither here nor there. I think that's a really great point of being a creator versus an enabler.

Anand Safi 33:22
Yeah. And I think you put a great example to this, actually, in terms of some of the best coaches in the industry or any industry might not have been players themselves, or might not have been as strong as a player as they are as a coach, actually. So that is one thing to realize that there is no literal translation that because you're a player, it means you will be a great coach. It's just a different skill set on just individual output versus just getting a team to do the work and just kind of fostering team teamwork and collaboration. So it's just two different things. At the end of the day, there is no literal mapping that good at one thing means you'll be good at automatically the other thing.

Tim Bornholdt 34:08
Right. And I think it's, like you were saying, having the ability in your organization to allow developers, you know, because some developers can be good managers. And some engineers like moving into that architecture role and just kind of understanding more of the stack and being higher up. And I think finding a way in your own organization to lay out a roadmap and several different possible career paths so that you can see a progression, I think that's super important for non technical folks to take away is just having a lot of different options and finding which option fits best for the individual is going to easily be the right way to do it instead of just assuming that they're going to go from being a creator to being an enabler.

Anand Safi 34:59
Yeah, and I think it's on companies or us as Engineering Leadership or teams to provide the psychological safety to your engineering talent, that just because you don't want to take up a management role doesn't mean that you are lacking anything or you would be rewarded less fairly than any other higher up roll. At the end of the day, I think leadership is key. And leadership is either in terms of system or architectural leadership, or in terms of people or team leadership. So there are two different things and you need people in both areas, actually, to just be successful as a team or organization as a whole.

Tim Bornholdt 35:42
Yep, I could not agree more with that. Jumping back over to Mark43 for a little bit, we kind of touched on this, about just needing to be, you know, worrying about uptime. And there's so many different components to dealing with the software you work with. But I'm one thing I want to hear your feedback on is when you have software that's already in use, and again, this has to be software that it has to be up and running and no crashes, how are you able to set up and foster an environment that you can continue to innovate while making sure that what you've got going is still spinning? If you think of spinning plates, you know, making sure that you still got all the plates spinning on the one side and you're adding new plates onto it. Like how do you juggle all of those concerns?

Anand Safi 36:31
Yeah, I think this is a constant challenge for not only for us but I think for most teams, actually, because the business would love that teams keep crushing it as SSA, just put out more and more features, just add more things to the product to make it more extensive and offer a variety of things to the customers and end users actually. But at the same time, if you're just focused on feature building, the technical part will not scale up, actually, if it's not given the love and attention it needs. So there are constant efforts to make sure that we are continuing to have some form of technical innovation, some form of critical thinking, or that creative juices flowing up with the engineering team to balance the product or business expectations, or with just a strong technical foundation or just like a technology base.

There are some some ways we try to achieve this. First is we do a mix of product and tech initiatives during our planning. So we are fortunately not one of those companies or teams that is fine to accumulate tech debt as we go, SSA, and then just say, Let's focus on the user facing things only. Let's not worry about what is powering those things, actually. Technology, tech initiatives in general are taken very seriously at Mark43. So each planning cycle we will be looking at, what are some proposed product managers? What are some proposed technical initiatives? And then making sure that we're prioritizing among those which are probably just most important, whether they are product or tech. So each initiative or proposal is given equal thought weightage and consideration before making the decision on what the team will be focusing on for the upcoming quarter in that regard. So first is just opening up a channel to make sure that technical work is always prioritized to build those systems that can have some wonderful features built on top of that, actually.

The second is we do hackathons or hack week. Actually, this week is hack week at Mark43. So we are trying to give people the time to focus on something entirely different from their day to day work style, whether it is coming up with your own hackathon idea and just riding with it or experimenting on your technology, or it's something totally radical where you feel let's expand into a new vertical. And then you pitch your idea actually in the company. And then you can get people from various divisions to be your team. And for one week, you just come up with the proposal, the scope for a POC, and then you do a pitch presentation at the end of the week, actually. So some of our actual core features have come from those wacky hackathon ideas as we say, and that is just amazing. Like if people are not pressured, in terms of this is your sprint goal, this is your weekly commitment, this is what we need to focus on or this has a go-live day, if they had all those things squared away from people's minds, then they can just focus on just building cool things, actually. And that is how technical innovation is really a key part in terms of some of the feature work that have come up through these technical hackathons here at Mark43.

Last thing that we want to do is apart from this specialized hackathons are just planning technical initiatives. During the quarter itself, we are trying to dabble our focus a little bit of dual track agile. So what dual track agile means is a mix of discovery and delivery. So for things that we have already planned out, from an product or technical initiative standpoint, a group of people or engineers on the team might be working on delivering those core commitments actually. So the high integrity commitments that are already said that we will be doing, a mix of engineers and product team, we'll be focusing on delivering of those commitments, which is a delivery track, while another set of people would be focusing on the discovery track. So what's next? What's upcoming? What is something else we could be doing in the future? Having those meetings, discussions, research sessions, trying to do focus groups and trying to gain more data and information from within and outside the company, from our users, in terms of what is that thing that we should be building statically. So we have a discovery backlog in that regard. And that is how we can kind of stay ahead of the game or the curve in terms of doing discovery, as we are doing delivery as well.

Tim Bornholdt 41:41
Those are really great pieces of advice. If you are looking to keep your company having all those plates spinning while adding others. I think, man, there's so much to break down in those. I think the place I want to start is the notion of a hack week, or having a time that you devote to just letting your team go. People always talk about hiring for like company fit and culture and things like that. But then stifle them with just boring work or just putting things on their plate without actually giving them responsibility to, like, you know, innovate and let their imaginations run wild. And I've seen this happen in a lot of different formats and across different organizations, you know. Some have every Friday, in the afternoon is your own time, and you work on your own project. And like, you know, the team comes back and pitches each other and you get that like every week, you get to look forward to having some of your paid time just be working on side projects. The hackathon idea is, and having a having a hack week, is just a really smart way to do it. Like you said, I couldn't imagine how many innovations have come from those types of meetings of just, Hey, I wonder if our app did this. And then like, you know, leadership can, I would imagine, like being in the leadership role myself now just how much fun that would be for them to just sit and be like, Oh, my God, like, those are some really good ideas coming across.

Anand Safi 43:15
Absolutely. We cancel all routine meetings that will happen that week normally, and it's just kind of just, yeah, think what do you want in terms of and also it does not need to be work related, right? Like, it's just, I have really wanted to try a new technology or a new thing that has come up or I really wanted to try out this product. And then from there just even if you just try it out and demonstrated the pitch presentation, who knows someone else in the company might be able to connect the dots and say, It's great you just tried this out. But there is maybe a chance that we could integrate this into our own product, or kind of we could build something similar into our own product, if that is possible. So again, it's not only just new technology or work related things, right. It could be productivity things, like how many people come up with productivity hacks, or just improving developer efficiency, how to do better time management, how to not get distracted at work. There are just so many cool tips and tricks that come out that as an organization that just helps us have more kind of best practices set up in terms of things that people are able to test out for a week, that it makes a real difference and then it just becomes the norm going forward.

Tim Bornholdt 44:36
I love it. And then e first and third points you made about making sure like while you're planning things out that you're making it a mix of new product features as well as like tech debt payoff type of features. And then doing this dual track agile as well of having one team like focusing on just churning through the backlog and getting things done. And then another team kind of setting up that backlog and doing all that research. I think it's the organizations and the tech companies that put an emphasis on, like, building out like infrastructure and focusing on infrastructure, I find are the ones that end up really being able to leapfrog everybody else. Like, if you try to save all of your tech debt for one big refactor down the road, you're just setting yourself up for like, a real bad time trying to get any kind of like, if you ever tried to go from like Rails three to Rails six, or something crazy like that. And you have to worry about how you're going to get all your databases set up. And oh, we've never written a single, you know, unit test or just different things like that. You see all kinds of crazy things in technology. But yeah, the organizations that do it the best are the ones that, you know, I don't think I know very many developers who would say that they just love doing maintenance and just love doing bug fixes and stuff. You know, everybody loves building new shiny things. That's human nature. But I think at the same time, it's human nature to not want to focus on those kinds of like upkeep and maintenance, like everyone wants the new bridge built across the town, but nobody wants to try to spend, you know, hundreds of millions of dollars to repair the one that we have that's existing. So I don't know. I'm kind of rambling here. But I just wanted to throw on some some extra points on what you were saying with having an organization that has both new features, as well as maintaining existing features equally weighted in their mindset, I think that's super important.

Anand Safi 46:43
Yeah, absolutely. No, I think you bring up great points to support that. And I think I really see that happening with more and more teams. And one of my last roles, as you mentioned, actually, we have the hackathon. And then we had the Friday to focus on just whatever you want it to. Maybe it could be some cool project that another team is doing, or just pair program with another engineer in some other division actually, just to learn something. So that 80/20 is really working, where people are saying 80% is our core commitments, but 20% is your true, I would say, innovation time, in terms of just to keep you motivated and engaged, and given the time and support you need to do things that you really would want to do otherwise.

Tim Bornholdt 47:34
Yeah, exactly. Could not agree more. Anand, this was awesome. I really appreciate you taking the time to come on the show today. Maybe you could end this off here by sharing how people can get in touch with you and learn more about the work you're doing over at Mark43.

Anand Safi 47:47
Absolutely, yeah. So I think the best way for people to get in touch with me is through LinkedIn. I am fairly active there. I love talking with people, connecting with people. So you could find me on LinkedIn by my name, Anand Safi. I also do a lot of mentorship, formal and informal through various platforms. You could find me on a platform called Mentor Cruise, and also on a platform called Plato HQ, really popular for Engineering Leadership mentoring, and then Mentor Cruise is really great for people who are fairly new in their engineering journey, or who are people who are willing to get into their engineering journey and want to make a transition actually. So yeah, I really would love talking with you and assist in any way I can. Or also just on LinkedIn, we can just connect and then set up some time for a virtual coffee chat to talk about just team culture, engineering culture, team dynamics, and what are some ways that people are tackling these things that I shared in their own organization and role. Because I think this is just a collective learning thing. It's like it takes a village to get it right. So what I shared might just be, I would say, a needle in a haystack in terms of what other experiences are out there.

Tim Bornholdt 49:08
Well, and you know, you mentioned being active on LinkedIn. I mean, you reached out to me there and I am really grateful that you did because I think there's a lot of great nuggets in this episode that people are going to take away. Anand, I really appreciate you taking the time to speak with me today. And hopefully we'll chat again soon here.

Anand Safi 49:27
Awesome. Thank you so much team again for having me. I think I definitely learned a couple of things from your own experiences and examples as well. And really, really happy that I got a chance to talk with you and come on this Constant Variables podcast.

Tim Bornholdt 49:44
Thanks to Amand for joining me on the podcast today. You can learn more about him and Mark43 at Mark43.com. That's Mark with the number four three dot com.

Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constantvariables.co. I'm @Tim Bornholdt on Twitter and the show is @CV_podcast. Today's episode was produced by Jenny Karkowski and edited by the warm Jordan Daoust.

If you have a minute quick before you leave, we'd love it if you left us a review on the apple podcast app. It shouldn't take much time at all. And it really does help new people find our show. So please head to constantvariables.co/review, and we'll link you right there.

This episode is brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help make sense of mobile software development, give us a shout at jmg.mn.