Blended Teams

In an ever-changing technological landscape, the art of assembling the perfect ensemble of minds and talents stands as crucial as choosing the right tools for the task at hand. Yet, distilling that alchemic mixture of skills and personalities is no simple feat. This exploration takes us deep into the intricacies of hiring for the technical tapestry — those developers, architects, and engineers who serve as the backbone of every software endeavour. These insights are forged from over a decade of my own experience — hiring for my software development services firm, and orchestrating teams for numerous projects with varying demands. Though our journey may be lengthy, it tackles the intricacies of hiring challenges head-on, proposing a multi-faceted solution that incorporates varied skill levels and spans geographical horizons.

Ah, the mythical quest for the perfect tech hire — a tale as old as the first “Hello, World!” Yet, it seems harder to find that prized developer than it is to find Waldo in a candy cane factory. You go to your favourite job board, post an ad for a Senior Full-stack Developer or an Angular wizard, and voila! Your inbox is flooded with more CVs than a cat has lives. Initially, it’s a confidence booster; you start thinking, “Wow, everyone wants to work with us!” But then reality checks in: after the first screening for must-have skills, your pool of 100+ applicants dwindles down to a “mighty” 10.

You roll up your sleeves, dive into the CVs, and discover that out of these 10, maybe one or two could potentially fit the role. But let’s be honest, even Cinderella’s slipper had a better success rate. It’s not just that they’re not the “perfect” fit, they’re more like a mismatched pair of socks: close but no cigar. One guy knows Angular like the back of his hand but doesn’t know anything about Docker and doesn’t think a frontend developer should learn it. Another one’s last brush with modern technology was updating his iPhone.

As someone who’s been in the trenches of tech hiring, I have my own tale of woe to share. Picture this: I was tasked with hiring a 16-member frontend development team for a high-stakes European project. The company had collected CVs and arranged about a dozen interviews. You’d think, ‘Surely we’ll find someone,’ right? Wrong. By the end of that gruelling interview cycle, we hadn’t extended a single offer. The skill level just didn’t match our expectations. There I was, the primary interviewer, feeling like the bone of contention as the clock ticked down to our initial deadline. Faced with a fast-approaching timeline, we had to extend the deadline and get creative. After our original plan hit a wall, we found ourselves doing what could best be described as tech resource juggling — sending some of our backend devs to the frontend lines, just to keep the project moving. And guess what? This very situation serves as a prime example of why the concept of ‘Blended Teams’ is not just a buzzword but a real, actionable strategy. But hold your horses, we’ll delve into what exactly ‘Blended Teams’ are a bit later in this article. Trust me, it’s worth the wait.

Why does this happen? Well, the tech world evolves faster than a caffeine-fueled coder on a deadline. By the time you’ve written down your job requirements, there’s a good chance half of them are already outdated. And let’s not even talk about the tech giants — those big, talent-hungry behemoths with bottomless pockets. They’re exceptional at identifying and recruiting top tech talent, which can sometimes give the impression that they’ve emptied the talent pool. However, that’s far from the truth. For companies where software development isn’t the primary focus, there’s still a wealth of untapped talent out there — it’s just a matter of having the right techniques to find and reel them in.

Lack of talent to hire right candidates is another big problem. Many companies simply lack the technical leaders who can judge a candidate’s skills based on their CV and interviews. This often leads to some unfortunate hires — like finding out your new ‘Senior Developer’ thinks Agile is a yoga pose.

So here we are, lost in a labyrinth of skill mismatches, rapid technological changes, and an ever-shrinking talent pool. But fret not, for all is not lost; read on to discover how we can navigate this treacherous landscape.

Navigating the challenges of hiring, we often make mistakes. One common error is the belief that our projects are so complex, they can only be handled by the best of the best. While expertise is essential, it’s not the whole equation. You’ll likely find that in most teams, regardless of size, there are usually one or two standout techies, let’s call them “Timo.” When Timo goes on vacation and an incident occurs (thank you, Murphy’s Law), everyone starts running in circles. Now you’re left wondering, where are all the experts you thought you hired?

Let’s entertain the notion for a moment that we could, in fact, hire a team comprised entirely of Timos. Superstars, every single one of them. While this might sound like a dream scenario to some, in reality, it could quickly devolve into a corporate version of ‘Game of Thrones.’ The more seasoned and strong-willed team members you have, the more potential there is for internal disputes and ego clashes. I can almost hear the debates now: one camp staunchly advocating for Java, while the other swears by Typescript. Both are ‘right,’ but inevitably, one is ‘more right’ than the other.

