#120 – Alexander Gilmanov on Transitioning From Developer to Entrepreneur

Transcript

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name Is Nathan Wrigley.

Jukebox is podcast which Is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, one person’s story about the struggles of transitioning from a freelancer into an agency manager.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com forward slash feed forward slash podcast. And you can copy that URL in to most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea featured on the show. Head to wptavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today, we have Alexander Gilmanov. Alexander comes to us today from Belgrade, Serbia. He’s a full stack developer with a rich heritage of freelance and agency work. His company officially launched in 2014 and they’ve continued to work with clients as well as creating a range of WordPress plugins, and their own SaaS apps.

Slightly unusually for this podcast, I decided to break the content up into two parts. You’ll hear the first part today, and part two will be coming out in the next episode.

If you’re a developer and are in the weeds of writing code, perhaps you’ve thought about a change of direction. This could be changing the place where you work, but it could also mean starting an agency and moving towards a more managerial role. This is what Alexander did, and this podcast charts, his journey. The highs and the lows, the epiphanes and the moments of regret.

We explore Alexander’s transition from hands-on coding to strategic management. He shares insights into his initial roles, where he juggled multiple tasks and managed client expectations as a freelancer. This foundation, not only honed his technical skills, but also prepared him for the complexities of leading a business.

We talk about how Alexander’s management style has evolved over the years. Starting out,

he faced the typical challenges of delegation and supervising a growing team. Trying to understand individual personalities and communication styles to create a functional working environment. His approach emphasizes the need for breaking down large tasks into smaller, more achievable goals. A method that has proven instrumental in managing both projects and people effectively.

We also discussed the critical role of autonomy in the workplace, particularly how Alexander has learned to trust and empower his employees based upon their experience levels, leading to greater productivity and satisfaction for everyone.

He reflects on the key lessons learned from the earlier phase of his career, where he underestimated the importance of project managers. And how this realization led him to restructure his business operations to optimize efficiency and output.

It’s a fascinating conversation, and if you’ve wanted to start an agency, but have concerns about what that might bring, this episode is for you.

A quick note before we begin the recording quality on Alexander’s side, wasn’t superb, but I’ve done my best to make the audio as easy to listen to as possible.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com forward slash podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you. Alexander Gilmanov.

[00:04:07] Nathan Wrigley: I am joined on the podcast today by Alexander Gilmanov. Hi, Alexander.

[00:04:18] Alexander Gilmanov: Hi. Thank you for having me.

[00:04:20] Nathan Wrigley: You are really welcome. You were brought to my attention, actually, what I’m about to say is not entirely true, and I’ll tell you why in a moment. But you were brought to my attention recently by Tammie Lister, who was recently on this podcast, and she mentioned that on a different podcast, she had been chatting to you about a subject which is going to be the main course of the podcast today. It’s all about moving away from being a developer, into being a manager.

But the reason that I have known about you, if not spoken to you before, is because of the products that you’ve got in the WordPress space. And so let’s talk a little bit about that. First of all, Alexander, would you mind just introducing yourself? Maybe talk about the plugins that you’ve got in the WordPress space, just so that we know a little bit about you.

[00:05:04] Alexander Gilmanov: Of course. Yeah, so as you already mentioned, I am the founder and CEO at the software products company. My own background used to be full stack development, a little bit of desktop development, and web development, and WordPress development. And I had a transition from being a developer to becoming a manager, and the founder, and the CEO of the company. Currently we are at 43 people, and still growing.

So yeah, it was quite a journey. But before talking with Tammie and Jonathan, I didn’t realise actually that it might be of interest, and it might be useful to some developers out there, that are maybe also considering switching to managerial roles, or becoming founders.

Then a couple of words on the products. Our first product that helped us to start the company was wpDataTables. It was initially a data management, but more a table plugin, a plugin that helped you create interactive tables on the website. Later we added charts, data management, database management, and now it does more and more in the area of data management, data visualisation, data manipulation, and so on.

The other plugin that probably more people know is called Amelia. It’s a booking plugin, mostly appointments, bookings for businesses like salons, healthcare industry, home services, photographers. We have so many different use cases. So practically, any business that provides certain services within certain timeframes, and can use scheduling tools, accept online bookings, online payments, and there are lots of things around it.

