Building a winning engineering team: Workable CTO tells his story

When you talk to Spyros Magiatis about his experience building the engineering team that owns Workable’s recruitment software, you quickly understand that it was like Rome – it didn’t happen in a day. In fact, the roots of the innovative spirit that fuels Workable goes back to pre-Workable times.

Spyros takes a clinical and objective approach to his recruitment and management strategy. He’s realistic about the fact that there’s no perfect solution:

Every structure and every process has its pros and its cons. The thing you need to do is organize it to eliminate the cons as much as possible.

Seeds for engineering team growth

Spyros founded Workable with CEO Nikos Moraitakis in 2012 and now presides as the company’s Chief Technology Officer. The groundwork for Workable was laid in Spyros’ previous capacity as a Software Development Director for another company, hiring 20-25 software engineers in a short time.

He found that hiring so many on such a tight schedule posed a challenge without the right recruitment software.

“I had interviewed over 100 – probably 200 – people and I was not happy at all,” he says. “Maybe it was the implementation we had done, maybe the [recruitment] software was not good – it doesn’t matter. The bottom line was that the tool was very difficult for the hiring manager.”

Even while using an ATS, and therefore not having to resort to spreadsheets and emails, Spyros had his problems in logistics. Picking 20-25 engineers from as many as 200 top candidates, with multiple people in the hiring team coming in at different stages in the process – that’s a recipe for a logistical headache.

“For instance,” he says, “if you were the manager of the person who was the hiring manager, you didn’t have access to the profile of a candidate. So the candidate was coming for the final interview with me, and it wasn’t easy to print their resume – I had to ask the HR assistant of the office to go to the hiring manager and have them print out the resume of the candidates.”

He grins at the memory. “Things like that.”

Every problem has a solution

A popular, yet uncredited, quote goes as follows:

Always look at the solution, not the problem. Learn to focus on what will give results.

Spyros has applied that philosophy to his work from day one.

The desired result he focused on was to fill more positions with better candidates in a shorter time. Not only was it helpful for him to have a solution that delivered that result, it was a huge business opportunity for him and Nikos.

“You know the story after that,” Spyros says. “It kind of took off and then I had to start all over again and build a new engineering team for Workable. This time, fortunately, it was with a better tool in my hand.”

That tool – the Workable software – ultimately evolved into today’s hiring platform used by thousands of companies around the world. Of course, Spyros used it to build a team of about 100 engineers today from an initial team of just three – Spyros himself being one of them.

Too much talk, not enough action

The growth over the span of just a few years – at one point, growing from those first three in 2012 to nearly 50 a few years later in 2015 – meant new challenges. With so many people in one department, Spyros soon learned, new problems surfaced in the management of that engineering team: using up valuable time and resources in meetings and not enough in the actual building of the product itself.

“With 15 people in the same room just [for each] to give a status update, it took almost an hour and you were only there to speak for a few minutes but had to stay for the rest of the update,” Spyros says.

“So, we were wasting a lot of time in meetings. The whole process was slow.”

Again, Spyros focused on the desired outcome, not the problem: spend less time in meetings and more time dedicated to the job at hand.

At that point, we decided to make big changes, and change the structure of the team. Instead of having one big team, we broke it into smaller teams.

He introduced a system where each team would have a product manager and designers. “And then we started hiring for all these different teams.”

So, how many people for each team?

“In theory, the magic number is seven, and in my experience, that’s accurate,” he says.

Cogs in the big machine

A huge positive of working in a startup is the chance to be part of an exciting new idea and work with others in bringing this idea to reality. Startup employees can share in the success of the company and be proud of their own role in that. Growth opportunities are as ripe for the employee as they are for the company itself, and that’s also a huge appeal of working in a company that’s surging out of the gates armed with fresh funding.

But when a company such as Workable grows rapidly, particularly in one department such as Spyros’ engineering team, there’s the danger of a “cog in the machine” feel for employees – particularly when it’s in developing software, an area that often requires extensive collaboration without much room for variance from the task at hand.

Ultimately, you have to organize the creative brains behind the software – your engineering team – into smaller teams, to keep them stimulated and engaged. “Otherwise,” Spyros says, “you become one of these big companies that move slowly and don’t innovate at all.”

Spyros recognized that problem as his own team grew. “I believe we crossed a second threshold a few months ago. We’re now at almost 100 people. And even the previous scheme of having five smaller teams was not working anymore.”

As before, he started working on a new solution: He added another layer to the existing larger team based on Spotify’s agile engineering model, which has been lauded as a pioneering solution for the problems facing many fast-growing startups. The Spotify model emphasizes breaking up departments into teams, squads, and tribes with emphasis on autonomy while remaining aligned at the same time. More so, employees remain engaged at a high level and stick around for a longer time.