This creates a tug-of-war of ideologies, where instead of focusing on getting things done, these heavy lifters are locked in a battle to prove their approach is the superior one. And let’s be honest; even the most seasoned professionals can sometimes possess significant egos and become entrenched in their ways, making compromise challenging. So, a team of all Timos is not only unlikely but also counterproductive. It shifts the focus from collaborative problem-solving to political manoeuvring, undermining the very essence of teamwork.

Before we move on, there’s one last type of Timo to be wary of: the ‘False Timo.’ These are individuals who present themselves as the go-to tech gurus, but when push comes to shove, they can’t deliver. In my years of experience, I’ve encountered these kinds of ‘wolves in Timo’s clothing,’ and let me tell you, they’re a ticking time bomb on any team.

Based on my experience, for a balanced, effective team, you’d only want about 25% of your crew to be Timo. This isn’t related to the complexity of your project, but rather, the size of your team. Enter the concept of a “blended team,” which we’ll explore in more depth later.

Now, what about the remaining 75%? Are they just benchwarmers? Absolutely not. In Timo’s absence, issues do get resolved, albeit by a collective effort from two or three other team members. They may take a bit more time, they may not have the immediate confidence, but in the end, they fix the problem. These are the members that should make up about 50% of your blended team. They’re enthusiastic about learning, good at following commands, and look up to Timo with great respect, aspiring to reach that level one day. They might not be there yet, but their contribution is invaluable. They are not superstars, but they’re the backbone of your team, stepping in when needed, eager to learn, and getting things done — even if it’s at a slightly slower pace. This mix of different skills and readiness levels is what makes a blended team not just functional, but exceptionally effective.

For instance, consider a recent situation at a company that had a dedicated CI/CD team running on vanilla Kubernetes. Everything was smooth sailing until one day, production faced an unexpected issue. A critical incident was flagged to the CI/CD team, and that’s when everyone realised they were missing their decision-maker, their Timo. He was in the middle of a 6-week vacation, and nobody else had a clue about how to approach the issue.

Management went into panic mode and convened an urgent meeting. The air was thick with tension and uncertainty. Without their guiding star, the team felt somewhat paralysed. However, a pair of enthusiastic team members took it upon themselves to solve the problem. They never discovered the root cause of the issue, but through trial and error, they redeployed the entire cluster, effectively resolving the issue. When Timo returned from vacation, it was too late to diagnose what had happened, but the incident had already been seared into the company’s collective memory.

I bet many of you reading this can think back to similar situations in your own professional lives. It’s moments like these that highlight the importance of having a well-rounded, blended team. This real-life anecdote underscores the idea that while you may have Timos in your organization who serve as lighthouses, it’s the collective efforts of the entire crew that keep the ship from sinking.

By now, you might be wondering about the final 25% of the team — those who are just starting their journeys in the tech world. Don’t underestimate their impact; they’re the hidden gems that can make a lasting difference. These are junior developers, typically with little to no experience. They come in eager to learn and adapt to the technologies you’re using. Not only are they cost-effective, but they’re also more likely to stay with the company for the long haul, as they’re just entering the market and fewer companies are willing to invest in them. But invest wisely, as these young minds are the future leaders in making.

Another glaring mistake I often see is the insistence on geographical cohesion. Companies, even those at the cutting edge of technology, demand their teams to be in the same city, meeting in person a specified number of times per week or month. They label this as ‘team building.’ I couldn’t disagree more with this archaic approach. Just the other day, I was watching a construction crew work on my street. Each individual had a specific task, whether it was laying cement, placing bricks, or hammering them into place. It occurred to me: this is precisely how we construct software, except we don’t need to be in arm’s reach to do it effectively. Yes, even in pair programming, you could be continents apart.

During the COVID-19 pandemic, we all adapted to remote work, and let me hazard a guess — software developers were probably among the least impacted. Scrum masters bemoan the inability to organise team-building events in a remote setting. But let’s be real, there are ample ways to keep a team motivated and happy in a digital world. Team members naturally gravitate towards like-minded colleagues and often form strong bonds without the need for forced company ‘perks.’ If you don’t agree, that’s fine, keep doing what you’re doing and enjoy the déjà vu of recurring issues. Somewhere deep down, you’ll know I’m right. 😏