And our third product is called Trafft. It is actually something like a SaaS version of Amelia. It’s not a WordPress plugin, it’s a standalone platform, but we do have a native integration with WordPress. And the reason for that, why we decided to make it as a separate product, was because we saw that once businesses get to grow, they no longer want to manage the website, and the bookings from the same dashboard, from the same place.

And also, many of them don’t want the burden of monitoring, backing things up, et cetera. Everything that an average WordPress hosting, many hostings don’t do that. And we do that for them on our platform. So yeah, that’s in short what we do.

[00:07:39] Nathan Wrigley: That’s great. Thank you. A really interesting collection of products there. We are going to be telling the story really though of a part of your life. We’re not going to get into the personal things, but we’re going to talk about a real change in your life. Your move away from being a developer to being a manager of, currently, a company of 43 people. Which is no small task, I’m sure.

You were saying to me, before we hit record, that you weren’t really sure that this story would be of interest to people. And obviously I’m in disagreement with that, because I’ve got you on the podcast to have that conversation. But there’s going to be a very large amount, I would’ve thought, of developers who listen to this podcast, people who are writing the code, working in an agency.

And maybe there’s a proportion of them who are thinking about, well, what could I do with my life differently? Do I always have to be a developer? Is that something that I can move away from? And maybe management, owning a company, running a company, and all of that, would be of interest to them. So, okay, let’s rewind the clock. How far are we going back in time, before you had an intuition that development, for you, wasn’t going to be the rest of your life?

[00:08:48] Alexander Gilmanov: I can’t think of an exact moment in time when it clicked. And also, I really have hopes that I will get the chance to code again one day. I really miss it, to be honest. But I would say, for me, it was a transition from being a developer, to being an entrepreneur and a founder. And being a manager is just one of the roles within being an entrepreneur.

I think, almost from the beginning of my career, I did have an ambition of creating something of my own. So it was out there more or less all the time, I just didn’t know how to do that. I transitioned through being a developer. I didn’t start my company right away, but I created my first plugin, my first piece of code, and started selling it. And this was maybe the moment when the exact transition happened.

But some changes in the mindset, I would say, happened before that, because I was freelancing a lot. I was doing a lot of freelance development back in my hometown, for some local companies. Later started working on some platforms like, I’m not going to call the names, but there are many freelance based platforms where you can get either a website, or part of the website to develop, as a freelancer.

And I think being a freelancer really trains you for being your own manager. And that’s the first thing you learn, to first manage your own time, your own budgets, expectations of the client, all that. It helps you to start managing other people.

[00:10:20] Nathan Wrigley: I think that managing other people is quite a skill. So being able to manage your own time is one thing, I’m okay at that. But if that were to stretch beyond the confines of my own life, I think that would be really difficult. And my guess would be that you’ve probably, in the growth of your business, you’ve probably had moments where it’s gone really well, and the management of the people has gone really well.

Equally, I’m sure that there’s moments where you’ve looked at yourself and thought, oh gosh, this is not going so well. Are there any kind of fundamental skills, looking back over the last period of time, you think that you are equipped with? Whether that was through education, or whether that was just through the genetics that you were given. Are there any things that you think, looking back, okay, this thing equipped me to be a boss, and without that thing, have a long, hard think about acquiring that thing?

[00:11:14] Alexander Gilmanov: Yeah, there were a few things in my career, and my personal life that helped me with that. And I think there are two parts of that. First is, I’d say managing tasks and understanding the whole, and then dividing the whole into subtasks. Seeing the wider picture, and then dividing it into details, is like one skill.

Very important for a manager, for a product manager, whatever you name it. I mean, it can have different variations. It can be just developer manager, or like engineering manager. But more or less, this is the fundamental skill.

You need first to understand, what are we working on? What is something we want to achieve, the end value? We want to give our users, our customers, and then divide it into independent tasks. This is not something that to get equipped with, I’d say.

For me, I think the first very large project was my PhD study, because it’s project that lasts for, for me it lasted almost four years. It had lots of components, very different ones like writing the study itself, writing the software, preparing the scientific part, writing scientific publications, leading some courses in the university, finding opponents in the scientific world.

