CLIENT CASE STUDY

Right. They knew they had to invest more in product development. I came in, moved them to current tooling and methodologies, Agile and Scrum supported by Jira, then started growing the team.

About that time, but initially we weren’t bringing on developers. Our first 2 team members from SoftwareSeni were designers.

Then I started our first pod. Our dev pods have 1 internal developer working with 3-4 SoftwareSeni developers. The first pod, it was just a test to see if this was going to be viable, was myself and a single dev from SoftwareSeni.

Our product team is now 3 groups of 20. And those 20 people can work on any area of Funraisin. We’re not a small team, but we’re not large, and we have so many features - stores, newsletters, apps, payments, fitness app integrations - we don’t have the numbers to have “Product Area Pods”.

So my strategy has been to move developers around, move pods around, and give them the time and opportunity to learn the different stacks we use at each point in the platform. It’s a “go slower to go quicker” strategy. You allow for it. This sprint’s feature might take a little longer to implement because the pod hasn’t touched this part of the platform before. But in three months or six months when they end up back here they will have the experience and the knowledge.

In the early days it would be “we're going to add developers”, and then I would interview them myself, and we'd bring them in. We started out with two and we put them into our project development area, not our product development. That's our develop-on-the-platform area. That worked well with those first two, and the interaction was really quite heavy at the start, as you'd expect.

We didn't really have any onboarding material that we could get going, so that's why it was a lot of hand-holding for us - and that wasn't SoftwareSeni, that was us. But as we grew and we got bigger, our commitment with SoftwareSeni and our resource profile grew alongside.

We ended up with 10 people just in project development, and we started utilising the training team at SoftwareSeni. We needed training materials, so they would write the onboarding, and my premise really was, what makes this scalable is that we need SoftwareSeni to be as self-sufficient as possible with the onboardings. Experienced SoftwareSeni staff that have been there a while, they self-onboard, and that self-sufficiency in getting up to speed - that's where we’ve arrived at.

SoftwareSeni have their own onboarding, so they'll go through a SoftwareSeni Funraisin onboarding, and then we have our in-house onboarding. What it's allowed us to do, is strip that away from being a heavy technical onboarding. Our Funraisin onboarding is aimed at the company, what we do, what the product stands for, what we stand for. The SoftwareSeni one is really how do you get up to speed, what are the tools, what's the environment, what's the coding, and they handle all of that.

When we first started, we leaned heavily on a front-end developer and a back-end developer, and we'd balance our teams out. Over the last 18 months we’ve been experimenting on changing that - keep the people we've got, but equip them to be frontend and backend, to be full stack. And SoftwareSeni leads that training.

Our account manager is my go-to. I have a problem or an idea, and I just need to tell them, this is happening, can you help me. And that was the conversation that shifted how we onboard: we're going to continue to add staff, this is going to get quite big, and we're going to run pretty lean on our side, so I need onboarding to be self-sufficient on the SoftwareSeni side as we grow.

We're pretty lucky in that out of the first three developers that started with us, two of them are still with us - and that's heading towards 4 years. They're still here and they've got all of the system knowledge and they've helped grow our onboarding. And then that became the blueprint for when we pulled people into the product teams.

Now when we want to expand our product development team - we use SoftwareSeni to scale. We use the same blueprint: start with a few people, then once we’re ready to add more people into the pod, they’re all in SoftwareSeni’s office, they can bring them onboard and upskill them directly.

It blew me away the first time I went to Jogjakarta. I knew SoftwareSeni was a sizable organisation, but being there hits home - the mechanics and all the things that they do behind the scenes. I think where people look at the relationship wrong is, they'll get one person, and think “we're just getting this one person”.

You go to SoftwareSeni, and it's the training department - you get to see that - and the English lessons that they're running, and the Spark Grad program, which we've taken three or four people through.

It's not just getting a developer, it's getting all that supporting mechanisms behind the scenes - your account manager, your training department, your HR department, and then you've got leadership, like Heryno (Heryno Cheung, Managing Director for Indonesia) and Bagus (Bagus Herdiawan, Technology Director), who lead from a technology perspective.

It’s accelerated it. It’s accelerated everything across the business. It means we can do more with the resources we have. I don’t understand why anyone would cut developer numbers because of AI. It’s just not competitive to reduce headcount.

Just whatever works. Whatever the dev finds that makes them productive. We’re not wedded to any platform, but Copilot is probably the main tool.

No. The SoftwareSeni developers have been solid. They have had no issues with the flexibility that we need from our developers. They show up and they do the work as part of the team. Turnover has never been a problem.

I do make the point of visiting the remote team at SoftwareSeni’s Jogjakarta office every year or so. You can do semi-social activities via video, but meeting in person, for product planning or actual in-person social activities, it boosts team cohesion so much. It’s always worth it and always enjoyable to visit them.