Companies that have embraced remote work for over a decade reap numerous benefits. Not only do they save on overhead costs, but they also vastly widen their talent pool, increasing the odds of finding those critical Timos for their blended teams.

In the context of software development, a blended team is not just a mix of junior and senior developers but a rich tapestry of skills, experience levels, and even locations. The team could be comprised of front-end gurus, back-end specialists, seasoned architects, cloud experts, and even a few generalists who can bridge gaps. Additionally, a blended team often includes members who work in different time zones or come from varied cultural backgrounds.

Imagine a finely tuned orchestra, where each musician excels in their particular instrument, but the real magic happens when they all play in harmony. That’s what a blended team in the tech industry aims to achieve.

In a well-balanced blended team, consider the rule of 25–50–25. This means that around 25% of the team is composed of seasoned experts, like our metaphorical concertmasters in the orchestra. These are your Tech Leads or Senior Architects — people who can provide a solid foundation and guide the team with their vast experience. They’re the ones who tackle the most complex problems and make high-impact decisions.

The largest segment — 50% — is made up of what we can charmingly call the “Core Performers.” These are your mid-level developers who handle the bulk of the day-to-day coding tasks. They’re the rhythm section and the strings, reliably playing the essential notes that form the backbone of the performance. With sufficient experience under their belts, they can also mentor junior team members while absorbing wisdom from the senior echelons.

Finally, the remaining 25% are the “Rising Stars,” the junior developers carefully chosen to grow into future lead roles. Don’t underestimate the value they bring; they handle foundational tasks that are crucial for project success, freeing up more experienced team members to focus on complex issues. They’re like the percussion section, adding highlights and flourishes that make the overall performance shine. Moreover, their eagerness to learn makes them valuable assets for long-term growth. They can be mentored by the Core Performers, creating a cycle of continuous learning and team synergy.

In considering the composition of blended teams, it’s worth noting that up to 50% of the team can be sourced from offshore or remote locations. This approach offers a flexible solution for various challenges, such as budget constraints or a local talent shortage. Remote developers can effectively bridge these gaps, offering specialized skills at a potentially lower cost.

Moreover, the decision to hire remotely isn’t restricted to mid-level developers. However, my experience suggests that this segment of the workforce is a safer bet when considering offshore or outsourced employees. They usually have enough experience to work independently, yet their roles are generally well-defined, making them easier to replace if necessary. This flexibility becomes particularly valuable when we consider that remote work arrangements can be temporary or project-based.

While this approach offers increased flexibility and scalability, I prefer to source the 25% segment — comprising junior or entry-level positions — locally. These individuals are more than just resources; they’re long-term investments for the company. They bring fresh perspectives and energy to the team, and the plan is for them to eventually take on greater responsibilities as they learn and grow. Our more seasoned team members play a critical role in mentoring these newer hires, setting the stage for their future contributions to the company. By sourcing these roles locally, we invest in a talent pipeline that is closely aligned with our organizational culture and long-term objectives.

While the 25–50–25 rule serves as a useful guideline for structuring blended teams, it’s important to emphasize that there is no one-size-fits-all blueprint. The proportion of team members across different experience levels may require minor adjustments depending on the project’s stage. For example, a team in the early stages of a project might benefit from a higher concentration of senior-level contributors, while a project nearing completion could require more mid-level developers for execution and delivery. The framework is meant to be adaptable, accommodating the unique variables each project presents.

Interestingly, you might notice that I haven’t mentioned project complexity as a factor in this article. That’s intentional. In my experience, all projects come with their own set of complexities, regardless of their size or domain. I’ve never sat in a planning meeting where a project was described as simple, easy, or straightforward. The notion of a “simple project” is, for the most part, a myth. However, that doesn’t mean solutions have to be complex. Often, the most effective solutions are elegantly simple, cutting through the perceived complexity to address the heart of a challenge. And that’s where the value of a well-structured, blended team really shines — leveraging a range of experiences and perspectives to find those simple, yet impactful, solutions.

In closing, building a good software development team is all about balance. You need a mix of experienced people and newcomers, working both in-office and remotely. The 25–50–25 rule is a good starting point, but it’s not set in stone. You can tweak it based on what your project needs at any given time.