All of this takes a lot of time. Most of the things won’t go as planned. You need to take a step back 9 out of 10 times. This trains your brain to approach this very calmly, not rush things. This creates sort of a skillset you need to manage. First manage yourself, then other people.

This is, I’d say, more or less a hard skill. Something you can manage through project management software, task lists, checklists, this sort of thing. But more importantly, you need to understand how to communicate with people. How to talk with people. How to explain things to people. So all of this falls under soft skills.

And I think it was one of the key things for me, because I always worked with computers. And then you start working with human beings that don’t have algorithms, don’t have buttons, procedures. You have two developers, but both have different characters, and you need to approach them differently.

And yeah, this is also not something I’d say you come equipped with, and you need to learn that. For example, initially I tried to solve every issue that arises with an email. And sometimes when I was a little bit scared of something or frustrated, I would write a very angry email, and write it to the whole company and say like, this is your final warning, and things like that.

And it took me maybe a year or two to realise that it’s actually the wrong way to solve things, and I only create internal pressure and frustration for people, and create more distance between us, and ultimately doesn’t serve the end purpose.

So yeah, for me, as a developer, it was maybe one of the hardest parts. To have internal meetings with the team, to speak with people one-on-one, in the team meetings have retrospectives, share openly what maybe frustrates me, and allow them to share openly what frustrates them, and not be afraid that I as a boss, as a manager, will punish them somehow. So I’d say those are the categories of skills you need to develop to become a manager.

[00:14:36] Nathan Wrigley: I think that’s really interesting. You know, you talked about the PhD, obviously this giant four year project, where you can imagine the goal, the goal line, the finish line, four years away, and you’re on day one. You know that this giant thing is stretching out ahead of you, I guess it is a process of just, okay, breaking it down. What can I do this year, this month, this day?

And that atomising of it all, just sort of trying to distill it into different jobs, that’s really important. I don’t think I’m good at that. I’m sure that my characteristics aren’t very good at taking in the whole, and breaking it down in a calm way. But having that capability, I guess could be learnt. But learning and having that capability over time, really important.

But also, like you said, the human element is maybe even more important at the end of the day. Because you’re not going to get anything out of your coworkers, your employees, if they don’t feel compelled to work with you, and for you. If there’s just tension or, goodness, even hatred, then the whole thing is going to collapse like a house of cards.

But forgive me, dear listener, you are listening to this. I have this intuition that developers, now, this is not going to be the case for everybody, but I think that developers can have a certain tendency to, there’s just a way of being a developer, isn’t it? There’s a certain mindset which works effectively with code, and it doesn’t always translate into working with humans.

And so being able to stop yourself and say, oh hang on, that is not an algorithm standing over there. If I tell it to do this thing, it might go off and do something entirely unexpected, and I need to be able to accommodate that. I need to be able to understand that. So identifying that in yourself is, yeah, it’s pretty impressive.

And the fact that you’ve been able, over time, to unpick that in yourself and say, well, hang on Alexander, slow down. Don’t write that email because they’re not an algorithm. Think about the human, we’ll see where this goes. Okay, this is really interesting.

[00:16:33] Alexander Gilmanov: Just one thing came to my head. One thing I remembered while we were talking. One of the switches I had in this process was, at first when I started working with a team, the team of developers, I tried approaching those people as processors, servers, something like that. And like really giving them detailed instructions on what we need to do, and how we need to do this.

And then when something didn’t quite work out, I think, okay, maybe the instruction isn’t detailed enough, so let’s take every step, and give an instruction for every step. And in the end, it turned out to be harder to prepare all those instructions, instead of just doing things all by myself.

It’s sometimes easier to write a piece of code myself, than to create an instruction on like how the coach should look, where to put all the classes and methods, and all that. And this is something, it didn’t come overnight. I realised that, first of all, you need to hire the right people for the job. So you can’t just hire a student and give a senior grade task, and expect it to be delivered.

