ISB Global - Building 'Big Software'? When & How to Scale Your Team
ISB Global Waste & Recycling One

ISB Global - Building 'Big Software' When & How to Scale Your Team

When is the Right Time to Scale the Team? How to Avoid & Manage Growing Pains?

Craig Jones, ISB Global’s Chief Information Officer, regularly contributes to Thought Leadership in IT. In this Thought Piece, he shares his experience of how to scale ‘up’ your team to build big software, offering practical advice and guidance.

No alt text provided for this image

image credit: Photo by Radek Grzybowski on Unsplash

Accepting the Need to Scale

One of the biggest challenges of developing big, complex pieces of software is accepting that a core development team may not be enough to get a product out the door quickly.

Most development teams spend a lot of time writing code and, even they would admit, not a lot of time managing it. This means that when a core development team is then tasked with building big complex software, the risk of winding up with a tangled mess is high.

Many organisations think that they can start by bringing in more developers, to solve this problem. However, there’s practically no way to calculate the ideal number of developers, data modellers, tech leads, DevOps engineers and DBAs for a project in advance. It largely depends on the number of independent subtasks and tasks that must be done, usually in a particular order, e.g. any work on integration and deployment pipelines, merging software changes in code shared by different teams, synchronization, or waiting for the provisioning of resources.

Therefore, it’s dangerous to assume that the same team patterns will be appropriate at every size of product development. In most cases 2 + 2 does not equal 4, teams rarely scale linearly.

Architect the Build Process and Team Structure First

Luckily, Development Managers and Product Owners needn’t necessarily calculate everything upfront if they architected their build process and team structure well.

Defining a modular architecture allows module owners and developers to deal with autonomous tasks and with separate teams. Each module will be able to hire the right number of people to deliver the required number of features. Delineating a product into modules and identifying all the touch points helps any team in the growth and abstraction process.

Keep the Communication Channels Open

Remember though, when your team sizes increase, communication between technology and customer-facing staff tends to decrease meaning that developers may have little to no idea as to what customer facing functional analysts are facing.

Add to this that many organisations take the opportunity to augment teams with experts picked from the global talent pool (while significantly cutting payroll and office costs). As partially outsourced teams become the norm and bring huge benefits, they also further complicate communication.

This means that managing large-scale software development requires well-organized open communication, especially with distributed developers.

Review your existing communication channels and develop a strategy suitable for both in-house and remote workers. For many, COVID 19 has, mostly, prepared teams for remote working. (Personally, the hardest part of this process was replacing the whiteboard. I still have no advice, so if anyone out there does, let me know). And when you’re operating globally, grouping teams in the different locations helps alleviate the time zone problems.

Make Good Decisions Early to Avoid the Worst Growing Pains

Through my experience, I know that by making good decisions early most growing pains can either be avoided or at least feel less painful.

Here’s some of the things you can do to alleviate the pain:

Stay Agile.

Remember elite teams self-regulate. Empowering teams to self-manage will save in the long term.

Hire well and pay more for the right skills, if necessary.

As a company grows, small business attitudes will persist. People tend to hire in their own image. So make sure you look for people with large scale development experience and skills.

Outsource if you need to.

Outsourcing is a great option when building a distributed team due to a lack of internal skills or being overloaded with projects. Outsourcing has many benefits, such as no fixed cost; you only pay for the work you receive for a dedicated project. Moreover, outsourcing lets you scale up and down fast depending on your development requirements.

Scale with purpose.

Before scaling, you need to identify the reason you need additional people on a team. Is your team fully functioning with excellent leadership, and you need more people to increase the capacity? Or are you expanding into new areas with skills and insights that you don’t have? In most cases it’s a little of both.

Maintain the company vision.

Long-term success in scaling a team requires an alignment between what employee’s value and what the organization values. Without this alignment, you’ll have a hard time finding and keeping employees on your new and expanding teams. Agility should also be reflected in your values: “Be prepared to change”.

For example, a small organization may come to value a culture in which employees work together, speak their minds, and come up with great solutions without waiting for someone else to go first.

As this organization begins to grow, they plan on keeping a flat structure, where everyone works autonomously without layers of bureaucracy to slow things down. But as they put this plan into practice, they discover that it’s harder to provide oversight for such a large group, making it difficult for everyone to understand the vision, and for leadership to make corrections. They quickly discover the difference between autonomy and independence. Just because employees can keep working without being monitored doesn’t mean they can make decisions that may affect the trajectory of the group.

So, remember, as you scale your teams, it’s important to recognize the limits of these individual values and support them with effective management structures and guides. Especially when it comes to technical decisions that may have a long-lasting commercial effect.

Articulate Company Values to Maintain Your Culture.

How people within the organisation interact and work with each other can make or break teams at scale, and with teams at scale its harder to identify and react when there is a problem.

In my experience the most effective cultures have a purpose and a direction. Hiring team members that complement other team members rather than hiring clones is a good start. ?Whether you’re hiring a software engineer or a support guy, the job position will have a wide variety of qualifications that make for a successful candidate.

So, instead of basing a job description on a person, take a careful look at the skills and attributes that make the person successful. How do the new hire’s attributes compare with the other members of the team? Do they shore up their teammates’ weaknesses, or do they magnify them?

And finally...

Make Sure you have a Growth Program

Employees should have opportunities to develop their professional and institutional knowledge. Then as teams continue to grow, they develop with their new co-workers’, in the same way the team grows from good to great.

If you’d like to discuss any of the points raised or how to scale your team to build, ‘big software’ please get in touch [email protected] ?

Thanks Craig, love the comment about the difficulty in scaling in a linear way, if only it were that easy!

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了