discussing-engineering-leadership-what-makes-an-effective-engineering-leader-replay-2021-07-08 from Evolution Recruitment Solutions on Vimeo.
And so there’s, there’s always differences as we as we’re big organisations together, but I think what we’ve done is keep our engineering and product functions relatively separate. So we can go and win the markets we work in. Something we have brought together, a good niche to sort of in the training space as well, to keep them up is our global hackathons. So we run one every six months. And I think we talked about engaging people in these initiatives but we’ve changed a little bit the focus to bring in the business a bit as well as just engineering. We did a lot of work on selling the benefits to people, focusing on the why is this going to be good for you, and then giving each of those individual contributors time to get involved, and space in their schedules for the hackathon for the time around it, and for prepping for it and for like, seeing like the impact afterwards. Selling the benefits gets people involved, and also just giving them the space to actually do those things really does as well.
We’re fully remote, we don’t have any offices. With respect to hackathons – we don’t even kind of have those yet because we’re such a small company doing deliveries fast. But some of the things I think that are important here are getting the team to understand that if they share their knowledge to the more junior members things will go faster, right? Everyone at Hopin is really keen to deliver more product, and we’re excited to get it out there. So it helps I find if we’ve got a budget for everyone to go and get their own training. So I encourage people to spend it on whatever they want, whether it’s conferences or online learning whatever. We follow fairly common design principles like pair programming at times to help people get through a tricky problem and we have a knowledge share every two weeks, which is really just a chance for the team to get together and sort of say; Hey, I was working on this last week, and I found this unique solution, or I uncovered this new library.
Response from Yuan
So we have the core software product with developer. Either you have a roadmap and then you put the priority based on the marketing side and the customer. With us, however, we have a completely different set of challenges, we often can enter the big tenders some large customer, they have a customer requirement, which is totally new and has nothing to do with core product and can take 3 engineers away for 6 months.
To get around that, what we do is we build up some resources and have a core skill set, and then use a few contractors to partner together. When we those project come along, as long as there’s some business case, and the commercial aspects are verified, we actually often build up a brand new team to work on that. Then comes the challenge of support.
Response from Mark Allen
Well, from from my perspective, we’re not solely based on delivering software as a business, we’re just a small cog in a and a much larger machine. So we have to work in a very fluid way that integrates well into other teams. And so that we can fit into the whole project delivery lifecycle. And naturally, from what we deliver, we’re right at the end of that journey. So a lot of the client perception, a lot of the internal perceptions are all drawn from how we deliver as a software team, because we are the last ones over the line and the last one through the door. So I mean, as James touched on, your on as well. It’s important to gain trust through hitting milestones, by keeping to promises and gaining trust in that way. Because once you start delivering on your core business, your ability to to explore different avenues, etc. You’ve built that trust, you can bring in new ideas, you can bring in new suggestions and new directions. And it’s only once you’ve proven your ability to deliver that core functionality of what you’re delivering within the business, that you kind of get the the ability to move around a bit more.
Response from Oliver
Those individuals will usually start to take away work away from from you as the leader, right? They’ll take responsibility for things and they’ll sort of go off and get done. And they tend to ask the right questions, right. It’s, it’s easy to ask questions, but asking the right questions is a different thing altogether. So they ask these questions, and they’re the right questions. They work well with other people, right? So they show empathy with other team members with other groups. They’re able to show sort of a way to get things done. Sometimes there might be, again, these are things that I would normally do. But if they’re in my team and they’re they’re upping their game, that’s what they’ll be doing. And like, finally, they’re confident in what they know. And what they don’t know. Right, right. It’s important to know, both your strengths and your weaknesses. And then you can work with them on those weaknesses to fill those gaps.
Response from Yuan
you need to identify the person has ambition and their own initiative. Once you make your own career progression, you think that everyone wants to do that. Now, at least in my team, there are people that really like working with the software and the backlog items. They enjoy delivering things, but they don’t have ambition to become a leader. That is absolutely fine.
I think in this model, you’ve really got to think about what you want to do and what path you want to take, right? Do you want to go on being a people leader and manager of managers and growing through that path? And if you do, you have to realise, like, you’re gonna have to step away from the code. Yeah, and you may stay current in your personal time, personal projects, that’s one way to do it. But if you want to stay current in the tech as an active, getting your hands dirty, long term, you probably want to be a technical leader, you might want to go and investigate the individual contributor path, right? Look at your principal architect, you really need to like, look into yourself and sort of make that decision. If you try and do both jobs, you’ll probably just do them both badly.