Then when you have the right person, yes, you do need to give them guidelines, and the end goals, and the problem, and good description of what we need to achieve in the end, but you don’t need to guide them all the way through. And especially for developers, when you are managing developers, you are like taking away all the juice from their job if you’re giving them too precise instructions. Because they want to create, they want to think of their own architecture, how they write their own elegant code. And if they receive an instruction, like if they’re a script or a server, it’s just not interesting for them.

[00:18:08] Nathan Wrigley: I think that’s really interesting. The idea being that, obviously as a manager, you have to manage. There has to be a certain amount of that. But also there has to be an element of, okay, here’s the task, just go ahead and do it. Not prescriptively writing the exact instruction for every single facet of that job.

Obviously, enough instruction so that the job can be understood by that person, but not standing over them every minute of every day just worrying about whether it’s going to be achieved. I guess the better employees will figure that out for themselves. They’ll go away, they’ll have autonomy, if they’re confused, they’ll come back, you can have a conversation. It’s not always top down that works most effectively.

[00:18:48] Alexander Gilmanov: I would say you need to approach different employees differently. So when interns just join us, developer interns, actually they do want this kind of instruction. And it’s better to have someone mentor them, do peer review, give them guidance, and provide instructions for how to develop a task. They would actually enjoy it much more because, if they join a company after, for example, graduating, and they didn’t yet have some practical coding experience, they want this from the company. They want to get some guidance, some mentoring, some senior developer to evaluate their code, and point the mistakes.

But as they get more senior, actually autonomy is a very important motivation factor. And if you take it from them, you demotivate them. Because seniors want to research modern technology, libraries, services. And if they receive instructions like, use this library, the task gets too dull for them.

[00:19:48] Nathan Wrigley: Yeah, so having a handle on each employee, and judging where they are in the hierarchy of all of that. So, like you said, somebody that’s new may want to be shepherded and guided much more, because they are really unfamiliar with the company culture, the expectations of the work that they need to output on a monthly basis. But as experience develops, and your relationship with them grows, I guess, you know where the boundaries lie a little bit more, because you’ve built up that relationship.

You know that if you give them an incredibly difficult task, and don’t give them too many instructions, they can do it. But that other person over there, they might need a bit more shepherding, even though they’re, I don’t know, more senior. Okay, so getting to know your employees is a crucial part.

Now, I have to say, Alexander has shared with me some show notes which are amazing. It’s very rare that the guest goes into such enormous detail, and so I’m incredibly grateful for that. I know that it’s also so that you can structure your own thoughts about blog posts, and things in the future about this topic.

But one of the sections which I thought was of most interest was how you charted your personal journey from, well, the different kind of work that you did. So from being a freelance, to working with friends. And I’d just like you to jump through that history for us, because it may be that somebody listening to this is somewhere on that ladder of different things. And the evolution that you’ve gone through over time, beginning with freelancing, maybe it’s hard for you to sum all of that up, but I’m going to hand it over and see if you can do that.

[00:21:11] Alexander Gilmanov: So yes, I mentioned initially, and as you mentioned right now, I started with freelancing, and it taught me a lot about managing. Because management, especially when you’re not the owner, and when it’s more like an agency work, where you develop something for clients, is about organising tasks, about organising time, maybe managing others. But it’s also about managing the client’s expectations, understanding what they want.

And this is sometimes the hardest part, especially for freelancers. People keep coming back and saying, they know what they don’t want, but they’re not sure about what they want to achieve in the end. And getting a specific requirement out of this conversation is very hard. But it’s also a very tough school, and it helped me later in the journey.

And as my freelancing evolved, at one point the projects started growing, and at one point it wasn’t just small website that I could develop in three, four weeks. It was something like a web app that people want developed maybe in a month or two, and this is something I cannot deliver on my own. I had to start thinking about building a team back then.

And I had a couple of friends, and naturally we started working with them. And because they were my friends, we were relatively similar in the coding styles. We understood each other really well. The management part came very natural. So I would just prepare the requirements, divide it between three of us. And we sat in the same room, and it was very easy to think. And actually the first experience was very inspiring. We were able to deliver things. We scaled the development and it went well.

