Being a Manager and Leader: Interview with Alex Sukhenko, CTO at Salsa Labs
What makes a good technical leader? And why is working in a small company often more interesting than being part of a large corporation? Do you need to apply a development methodology? We discussed these questions with Alex Sukhenko, CTO at Salsa Labs, an SaaS company that provides fundraising software to nonprofit organizations.
Manager and leader
Before joining Salsa in 2012, Alex transitioned from developer to senior executive level in various companies. This gave him a broad vision of all aspects of a technology company.
“I understand SaaS companies, how they plug into sales, how to plug those sales into a generic perspective, into marketing, how the product management works, how it feeds the engine, how to get developers to actually, run the manufacturing line, make sure that it comes out with some sense of quality, and then how to power everything, co-location service to the more modern cloud services.”
The pace at which small companies grow is exponentially faster than that of the bigger and slower companies, mostly because of bureaucratic politics. Alex says that in addition to operational, product-development, and quality aspects, small companies often try to sell ahead of what they have and build roadmaps to be competitive. And this is the reason why Alex likes small companies.
Being CTO of a technology company comes a whole host of responsibilities. Alex highlights the following:
- defining what the company needs to build,
- building the actual software,
- making sure that what’s built is of high enough quality to be deployed and used in a customer setting,
- looking for efficiencies,
- managing expenses,
- choosing investments to trade off in relation to everything else that’s going on in the company, and
- increasing or decreasing the R&D pool so that the company can add to or take away from sales and marketing, for example, and maintain the balance there.
In addition, the CTO communicates with investors and has to make sure they see progress and continue their investment, or even acquire the company.
However, the CTO is not just a manager; they should be able to show leadership qualities to fix problems quickly when they arise.
“When those things happen, depending on the severity of them I’ll jump in on the firefights, in the video calls. I’ve gone 24-plus hours on some of these things, where I typically don’t anticipate doing something like that, but I’ll stay with the guys until it’s fixed and help sort it out, prioritize, argue, and direct the focus. I think the guys appreciate that, as opposed to asking ‘When is it fixed, when is it fixed?’”
It’s very important for the CTO to build credibility with the development team because sometimes they need to push hard to keep to timelines, or even get somewhat aggressive with people who are turning out poor-quality work. The CTO helps the team understand the requirements, priorities, and business value of what is being done.
“You have to make sure your staff understands why you’re looking at doing something, or if you’re not fixing the technical debt and really focusing on new stuff, they should know that you have good intentions and plan to come back to it.”
Alex argues that the CTO should step in to deal with code and technology from time to time. A CTO who is new to the company can take advantage of diving into the code and trying to figure out what’s there; however, Alex doesn’t think that this is necessary.
“It could be an indicator of not being a good manager or not having a good team that you can trust. I don’t have the ability today to deal with code, but I can go to some of my people, ask questions, and get answers. I may add a week to what he tells me, or see if he really thinks the things through. My assumptions are certainly not that simple, there’s a lot more complexity in it.”
Alex says that he is used to discussing different challenges with the team in front of a whiteboard. And those whiteboard discussions have become very valuable.
Do you need processes?
Which methodology is best for software development? Should you use two- or four-week sprints? Or is it better not to worry about processes? Alex says that all depends on the situation.
“If you look at it from a generic perspective of just [the] development life cycle—having some type of peer review, having some type of QA, UAT check-off—it makes a lot of sense as long as everything is done correctly. You need to have an opportunity to catch certain things and maintain certain architectural standards.”
Alex explains that they once faced a problem that led to all kinds of issues. Peer review should have caught it, but it was missed.
“Even with a process in place it doesn’t mean it’s going to solve all the problems, but at least you have a list to check that things make sense. Then if you miss something you can at least point back and say, ‘This is how we should have done it,’ and have the best intentions.”
From the other side, very formal requirements may disconnect everybody instead of getting them together in one room. Alex believes that it’s very important to get everybody together—product managers, developers, and QAs—in one room to discuss the tasks, ask questions, and put everything together, instead of sticking to rigid requirements that turn into test cases. Even if the team is dispersed, video calls might help people to gather in the same place.
“That seems to have [become] a much better way to do business when it comes to developing now and making changes [in real time].”
The length of sprints also depends on circumstances. At Salsa, they follow a “type of Agile methodology.” They started with one-week sprints, but some changes, such as integrations, require much more time. Alex says that they have also tried six-week sprints.
“We’ve gone from the extreme of two weeks being too small to [six weeks] being too big. Sprints become too heavy, as opposed to being too light before.”
As a result, they moved to four-week sprints.
“If you really say that you’re going to do something and it has to be very process oriented, but it doesn’t work, then you have to look at every situation and see what happens and make an adjustment. Over time you’ve got to constantly [make] these changes to see where you are based on the maturity of your team and your service and your company. So it definitely depends.”