Spyros applied this model to his own process. “Now, we have teams of teams in the engineering department.” Workable’s engineering team now has four tribes with two to three squads of 7-10 engineers each.

Each squad has a visual designer, UI designer, a product manager, two front-end developers and two back-end developers. That’s the ideal team structure in my opinion.

That helps break down the jobs between specific engineering squads and helps in the planning of the product road map. “Let’s say we have a tribe working on recruitment marketing. We have smaller teams and squads that do a very specific part of recruitment marketing.”

“Yet,” he adds, “they essentially belong in the same family of features.”

In essence, instead of being a seemingly insignificant cog in the machine, they can take pride in their individual contribution to the company’s overall success.

Engineers can then see the project from beginning to end – in direct contrast with Henry Ford’s once-innovative assembly-line structure designed for mass production of his automobile. Those engineers then have ownership of the work. This allows for greater and deeper focus on specific projects with smaller teams for each – giving individual engineers an opportunity to feel greater ownership of their own work, giving their role more meaning than if they were working in a factory environment such as Ford’s.

“It’s good for team morale,” says Spyros. “They know what they’re building, why they’re building it. [The squads] work together for long periods so you don’t change projects every few weeks.”

And you have this feeling of fulfillment when you deliver something. Those are very important aspects of the work.

Now the engineering tribes have different uniforms

Of course, that solution above meant another challenge. In this case, Spyros saw new issues in the collaboration across teams – again significant when you require a healthy blend of dedication to arcane details with innovation and creativity in software development. How do you solve this?

In short: consistency is the key.

“You want engineers to be independent and have the flexibility to do their work,” Spyros says, emphasizing that it’s those engineers who know best how to do what they think is best for the product they’ve built. “But at the end of the day, they are all part of the same platform, so you want them to have some consistency in the way they use programming languages, frameworks, tools, and so on.”

So, again referring to the Spotify model, you also need a horizontal structure, Spyros says, where everyone of a single specialty – for instance, front-end or UI developers – are part of a “loose” team that doesn’t have a very specific road map to deliver. Rather, they meet once or twice a month to make sure that knowledge is shared and to discuss how things should be done regardless of which squad they belong to.

“And then, you need to deliver some features that require the collaboration of more than one squad,” Spyros explains, citing the team behind Workable’s Facebook advertising feature as an example. “This team needs the help of the data science team to build the algorithms that do the right targeting, that helps them create liquidity that targets the right audience, and so on and so forth.”

To pull all that together, there needs to be another layer of regular meetings. This, he says, is where all the team leaders meet regularly to coordinate the work across teams.

“Now you have this matrix organization with the squads and chapters, and all these things add some level of complexity.”

Yes, it’s more meetings, Spyros admits, but they’re more focused and results-oriented. “You do that in order to achieve the ultimate goal, which is to have the core of your software engineering team as self-sufficient and as flexible as possible.”

A solution for every problem

So, every step of the way, Spyros has found a solution. When recruitment was a challenge because he couldn’t get all the people or information onto the same page, he joined forces with Nikos and started Workable. When rapid hiring led to too-large teams and monotonous meetings, he learned about Spotify’s model of splitting those up into squads and tribes. When that led to poor communication and collaboration between teams, he established a new strategy of meetings.

But with such a rapid growth over the last few years, Spyros hasn’t lost sight of the importance of a strong hiring strategy. At the heart of a successful hiring strategy is to remember that every new hire is a human being who can bring their very best to the company.

“What hasn’t changed at all since day one,” Spyros says, “is that for every new addition to the team, you should make it as if it was the first hire you make. We’ve put a tremendous effort to hire the best for the team we have. We take into account skills, personality, culture fit, everything – but for every single hire we make, we do our best to find the best.”

Spyros notes that it’s easy to forget that spirit in a rapidly growing organization; “What I’ve seen now in bigger companies, as the team grows they tend to believe that they just need extra hands to do the job.”

“But,” Spyros warns, “it doesn’t need to be like that.”

If you manage the team as a team of 80 or 100, then yes, you’re hiring one out of 100. But if you have this small squad of, let’s say, seven people, then you’re actually hiring one out of seven. It’s as if it’s still one of the first hires in your new startup.

Even with 300 employees in offices in five different cities across four countries, that hiring strategy hasn’t changed at all.

“Even as a CTO,” Spyros says, “I still interview the shortlisted candidates in our hiring process. We have a very thorough process – we discuss it a lot with the team leader, the VP of engineering, and the recruiter, and we put a lot of effort into always picking the best.”