[00:22:50] Nathan Wrigley: Can I just interrupt there? Just very briefly. Do you ever look back on that time and think, I wish I’d stayed there? Because that sounds like a really, a nice environment to work in. I mean, obviously, you know, the financial reward of that probably isn’t quite so great. Maybe the complexity of the work that you can take on, maybe isn’t so great. But I imagine there’s a lot of people who are there and thinking, well, actually that’s okay. I’ve got my friends around me, the code is something that we can all share and understand, life’s good.

[00:23:19] Alexander Gilmanov: Sometimes it is. For me particularly, it wasn’t, because it was still early in the journey, the level of projects wasn’t something which I wanted to have. The good thing is, one of the friends is right here with me today in the office, so he stayed with me on the journey.

[00:23:36] Nathan Wrigley: It does sound, from what you’ve just said there, that you’ve always maybe been driven by growth, complexity, a difficult challenge.

[00:23:44] Alexander Gilmanov: Yeah, that’s the entrepreneur gene, I would say. There is something inside entrepreneurs that always pushes us to develop, to grow, to find for what’s next, all the time.

[00:23:55] Nathan Wrigley: Okay. So, sorry for the interruption. You were working with your friends and I’ll let you continue.

[00:23:59] Alexander Gilmanov: When we could work on the same project, it was great. But at certain points they had projects of their own, because they were also freelancing. And I started my first experiments with hiring other freelancers that I didn’t know. Finding them through job ads, tried finding them through also freelance platforms like subcontractors. Tried finding them through recommendations. And that’s where my first real life entrepreneurial and managerial challenges came in.

Most of the managers go through all these steps. They find a guy that, he’s the right guy for the job. We start working, everything is fine for the first few days, and then he disappears, or he delivers something that is far from what was agreed, or he’s constantly late, or they try to cut corners. Developers can identify pretty easy when logic is mixed with templates, or things like that. Which is much faster to code, but then it doesn’t scale, and creates constant problems for ongoing development.

Yeah, all those things started happening to me, and the first failures came when some of them disappeared completely, like two days before the deadline, without sharing the code with me. Things like that happened, and oftentimes I would say it’s just easier to stay freelancing on my own. If you want something done right, do it yourself. Yeah, this is kind of the belief that is common between many people, but I don’t find it to be true today.

[00:25:28] Nathan Wrigley: I’m going to interrupt there just summarise, if that’s alright? So the journey begins with you freelancing. The freelancing then gets mixed up with friends and colleagues, and people that you know. Then the complexity of that, because you’ve got projects and you need more people, you have to begin finding people. And so at this point, problems start to occur because the people don’t do what you expect them to do. So maybe there’s a story in there about how you communicate with what are essentially complete strangers, you know, what’s the level of that?

But also, you know, they’ve just got their own agendas, and they miss work, they cut corners, and what have you. And so all of a sudden, you want to grow this business, but you’re now, everything’s collapsing around you a little bit, because of unexpected problems that the first time around you wouldn’t anticipate. You’re not going to go into it thinking people are going to let me down, presumably. You’re going to go into it thinking, well, I’m going to hire somebody, they’ve got a good reputation, they’re going to deliver me quality code, and then life gets in the way, and all of these problems occur. Okay, right. Keep going, this is great.

[00:26:32] Alexander Gilmanov: Thank you for summarising. I didn’t plan it so much in advance, so I might be jumping from one thought to another. So yeah, this is the time in my journey where I realised that I am actually lacking some experience in large scale projects, in larger teams. I don’t know how the really big projects are developed.

And back then when we worked with friends, when I worked as a freelancer, most of those projects didn’t survive after 12 months initial period. Those were very early startups, and most of the time I felt like we are developing stuff for the trash can practically, because we are working hard on it, and then the project isn’t funded anymore, and just basically dies.

And that’s why I decided to take a break in this entrepreneurial journey, and moved to a larger city, joined a large German company, a MarTech company, and stayed with them for three and a half years. It really helped me structure the thinking, and understand how project management, and the development process, and the continuous integration, many other things in large scale projects.

How do all these things work? And this is probably the first time in my career when I encountered, real project managers. Before that it was more or less informal, unofficial, people that started their own startup were managing the project.

