STX Next engineers help internal groups mitigate project overflow. Contributions to 4 separate products range from bug fixes and code refactoring to writing automated testing scripts and building new features.
Collaboration with STX Next throughout several challenging engagements ensured both timely conclusions and favorable outcomes. Unexpected turnover is rarely an issue and excessive bureaucracy never undermines critical progress.
“[They have] very energetic and sociable teams, and we get along well.”
Introduce your business and what you do there.
Hogarth is an advertising production company. We specialize in the production and adaptation of advertisements for TV broadcasting, print, and digital media. We’re one of the largest advertising production companies in the world, with over 2,500 employees in 20 countries. Our client base is predominantly made up of large, multinational advertisers.
What challenges were you trying to address with STX Next?
About four years ago, we couldn’t recruit Python developers fast enough and at the scale that we needed in London. That limitation drove the need to find a capable partner. We first engaged STX to provide what development bandwidth was missing, internally. The relationship has grown and evolved from there.
What was the scope of their involvement?
Hogarth develops a fair amount of IT technology that's exposed to our customer base as several products that they can license. We have an extensive product development relationship with these customers.
In the last four years, STX has worked on four enterprise web application products. The majority of the work involved Python software development, testing, and QA, fitting them in with our Agile processes.
Their involvement was similar across all four projects — building new features, bug fixes, refactoring some legacy code, and writing automated tests. We have a hand in defining the composition— the scale, size, and makeup—of the teams, but we don’t have a hand in selecting the individuals. Largely, STX’s interpretation of our requirements governs their recruitment process. The teams have worked out well. It’s fair to say with any relationship like this, it’s a partnership. You have to work with individuals and we do invest a fair amount of time in working with management. STX ensures that we get the most out of our teams, just as we would with our own staff.
At peak capacity, we worked with probably about 40 engineers from STX — about five teams of eight. That would be going back a few years now. Now, it’s more stable, around 25.
How did you come to work with STX Next?
STX Next was competing against was the decision to continue using an increasing number of freelancers in London. Generally, Poland is a very effective offshoring option for companies in the UK. Although the resources are remote, Poland is reasonably close. It’s cost-effective, and the working cultures are similar.
What is the status of this engagement?
We first made contact in July 2013 through email. By August, we were in their office to kick off an extensive project. That fast turnaround and the scale-up period was one of the very impressive things about STX.
Could you share any evidence that would demonstrate the productivity, quality of work, or the impact of the engagement?
Our enterprise DAM product, Zonza, is a successful platform in its own right, and it’s used by a large number of customers in over 100 countries. STX is an integral part of our team, so it’s not solely their success story. What we get from STX is solid, high-quality, dependable development augmentation. I’m not just measuring the success of Zonza. Instead, we measure the success of the relationship based on output, value for money, quality, cultural fit, agility, and responsiveness. Generally speaking, we’re very happy with the way the relationship works.
How did STX Next perform from a project management standpoint?
STX Next integrates directly into our workflow and is familiar with the tools we chose to use from the very beginning. Other than minor changes, we’ve not had to adapt anything to work with a remote team. Since we can’t meet in person the whole time, we’re usually on Skype. We manage projects in JIRA together and share access to our Confluence wiki for knowledge management. Largely, it’s a seamless process. It’s almost as if we were working with local developers.
STX has a system that lets us track time and allocation of that time against jobs. We can look down the list of tasks and see which developer is assigned to what specific user story or task we’ve put into JIRA. It’s very granular in that respect. While it’s something we rarely do, it’s there if we need it.
We haven’t turned over our product management to them at all. We spoke about that once or twice, but it’s quite key to our model that we handle our own product management design and research. We haven’t really turned over our tech or dev ops.
On the whole, team churn is expected since it’s a fast-paced industry. However, we’ve been working with some people at STX since way back in 2013. As a result, they’ve retained a very deep, technical knowledge of the products.
What did you find most impressive about STX Next?
STX Next has very energetic and sociable teams, and we get along well. After working extensively with their teams, we honestly see them as colleagues rather than suppliers. That’s a unique thing, and it has to do with the culture of STX — it’s something they should be proud of.
STX doesn’t have a lot of unnecessary processes or bureaucracy. In contrast, other third-party development companies tend to overload processes. STX doesn’t and we’ve found working with them to be quick and easy — they just get it done.
Are there any areas STX Next could improve?
By and large, we’ve experienced some challenges in the last 4 years, but that’s the case with every organization. For example, acquiring and managing talent, and figuring out the best way to use various methodologies.
When we started working with STX, they had 80 or 90 people in one city. Now, they have over 200 people in 5 cities. As any growing company will experience, they’re having to go through a phase where things aren’t quite so flexible and easy. That means we’re dealing with a different type of organization, and we need to be prepared to work with the company through those issues. Certain changes are harder than others, and we feel that as customers. It’s not a criticism per se, its natural artifact of success and growth.
STX Next prides themselves on being a “Python powerhouse.” To us, that means that STX codes in one language, and that suits us down to the ground most of the time. But more and more, we’re seeing that our requirements require a little more skill diversity. For example, they would need to adopt other tools to support things like DevOps, cloud orchestration, and deployment. They’ve been keen on doing that, even though it’s not strictly straight Python. As they’re a growing company they might not see a need to diversify as much as we’d like them to, but as a technology partner of Hogarth, it’s something that we would encourage and embrace they do.