[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.
Jukebox is a 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 of the struggles of transitioning from a freelancer into an agency manager, but this is part two. 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 into 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. 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 to work with clients as well as creating a range of WordPress plugins and their own SaaS apps, mainly in the online booking space.
Slightly usually for this podcast, I decided to break the content up into two parts. You can hear the first episode, from last week, by going to wptavern.com and searching for episode 120.
Alexander brings a wealth of experience from his journey within the WordPress ecosystem. And this podcast is all about his transitioning from being a freelancer towards a more managerial role, now overseeing a team of 43 employees.
Alexander gets into the intricacies of team management, emphasizing the effective use of tools like Google Suite, Slack, Jira, Notion, Confluence, and GitLab.
We begin with Alexander reflecting upon his evolving role, from an individual contributor, to a leader. Responsible for a midsize team. He talks about the lessons learned along the way, particularly trying to steer clear of negative motivation tactics. He now advocates for positive reinforcement, and fostering a culture of trust and calm, where mistakes are viewed as opportunities for growth.
We then chat about the complexities of balancing automated and human support, and Alexander offers his perspective on managing support requests effectively whilst maintaining high customer satisfaction.
He also explains about the structure of his team, telling us about the benefits of smaller, independent teams, and the need for coordination across departments, such as product development, marketing, and support.
Towards the end, we talk about the WordPress community and Alexander contrast this with other industries, sharing insights from events and conferences that have shaped his approach to team management.
He mentions learning from established companies like Visual Composer or WP Bakery, noting the openness and knowledge sharing that define the WordPress ecosystem.
Finally Alexander underscores the importance of building the right team. He discusses the need to recognize when team members are not a good fit, and now it’s not always realistic to expect every employee to be the perfect fit for his way of doing things. Seeking the right people and learning continuously forms a key part of his managerial philosophy.
If you’re interested in team management and the dynamics of the WordPress community, this episode is for you.
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.
A quick note before we begin, Alexander’s audio was not great at the start, but I’ve done my best to clean it up, and it is more than listenable.
And so, without further delay I bring you Alexander Gilmanov.
I am joined on the podcast once again by Alexander Gilmanov. Hello. How are you doing?
[00:04:43] Alexander Gilmanov: Hi. I’m doing good. How are you?
[00:04:45] Nathan Wrigley: Yeah, really great. So, just to give you some context, dear listener, if you haven’t listened to the previous episode of this podcast, if you’ve missed a week, then it’s probably a good idea to go back because this is part two, kind of unexpectedly actually.
When Alexander and I began our conversation for the podcast, just the intention was to get it all done in one hit. And then the conversation got away from us. I was really interested in it, and so we kept talking. And about halfway through what we intended to cover, I said, let’s do it as a two-parter. So that’s where we’re at, at the moment.
Now, if you were to replay last week’s episode, Alexander will be able to introduce himself. So we won’t go through that whole process again. But what you’ll hear there is Alexander’s journey from being a freelancer, to a more managerial role, and the different things that he went through in his professional journey, in order to get where he is today.
So it was the story of his work life, you could encapsulate it as. And the bit that we never got to was all of the bits and pieces that make up the work life. How to do things, and the decisions that Alexander has made over the years, mistakes that have been made, and things that have been improved and, what have you. So that’s where we’re going to go for the next little episode. Let’s see where this goes to. But firstly, thank you for joining me again. I really appreciate it.
[00:06:05] Alexander Gilmanov: Thank you for having me.
[00:06:07] Nathan Wrigley: Yeah, no, you’re very welcome. So we’ve got you at the point where you are now a project manager. Your career has ended up with a 43, I think you said, person company. It’s a lot of responsibility, and decisions will have been made on that journey. Things will have been done badly, some things will have been done brilliantly.
Let’s just go through the bits and the pieces that you think make you good at your job. Now, I’m not suggesting that you believe yourself to be brilliant at your job or anything, no big headedness here. But what are some of the kernels, the bits of wisdom that you could give us about managing a company, a web agency, with 43 people? And we can go in any direction you like.
[00:06:46] Alexander Gilmanov: While we were phrasing the question, you already mentioned one of the things that was on my mind because, exactly, many things are done, were done maybe wisely. Some things were mistakes, and I can’t consider myself to be a perfect project manager, or founder, or CEO. And I think this is one of the key things, like never to go to any extreme about thinking I’m doing things perfectly, and this is the only way to do it, and not to go to other extreme.
Some people have this tendency of blaming themselves for every mistake, seeing it as failure, complete failure, something that cannot be redone. Almost never in business life it happens like that. But the attitude about the problem sometimes can create bigger problem than the problem itself. So that’s one thing that came to my mind as you were speaking. Try to stay calm about things, about failures, about success. Everything is learning. Everything will pass.
[00:07:42] Nathan Wrigley: Do you have moments where you didn’t obey that little golden rule though? Do you have moments where the anxiety, the stress, I don’t know, the financial consequences of decisions you made, all felt like it was getting a bit too much? I think it’s easy to tell yourself after the fact, be kind to yourself, but reality is, when the clients are not happy, when the projects are not coming to fruition in a timely way, I think it’s all too easy to get into blaming, and anger, and all of those kind of things.
[00:08:10] Alexander Gilmanov: Yes. I think one of my early mistakes, not failure like mistakes, but one of the wrong way of approaching things was using anxiety and fear as a motivator. Because for the first year or two, as I think I mentioned last time, we were depending on each and every project, each client. It created a lot of tension.
I didn’t like it, but when you feel constant stress, stress also gives you some adrenaline, some power, and then you can go for hours and hours. Long term, stress, and fear, and anxiety is a bad motivator, because you don’t feel good about those projects. You don’t create positive energy in the company, you exhaust yourself.
This is something I realised maybe after two years of running the company, and I started restructuring my way of thinking about it. And this is something I would advise entrepreneurs, young founders, and young managers to avoid, because many people tend to do that. They start creating, they start exaggerating potential scenarios, potential problems that might happen.
What happens if this project fails? What happens if this client cancels? We are all doomed then. And let me stay until 2:00 AM today, and do everything possible. Okay, this gives you like short term boost, and short term motivation and fuel, but long term it’s going to exhaust you, and people around you.
[00:09:28] Nathan Wrigley: It can be very easy though to fall into that trap, can’t it? Because I think in some situations, fear, anxiety, and even anger, they are so close at hand. You know, they’re the natural thing that comes out in certain scenarios, especially fear. And to be calm, and to be equanimous, and to have that capability to take a step back and see that probably the doom scenario is not necessarily the scenario that’s going to come out.
And I guess if you, as the leader of the company, are exemplifying what the company stands for, and the way to behave in the company, if that’s the way that you are handling yourself, then in a way you are giving permission to everybody lower down to start to freak out, and believe that everything’s going wrong, and become angry and what have you. So changing that behavior to be more calm, there’ll be a knock on effect with your employees, and probably a lot calmer, and a lot more productive as well.
[00:10:20] Alexander Gilmanov: Yes, exactly. Allowing yourself to make mistakes is, I think, crucial. Being too relaxed about this is also important, but if you are setting expectations for your team, and you are too upset about every single mistake, it’s going to create a lot of stress.
And I did this mistake, as I said. In the early days, I was looking at all the successful examples, successful entrepreneurs, companies that have success stories because all you see online are success stories, and you think they have everything figured out. And then you look at your own company and you see all those things that other people don’t see from the inside, all the problems, maybe things not implemented to 100%, things you know can be done better. And you start blaming yourself and people around you.
For the first years, I also believed in negative motivation too much. I was trying to establish some sort of penalties if something isn’t delivered on time, try to scare people if we are not going to deliver the project by day. I don’t know what’s going to happen with the company, something like that. And this is really a wrong thing, I think now, as of today, to do for a leader, because you’re not creating trust.
People maybe will, as also short term, do more. Maybe they will become more motivated, deliver more, because they’re at fear for their positions. Long term, especially if you’re building products of your own, like deadlines, penalties, trying to scare people, creating anxiety, it’s poison long term. You’re not going to get a team you can trust, team to trust you. You’re not creating the ownership feel you want from your key employees.
[00:11:58] Nathan Wrigley: Yeah, and presumably you are coming to work not feeling great about anything as well. You are at the top of the tree there, and it all looks bad all the way from top to bottom. That’s really interesting though. I’m no psychologist, I don’t really know how the brain reacts to fear, as opposed to positivity.
But my intuition is that, if you are told that you are doing a good job more frequently than you are told that your work is not up to scratch, and there’s this deadline coming, and there’s these penalties you’re about to fall into the trap of receiving, my guess is that you’re just going to enjoy that work experience, and be much more motivated to make the job successful, if you are constantly being praised and rewarded.
[00:12:39] Alexander Gilmanov: Yes, you need the right people. Some people that would be a brilliant employee, for some other company it will not be perfect match for your team, for your project, for the combination that you’re building.
Yes, I wanted to say it’s a good skill you need to learn to identify those people. One of the early mistakes I did, I tried to change people. I tried to either adjust the way we do things as a company to certain people, or try to adjust certain people, and get into something which is really not job of a manager. Change the habits, change the mindset, change the values of a person.
Sometimes when there is no match, the best solution for everyone to part ways and to look for a different person. Also, it’s a common mistake, and I’m also guilty of doing it, is to punish the members that do everything, and punish the rights team members for something the team members haven’t done right. By introducing penalties, by scaring the team in group emails, or something like that, but I don’t do anymore.
[00:13:39] Nathan Wrigley: That’s good to hear. One of the things that you mentioned there was how easy it is to assume that everybody’s getting everything right. To look online, and with the best will in the world, more or less everybody paints best picture of themselves online. Not many people are going to go out there and share all of the things that are going wrong in their business or their life. So you do have this very skewed impression.
You know, if you head onto YouTube and look at management videos, how to manage a web design agency. There’ll be loads of different ideas, and maybe some of them are just not going to fit with your way of doing things. And so that leads me to this next thought, which is, basically, where did you learn to make these changes in the way that you manage things?
Was it an incremental thing? Did you have some sort of guru, or course, or tutor that you went to? Or was it merely a case of, over the years, making mistakes and looking and thinking, okay, I need to change that one little thing, and then another few months goes by and, okay, I need to change that one little thing? Where did you get your inspirations from?
[00:14:38] Alexander Gilmanov: It’s an incremental thing, and it’s an ongoing process. In the early days of transitioning to a manager, I really almost physically felt this hunger for knowledge and mentorship. And I used each and every opportunity I could. I was writing emails, and as we are in the WordPress ecosystem, I can even maybe mention a couple of companies that were really, really helpful.
For example, Visual Composer, WP Bakery, they were my early role model. They were very successful in the marketplaces where we also started selling our plugins. And I was looking up to them. I got the inspiration from their websites, from their social media. And one day I took the courage and wrote them a message through a contact form telling them, I really admire what you do, and I would love to share experiences.
I received an answer from their CEO the next day. And he was very kind, and he answered many questions. And then in one of the WordCamps a couple of years after, I saw that they’re attending it. And, again, I wrote them a message and we got to know each other, and they were all very open about how they do things, what they do right, what they did wrong. And this was something that, it was just one acquaintance, and just one step I took without any hope that someone will answer, which answered a lot of things that on my mind.
Some things were just, you need proof that you’re not doing something wrong. Sometimes you will try doing, let’s say Google ads or Facebook ads, and they don’t produce any results, and you think, maybe I’m just no good at it, maybe others have everything figured out. But then you talk to other, two, three people in the industry, and you see that it’s actually a common thing.
Also Sujay from Brainstorm Force, Astra, I keep mentioning him. Getting to know him was a very insightful experience. He would share many of the things that they have done, that they changed in their journey. Some of the findings that they had, for example, switching from selling plugins on the marketplace, towards selling plugins directly on the website. It was something that was on my mind for years. I thought we just can’t afford it. We don’t have the traffic, we don’t have the demand generation on our end, and we depend so hugely on this marketplace.
And he shared, I think even the revenue numbers, things other people wouldn’t share in different industries. He showed me the, you will drop for certain percentage when you move away from the marketplace, but then it’ll give you a push to build your own customer base, and you can work with them better, you can nurture this better. Eventually we’ll recover, and long-term effect, compound effect, will be much better.
Such interactions were maybe the mentoring sessions. I didn’t have a mentor I could talk to. But also, I tried to use every opportunity I could. I was attending events, I was attending talks, conferences. Sometimes it was just basic stuff like how to do accounting, how to fire people, how to hire people. And from every conferences, webinar, education piece, I took away something.
Sometimes it wasn’t much, the event itself, but I would meet a person that is maybe in a different industry, but at a similar role. And I would ask them like, we are really struggling with managing all this different stuff in the office, bulbs keep going out, and we need paper towels and, I don’t know, toilet paper, things like that. And we already have 15 people, but still there is not enough time to hire full-time office manager.
And at the same time, I feel it’s not wise for me to keep doing all this as a CEO and founder. I’m wasting time for trivial things. They would just give me advice how they maybe hired someone who is combining office management and HR, or accounting. I never thought about it this way.
[00:18:17] Nathan Wrigley: One of the things which I keep coming back to, you may have strong intuitions about this, you may agree, you may disagree, I don’t know. I do think that being a part of an open source project is different in some way. I don’t know what that is, I can’t put my finger on it. But the willingness to communicate with, in some cases, direct competitors is really quite startling.
You know, you go to a major WordCamp, and there will be all these companies who are directly competing against each other. Let’s take hosting, for example, that would be a good example. They’re all there, and obviously they’re pitching their product, and they’ve got their booth, or what have you. But when it’s all over, and the evening rolls around, they’re all having a bit of a chat and sharing information.
There may be some things which are confidential, but I do think that making use of those connections at those kind of events is really useful. And that was very surprising to me when I first turned up to a WordPress event, that all of these competitors would be quite willing to talk through their problems. And you may be not competing with the companies that you’ve mentioned, I’m not entirely sure.
But still very nice of those people, to take time out of their schedule to give you a bit of a leg up, and some tutoring, and some mentoring. And I’m not really sure that that would happen in every kind of industry. Like I said, I don’t know why that is, but I have an intuition that that’s a thing. So I don’t know if you want to comment on that, but I’m just offering it up.
[00:19:45] Alexander Gilmanov: I fully agree. It’s very different in WordPress. I had some experience with the agency work, and with some industries. We had contact with as an agency, and also I attended lots of SaaS conferences. The overall atmosphere is very different. And competitors, they would be, of course, polite and professional towards each other. Last WordCamp in Taipei, there was a picture, like BB Builder, Divi and Elementor walk into a bar, and three guys sharing a beer, it might be even forbidden by corporate policy.
[00:20:17] Nathan Wrigley: I think it would. I really think it would, and so that is curious. The piece of the jigsaw that I can’t quite understand, and I think it’s what makes open source such an interesting and friendly environment. Again, dear listener, if you’re listening to this and you haven’t been to one of these events before, I think it’s worth a shot. You know, if there’s parts of your business that you are not that sure about, obviously you could hop in a contact form and hope like you did, that you would get a reply.
But turning up to some of these events, and seeing if anybody in the room has had the same experience, or is trying to figure out the same thing that you are, is really, really valuable. We call it the hallway track, and it’s the bit where everybody just hangs out outside of the presentations, and the bits and the pieces that have been organised.
Okay, let’s move on to some of the things that you’ve shared. Now, I said in the last episode that Alexander had created this Google Doc, not necessarily for me, but he shared it with me, and it was really a dumping ground, I think you’d explained, you were just letting your thoughts out into text. And I’m going to sort of latch onto a few bits and pieces.
So this is some of the process stuff, some of the things that you’ve figured make your business run more smoothly. And one of the things which is right at the top, and I think you mentioned this quite a few times, making sure that your projects and your products are always with the target audience in mind.
Now, I know that’s easy to say, right? Okay, always think about the audience, we must think about the audience. That’s obvious, right? Tell me about that. Why have you put that as right at the top, and you keep repeating it? What’s going on there?
[00:21:46] Alexander Gilmanov: It’s sort of a mantra, I think every product builder needs to return to. Everybody knows that. I think every product company would have, like we are not building it for beautiful UX. We are not building it for ourselves, we are building it for the end customer. And the end customer, as they say, they don’t want to buy a drill, they want to put a picture on their wall, or they want holes in their walls.
And because you get carried away by the process, and it’s never ending. I know that I’m sharing this with you like I’m a guru of that, but tomorrow I may get driven away by working with a designer again. So if a large percentage of your customers is telling you that your product is doing something wrong, and you know that it doesn’t, they’re right because you’re building it for them. And it’s so easy, and for different segments it’s so easy to just right it off, especially for support or something like that.
You know that every day you’re going to receive a hundred of new requests, you feel them as never ending. Support agents, it’s a very tough part of our job, and it’s very easy for them to get into that mindset. Those guys keep annoying me, they keep writing these repeating stupid questions. You start seeing them in your head as something, as a crowd of people, and they keep asking the same question, you think they’re all somehow connected. And you need to repeatedly wake yourself up because you act as a company, work for those people, you exist because of those people, and you need to make them happy
[00:23:16] Nathan Wrigley: You know, it’s really interesting because, I’m sure you have done the same thing that I’m about to describe, that you have used some service, product, whatever it may be, and you’ve written in with a suggestion or support, and you get something which feels angry back. It’s jarring, isn’t it?
Very quickly, you have a very negative impression of the company. And all it took was for one employee, who maybe is a bit fed up with their job, or was having a bad day, or whatever that might be, and you are skewed. And I suppose, in a sense, the best company on earth would be a company where you could sell the product and have no users. Nobody would write in. Nobody would need any support. Every feature that you shipped would be welcomed, and everything that you didn’t ship, nobody needed.
But that’s just not how it is. You have users, and unless you’re actually making them the core then, what’s the point? But how do you make sure that you are servicing your users? Is it talking to people at events, people that are using your product? Is it just inspecting the support tickets periodically? What’s the process, which means that you are fairly confident that you are listening to your user base?
[00:24:28] Alexander Gilmanov: It’s one thing where I want to highlight, you never can do it 100% perfect, you just said yourself. And in this part, I don’t want to sound like we have it all figured out.
[00:24:38] Nathan Wrigley: No, I understand, yeah.
[00:24:39] Alexander Gilmanov: We are constantly working on improving it. We know how we would do this in the ideal scenario, but the resources aren’t there yet. We would love to have 24/7 support. We would love to have three tiers of support. We love to have a real time sync between all the departments. And we are going towards this ideal solution but, you know, we also have restrictions.
43 people company is a lot of people, but still not enough for everything to be ideal. And getting back to the question, we try our best to do all of this. We have open channels for people to suggest features, and vote for features. But we also try to be honest with them that, this is not how we determine the roadmap, how we define the roadmap.
Sometimes people get angry. They say, this feature has 800 votes, and it’s still not in the process of development, it doesn’t look like rocket science to build. For example, hotel booking, into the booking plugin that we have. From the outside it doesn’t, but from the inside, when you have all these other things going on, it’s tough to even give estimate on when we start working on this.
So, yes, we have this channel. We are trying to build communities. This is something that we don’t do good enough, and I think we should do a much better job at it. Communities in Facebook, we launched a Discord channel where people can communicate and help each other, even if our support manager is not there.
Maybe they already had question about how to configure something, and then some other user can help. And I’m also in this community, and from time to time I would monitor and see like what are the common frustrations. And I also try to appear at least once per month in this feature vault system, and monitor what’s most requested, what are the frustrations, because unfortunately frustrations will happen. You can’t keep everybody happy, even though we want to.
[00:26:28] Nathan Wrigley: Do you encourage your staff to use your product? So let’s take the example of the booking system, Amelia. Now, I’m guessing that a proportion of your staff will have no need to use a booking plugin, because they’ve already got a job, and they’re not booking out their time, or whatever it may be that that plugin most frequently gets used for.
But I guess, unless you know the ins and outs of that plugin, and the pain points that a real user experiences, you don’t really understand. You haven’t got under the skin of what that thing is, and it’s too easy to just sit there and be the developer. I’m working on the technology, I’m working on the code to make it work, look it works. Yeah, but nobody needs that.
Do you encourage your staff to use it and implement And I know that you’ve got a variety of different booking solutions, as well as a data tables management suite. We’ll put the links in the show notes. So yeah, do you get your staff to use what you produce?
[00:27:20] Alexander Gilmanov: Yes we do. As you said, not all of them need booking solutions. But for example, myself, I have a booking page, where people can book a call with me when needed. By configuring it, found a couple of bugs, and issues, and couple of inconsistencies while developing something, it seemed like a logical scenario, but when I tried to configure it and use it for myself, I saw that, okay, it doesn’t quite follow the thought process.
Also what we do is, all the managerial roles, project managers, team managers, team lead of the project managers, and myself, whenever we receive, and because there are so many channels, every now and then certain support request or comment would reach us, somewhere through the contact form, or in a comment somewhere in the social media or in private messages.
Customer would reach out to us with a support request, or some comment, or some concern. If we have the time, we would try first to answer, and take care of these customers ourselves, because then it helps for example, to keep the hand on the pulse, as we say it. Not necessarily this one customer would have the most typical problem, it helps me to remember what I just said a couple of minutes ago.
We are building this for the customers. They’re not here because of us. We are here because of them, and this is what we do. And then it helps us to see the real use case scenarios, scenarios we would never even think about. Language schools, yoga studios. Many, many different use cases.
Very logical sometimes for them to request a feature we don’t have, and we would never even think about such a feature, because we had a totally different use case in mind when we were building something.
[00:28:57] Nathan Wrigley: Yeah, a room full of 43 developers and associated managers, you’re not going to have all the intuitions, are you? There’s bound to be somebody that comes very left field, and suggests something which, you never know as well, do you? It may be that somebody in a conversation in a Facebook group just says something, and that just launches your business off in a completely different direction, and you can pivot. So I think you’ve got to be open to those things.
Can I just ask, I don’t want to get into this particularly, but you were talking about support there, and some of the mechanisms that you’ve got for support. So just very, very briefly, what do you think about the sort of rising trend to automate support?
More and more I see that, if I go to a website, for a while it was Intercom, that was a new thing. There was that little bubble in the bottom corner and you could type something in, and you would either get a reply over email or you’d get somebody in real time writing.
Now we see this trend towards AI, where the AI tries to be the go-between. I get the feeling that it’s to protect the company from the support burden. Often it’s just to insulate, can we get the answer to them before we need a human involved? But I also have this notion that, for most people they find it quite frustrating. So it’s entirely up to you if you want to answer that or not, but I just thought that was curious.
[00:30:10] Alexander Gilmanov: Yeah, it can be frustrating. And I think the most important part is to always keep the option open to, forward it to a real person. Of course, yeah, that’s the conflict of the paradox, whatever you want to put it. You don’t want to invest too much in tier one support because, indeed, a lot of people don’t want to browse through the data and the knowledge base that is already there.
A lot of frequently asked questions already have a very detailed answer somewhere online, but they don’t want to dig through this, even if it’s two clicks. It’s always easier for them to ask a question. And for this, AI can be pretty good. And it can be really frustrating. But what I would mention there is that, sometimes a real human can be even more frustrating, because sometimes they can get more, I don’t want to say any bad words, but they can give you answers that are even more off than AI would give you.
And with some very large corporations, I don’t want to call the names but, for example, for configuring some pay per click ads, I wanted specific support. And first, I had to wait to be switched from an AI that doesn’t know anything to a real person. And then this person had also completely no idea. They tried to send me the same copy paste template replies, and I wasted an hour of my time.
[00:31:27] Nathan Wrigley: I’m not sure. We’ll have to keep an eye on this debate, but it does seem like that kind of support system is going to the way that things are done in the future.
Okay, so we talked about the relationship between your company and the users. Let’s just turn for the next 10 minutes or so to the sort of structure that you’ve got within your own company, and how you manage that.
We don’t need to go through the evolution of it, but right now you’ve got 43 people. Just tell us what your company looks like, in terms of how you’ve got that cake layered from top right to bottom. Where have you got to? By employee number 43, what does it look like, and how do you have people, working underneath other people? What does it all look like?
[00:32:04] Alexander Gilmanov: An ongoing process. Not to take too much time, I will just share my current take on high level, how we try to structure things. First of all, we try to keep teams at five to seven people maximum, for them to be able to sync with each other. And this is the number, I think everything higher than five is hard for a manager to follow. For one person to know what each and every one team member are doing, if there is 10 people.
At the moment we have product teams and we try to structure those as almost mini businesses, within our overall business. For example, a developer that works on wpDataTables wouldn’t have tasks to deliver on some other products, and the project manager in this team would also only focus on their own product development.
What we still share, to a certain extent, is the support or customer happiness team is shared between three different products, mostly for redundancy when someone is away, or there are so many tickets that the assigned person can’t cover all of them. We need to have redundancies so all the support agents are onboarded to all the products. As we evolve, we want to also have the support team within the product team, so that it would be more or less independent from each other.
And we also share the marketing team. Also not an ideal setup. This is something which is optimal for now, given the resources. I think that it’s perfect if the marketing is also focused on one product only. This is something that is still luxury as of now.
We are also sharing the marketing team at the moment. It’s not an ideal setup. As we go ahead, we would also love to divide the marketing team and merge the different marketing teams with the corresponding product teams, because this is actually the best way to do this. When every person focuses on one role, on one product, then you get the best results.
But this is a luxury you only get with scaling. Yeah, so this is probably the principle we are following now. One manager for five to seven people max. More independence within teams. See what’s the level of decision making independence we can give them. And then some managers that would be responsible for syncing different teams, because customer support, customer happiness has the inputs that the product development needs.
Also, the product development needs to sync with the marketing to market the features, and to the support, so that support would know what are all the new features that we are releasing in the new versions. Yes, and we are sharing naturally the admin part of things like office management, HR, those things. But this is, I think, natural for any company.
[00:34:47] Nathan Wrigley: So if I’ve understood it correctly, you’ve got teams of five to seven developers. That then has a manager.
[00:34:53] Alexander Gilmanov: Five to seven people. This would also include designers, developers.
[00:34:57] Nathan Wrigley: Right, so each of those has a manager, so you’ve got a bunch of those teams, and then those managers then report to, what, another manager, slightly higher up. And then, do those managers then report to you? And then separately you’ve got the marketing and the support teams, who have to communicate with all of those teams, so that they’re aware of what the product actually is on a day-to-day basis, okay. For 43 people, you’re happy with the way that’s going.
Let’s just, very quickly, before we run out of time, because we’re probably approaching the time that we’ve got available. You’ve written down a section of tools that you like, which I think is quite interesting. We don’t really get into this conversation. So, what are some of the things that you are using in the year 2024? Obviously it’ll evolve over time. I’m sure you’re happy to jettison some tools, and adopt new ones as they come out. But where are you at right now? What are the mainstays of your tooling?
[00:35:44] Alexander Gilmanov: Yeah, one note I would probably, one comment I would mention before going into the tools is that, it’s not really about the tools. It’s a mistake many managers and many beginners do, that they think that tool will solve a problem for them. But no, tool can only help you to solve a problem.
[00:36:01] Nathan Wrigley: I will never, ever get over thinking that the tool will solve the problem. I make this mistake multiple times a year. Just get a new tool, and imagine it will fix all the things, and it never does. Anyway, sorry, an aside. You carry on.
[00:36:13] Alexander Gilmanov: We all do this mistake. It’s a nice idea that you install the software, and you don’t have to worry about organising tasks anymore, something like that. So when I just became a manager, I was actually just doing some to-do lists, checklists, and it was sufficient. And I had a higher level checklists, and then drilled down into every point. Every point would have checklists under it.
As of today, 2024, I believe the tools stack is more or less standardised in the industry. We use the Google Suite for docs, for sheets, for emails. We use Slack for real time communication. And sometimes I think if we should maybe reduce using Slack, because it creates sometimes too much of context switching, too many distractions throughout the day, especially for managers. That’s a pain point for managers, that they have so many messages, and people expect them to answer like within 10 minutes. Where is this doc you shared with us on Friday?
We use Jira for tracking the projects. And we use different kind of boards for different projects, because I think every team needs to decide on the process that works for them. We use agile for all projects, but somewhere we use more kanban kind of approach. We have no strict deadlines in terms of two week sprints, and for most projects we use two week sprints. And then we have sprint planning, sprint review, and all that.
Tasks are estimated in story points. Probably you’re familiar with agile scrum and with all this methodology. And it then also helps with the estimating, with reporting, with looking back at how many story points every release had.
We are using some of the Confluence, but actually for longer term, structured kind of project, and team documentation, we use Notion. It’s a very nice, very handy tool for that.
And we have different layers like company policies, team structure, product related assets, product related standards, coding standards, marketing standards. Whenever we figure out an SOP, we put it there, we all know this is the app we use, and everything is in there. And it’s very helpful for onboarding new guys, because before that we had all those chaotic Google Docs folders, and every time we had to remember where to look for those, and now everything is in one place.
What else do we use? There are tools we use here and there, like Discord for communities. Those are more task relevant tools, like for Google ads, Facebook ads, we use some of downloadable software to monitor and track, but this is less relevant for project management.
But for project management, I think Jira is the most important part. And we use GitLab for developers. It’s connected to all the servers, to the continuous integration, continuous deployment process, and to Jira. Whenever something is pushed for a certain task, Jira has a reference to it. Yeah, I think from the major software all of us use, that would be it. But as I said, it’s really about, really not about the tools.
[00:39:09] Nathan Wrigley: Exactly right. It really isn’t about the tools. Also curious that you have selected what many other teams have selected. There are definitely some sort of star players out there, in those project management software, and things like that. They’re popular for a reason. But I think trying to wrangle the communication between a growing team, especially when you’re trying to onboard people, really a difficult thing to do. It’s almost impossible to keep everybody on the page.
I share your frustration with Slack. One of the things that I find difficult about Slack is just being able to keep up with something if you’ve had a day off or something. You know, you’ve suddenly got this linear feed of information, you’ve got to scroll right up there, and the expectation is the link that was buried in some threaded comment you should have seen and, well, I didn’t see it, I’m really sorry about that.
I think probably we’ve gone through all of the different bits and the pieces that I wanted to go through. I am so appreciative of the amount of time that you’ve given to me. Enormous thanks.
The other thing that I would like to say is, what’s coming out of the conversation that we’ve had, I think is that, you view this as a journey. There’s no actual destination here, well, maybe there is. When you are 65 years old or something, and you are finally wishing to retire. But this whole process is just a constant process of tweaking, changing, modifying, taking people on for different roles, trying things out, forgiving yourself when they go wrong. And I’ve learned a lot from all of the different things that you’ve said to me over the last couple of hours.
As I said, the show notes will be able to, well, you’ll be able to use the show notes to track down any of the links for anything that Alexander has mentioned.
Just before we go, Alexander, do you want to drop once more where people can find you? I know we did this in the last episode, but we might as well do it again before we round off.
[00:40:47] Alexander Gilmanov: Yeah, I’m most active in LinkedIn, so you can always find me there. And I’m happy to connect if you have a question, concern, comment, please contact me.
[00:40:55] Nathan Wrigley: Okay, I will put that in the show notes. Thank you so much for chatting to me. I really have enjoyed this conversation, and I appreciate your time. Thank you very much.
[00:41:03] Alexander Gilmanov: Thank you. And it’s actually very interesting to share my thoughts, and to structure my thoughts. It helps me also to iterate and reflect on all those things. Thank you very much.