And in this company we had teams of five developers. Every team had a project manager. We were using a specific development process with sprints, with tasks assigned, with a way to test the tasks, staging environment, development environment, all of these. Many of those things we previously, we did intuitively. In this larger company, I had the opportunity to learn it from the inside, and it really helped me.

[00:28:21] Nathan Wrigley: So, I don’t know how to phrase this question. I’ll try my best. Did you begin working for this larger agency intentionally to learn? Or is it that you now look back and realise that you learned? Because I’m imagining, again, people listening to this, maybe they’re in the moment that you were, where there were lots of freelancers, and it was all a bit of a muddle. And they’re looking to fix that problem.

Your way around that was to go and work for three years. I mean, three years is a good long time, isn’t it? Where you would be surrounded by people who already had the structure. You would learn it by osmosis, it would be part of your daily work to figure all this stuff out, with the help of others.

So, did you deliberately go knowing that you were going to do it for a short amount of time to learn the processes? Or is it just that after three years you thought, oh, look what I’ve learned?

[00:29:11] Alexander Gilmanov: It was, I’d say a mix of both, but more so it was intentional. At one point I looked back and I like, okay, we’ve delivered 50 websites maybe, and two or three small platforms that never survived. Do I really have the experience and seniority, and the level of knowledge and understanding that I wanted to. And when I honestly admitted that I don’t, I realised that, okay, maybe I shouldn’t be rushing into entrepreneurship. Take a step back, join a company that had it figured out.

And initially when I joined the company, I thought it was going to be only about maybe 4, 12, 18 months. But the company was so good, and people were so good. At one point after the first year, I didn’t even think about getting back to the entrepreneurial journey, because when you have everything figured out around you, even when you do have these entrepreneurial genetics, it’s nice to have the pay date on the first of every month, and you have predictability, and you have other people worrying about things. So that’s one of the reasons why I stayed for three years there and not for one year.

[00:30:16] Nathan Wrigley: Can I ask, okay, after three years, why then change? Was it just the entrepreneur in you, who just couldn’t quite reconcile the deep desire that you had to do your own thing with your reality? You know, you’re turning up to work and getting a paycheck, and all of that. I’m guessing that’s more likely. You just evolved out of it and thought, I want that in my life again, I want to be in charge of things, figuring things out again.

[00:30:40] Alexander Gilmanov: I think that in the essence, yes, it was that. Because at one point I started freelancing again in my own spare time. Practically, I moved to a larger city and I didn’t have friends, I didn’t have a girlfriend, I had all the time in the world. After a full-time job, I also had a few more hours where I could do something.

So at one point I started freelancing again, but I could do it on a different level. And this is when I started the pet project, which ended up being first PHP data tables, a PHP script for rendering tables. And then I wrapped it as WordPress plugin, and published the WordPress plugin.

It was still a pet project, but then when I started seeing people buying it, liking it, enjoying it, using it in different parts of the world, people started sending me requests for more features. I started receiving support requests.

For me, it was so inspiring, and I realised that maybe $100 earned through selling my own piece of software, are more dear to me than $1000 earned through working at a full-time job.

[00:31:45] Nathan Wrigley: Oh that’s such an interesting sentence. That’s really interesting. Okay, alright. Sorry to interrupt. I just thought that was worth calling out.

[00:31:53] Alexander Gilmanov: At one point, I just couldn’t help but invested more and more time into my own thing, my own baby. When you see it’s growing, it’s a feeling you don’t get from anything else really. At one moment it started selling really well. It wasn’t still enough to become a substitute for a full-time job. People were using the plugin, and they wanted also to add features X, Y, Z, and they were ready to pay for it. And I started charging higher and higher hourly rates. I figured out, people are still happy to pay those higher hourly rates. And I just decided to take the risk, to quit my full-time job, and to start a company.

I was still relatively young, I was like 27, 28 back then. I decided that, what do I get to lose? Maybe I will lose one or two years. I can always get back to full-time job, some other company. And there is nothing like this experience. Yeah, it was a very interesting moment in my journey. And this is actually the next step.

[00:32:50] Nathan Wrigley: I was just going to say though, you’re in a really different place, aren’t you? Because if you go back to your hiring freelancer moment, there were all the trip wires that you went through, and the things that you did, in air quotes, incorrectly. You are now armed with three years of knowledge of working at an agency. There’s a whole bunch of things that you will now not get wrong, because you’ve seen how to grow a business, what kind of processes need to be in place. And so, okay, let’s go, starting my own company.

[00:33:17] Alexander Gilmanov: Yeah, that was the next step. And this is when I needed, had to become project manager, the office manager, finding an office, changing bulbs, finding furniture, hiring manager, developer, all that. I had to divide my day in small shifts. For two hours I’m an office manager, for two hours I’m a product manager.

It was an interesting time, and I think I did it at the right moment, I was still full of energy. I mean, I’m still full of energy, but I don’t know if I would have the guts now to enter the same journey once again. I have family now, I need my own time. Back then I did have the luxury of waking up at whatever time I wake up, and then just work for 12, 14 hours, and then just go back to sleep. This was the whole life for the first year or two of my company in the beginning.

[00:34:04] Nathan Wrigley: You just described it as an interesting time. You know, changing light bulbs, picking out furniture. Interesting is an interesting word. It’s kind of implies that there’s a little bit of frustration there maybe. Jobs that you probably don’t need or don’t wish to do, but need to be done. Basically, it’s got to be you, I guess. You know, the light bulb’s gone, okay, who’s going to change it? Let’s look around, oh me. The carpet, somebody spilled the coffee on the carpet, who is going to, oh me. That’s a big change in life, suddenly. I guess, yeah, interesting sort sums it up. Frustrating, but useful and necessary.

[00:34:38] Alexander Gilmanov: Yes, exactly as you described it. And this is something that happens with bootstrap founders. It’s not like you become a boss, and everybody starts running around you. For the first year or two, it’s the other way around. You have to round around everybody and everything, and make sure things don’t fall apart. Because when you start something new, it has a tendency to die initially, in the first year or two.

I mean, things just fall apart. Servers are falling, light bulbs are going out, the first developer you hire decides to change the job in two months, and you need to rehire, and to onboard, and to go through everything once again. So I think only after it was maybe 10 or 15 people working in the company, I could relax a little bit. Okay, there are people now who take care of different segments of the job.

But initially, especially as we were combining developing our own product, and working as an agency on clients, on software. It was an interesting time. It was frustrating. It was tough. It was a lot of stress, because you practically depend on every client. If one client decides to stop working with you, you immediately don’t have the funds to keep paying the salaries that you are already committed to.

So there is a lot of stress involved in the first years, but also a lot of inspiration. A lot of great emotions, because you see how things grow, and they grow really fast in the first year or two. Because growing from two people to ten people is X5 growth. These initial steps, it’s wow, amazing.

Right now we would add seven or eight people. I wouldn’t even notice much of a difference, but back then it’s changing things completely. And yeah, so you are growing your baby, and getting to do things you’ve never done before.

Getting back to the project management side of things, initially I didn’t even think about hiring project managers, mostly because of the funding restrictions. And also mostly because, initially when we started doing agency work, we were outsourcing developers. We were outsourcing developers on hourly basis, or per seat basis. And I would say there was no chance, back then in 2013, 14 to sell project manager seats to a client.

And I actually, for few years after that, it took maybe five or six years for the market, this kind of market outsourcing market, for clients to figure out the project managers are actually crucial to project success. But back then I had to do it all on my own. And when we had eight or ten developers, I realised that it’s physically impossible to do it like this anymore.

I had to be project manager on every project, including our own product, plus three or four client ongoing projects. I had to know exactly what happens, what piece of code was released, what we are planning to do. And I just realised, I am losing quality on all fronts.

[00:37:33] Nathan Wrigley: Of all of the bits and the pieces that I read, that bit stuck out to me as a real moment for you. The realisation that, I need to hire people to shepherd the people. I can’t do everything myself, and I have to allow people to be in charge of bits of my business, and to manage those projects.

And maybe that is a difficult thing to let go of, because in so many ways, project management from a developer point of view probably looks like, well, that’s a strange role. What are they actually doing? They’re just going to meetings all day, and they have more meetings after the meetings. And yet it’s really essential, or at least that’s the conclusion I think you drew.

[00:38:14] Alexander Gilmanov: Yes, exactly. And I remember my own thoughts, my own perception of project managers, while I was still a full stack developer in a large company. And we would talk, as developers, we would talk between each other like, why do these guys get to evaluate our job? They know nothing about coding, they know nothing about elegance of the code, coding standards, they don’t contribute to the software, yet they are our bosses, and they rate our work, they try to push us to do more. This is really unfair, that was my own perception.

And to a certain extent, unfortunately, I must say, some less experienced managers can do that. They can push people too much, they can come across as bosses, which I think is unnecessary in the software world. You don’t need really a boss, like a manager to be a boss and to be above you.

When I started doing all of that myself, I quickly realised that like, there is no way around syncing all the stakeholders, but having meetings. And at some point you get to 10 meetings per day, or something like that, if you have many projects. This is something that’s unavoidable, and actually it’s the most efficient way to sync, and to coordinate things.

[00:39:26] Nathan Wrigley: Would it be fair to say, now, that you are, you know, you’ve really removed yourself from the coding side of things, and you are basically project manager for the entire business. So maybe you are a project manager of project managers, which sounds strange to say. But you are managing, and you’ve totally moved away, and you’ve realised that this is now the bit of the business which you are best placed into.

[00:39:49] Alexander Gilmanov: Yes. I think the key for scaling is focus. Whenever the revenue allows, whenever project scale allows, I like to identify things that were shared, things that one person combined, maybe two projects or two different roles, and to hire people that would do just one thing with 100% focus.

I am now maybe even on the third level of abstraction, third layer as developer. Developers call this like abstraction layer. So I’m managers, above managers, above managers. And we do have different role names in the company, like product owners, product managers, team leads. We also try to, when possible, maybe separate people management from processes management, because different mindsets are needed for those.

It’s great when one person can combine both. Many people are great at that. Sometimes it’s better to give the processes management to person who really likes the admin stuff, and people management to someone who is an extrovert, and is just great with people naturally, without some tension. Because for me still, I’m very introverted. Dealing with people still comes with a certain tension for me.

[00:41:03] Nathan Wrigley: I’d like to say a big, thanks to Alexander for talking with me on the jukebox podcast today. Don’t forget that the conversation will continue next week, where we explore some of the practical steps of growing a business.

On the podcast today we have Alexander Gilmanov.

Alex comes to us today from Belgrade, Serbia. He’s a full-stack developer with a rich heritage of freelance and agency work. His company officially launched in 2014, and they’ve continued work with clients, as well as creating a range of WordPress plugins, and their own SaaS apps, mainly in the online booking space.

Slightly unusually for this podcast I decided to break the content up into two parts. You’ll hear the first part today and part two will be coming out in the next episode.

If you’re a developer and are in the weeds of writing code, perhaps you’ve thought about a change of direction. This could be changing the place where you work, but it could also mean starting an agency and moving towards a more managerial role. This is what Alexander did, and this next podcast charts his journey. The highs and the lows, the epiphanies and the moments of regret.

We explore Alexander’s transition from hands-on coding to strategic management. He shares insights into his initial roles, where he juggled multiple tasks and managed client expectations as a freelancer. This foundation not only honed his technical skills but also prepared him for the complexities of leading a business.

We talk about how Alexander’s management style has evolved over the years. Starting out, he faced the typical challenges of delegation and supervising a growing team, trying to understand individual personalities and communication styles to create a functional working environment. His approach emphasises the need for breaking down large tasks into smaller, more achievable goals, a method that has proven instrumental in managing both projects and people effectively.

We also discuss the critical role of autonomy in the workplace, particularly how Alexander has learned to trust and empower his employees based on their experience levels, leading to greater productivity and satisfaction for everyone. He reflects on the key lessons learned from the earlier phase of his career, where he underestimated the importance of project managers, and how this realisation led him to restructure his business operations to optimise efficiency and output.

It’s a fascinating conversation, and if you’ve wanted to start an agency but have concerns about what that might bring, this episode is for you.

Useful links

wpDataTables

Amelia booking plugin

Trafft

Leave a Reply

Your email address will not be published. Required fields are marked *

Leave a comment

Your email address will not be published. Required fields are marked *