How do you enable an IT organization to support a fast-growing technology company while also building a scalable delivery organization that will last? This was a question asked to me recently and I thought I’d share some of my learnings that I’ve faced for decades now while working with development and management teams at large, fast-paced technologies companies like Salesforce and Splunk. 

First, IT organizations have been at the center of corporate transformation since the beginning of the industry, but it’s important to note that IT organizations have also been transforming themselves as the industry has evolved. Thus, it can feel like an IT organization is changing the tires on a moving car ⎼ entirely possible but challenging.

The following are a few strategies that I’ve used to produce results at scale within a fast-growing company.

1. Product vs Project: Transforming IT for rapid growth and scale requires a pivot from delivering projects to investing and maturing a product portfolio.
2. Agile and DevOps: The benefits of Agile delivery for your SLDC have been well documented, so I won’t go into this here, but there are few practices that I’ve found helpful to mature your Agile delivery.
3. Resource Strategy: Agile requires a fundamental shift from pure outsourcing or managed services to a staff augmentation strategy.

Let’s take a deeper look at these key points: 

Product vs Project 

This isn’t about whether your company provides products or services. It’s about how you view the actual delivery processes within your organization. Projects by nature are temporary endeavors that have a unique set of requirements that need to be delivered within a specific budget with specific skills. Organizations that are purely project-driven tend to have waterfall delivery practices that are constrained by the scope, schedule, and the cost of the project, irrespective of the value being delivered. This means as long as the project is on time, does what was specified in the requirements document, and isn’t over-budget, it’s a success. However, this doesn’t account for whether the right thing was delivered. As a byproduct of these practices, the organization adopts a culture that creates isolated views within their ecosystem that limits the learning opportunities to build competency within the organization for the long term and increases overall delivery time. 

Products, on the other hand, are items or services that serve a customer’s need or want. It’s important to note that I use the term product (tangible) interchangeably with service (intangible) since technically a service can be a product too or at least carry elements of a service. IT organizations that align delivery to products tend to have strategic roadmaps centered around a single product or a group of products that are funded with long-lasting teams that are chartered to drive to the right outcomes for the business. 

Long-lasting teams serve to create deep competencies within the organization which allows the organization to adopt change more rapidly and deliver outcomes faster. Why? All teams need to go through Tuckman’s 5 stages of group development ─ Forming, Storming, Norming, Performing, and Adjourning. However, long-lasting teams centered around one or more products stay in the Performing stage more often than a temporary project team. Think about it, if for every project a new team is formed internally with existing people, consultants, contractors, or any combination of these, it requires people to learn what the objectives are and why, find direction from leaders, build trusted relationships, and understand how to work together effectively. By the time the team has reached the Performing stage the project is over and the project team disbanded. In addition, the knowledge acquired throughout the delivery has moved on to another project or worse, out of the organization all together leaving a competency gap.

Both project and product mindsets have distinct advantages and disadvantages, and to be honest, developing a culture centered around products is easier said than done. However, when your organization adopts a product-first delivery approach, you are telling your stakeholders that you are committed to maturing their business capabilities and investing in your people. At the end of the day, this strategically delivers the right outcomes and strengthens the overall business. 

Agile and DevOps, Not Agile or DevOps

Before we get into the next key point, we need to get clear on Agile and DevOps. These two software development approaches share a similar goal: getting the end-product out as quickly and efficiently as possible without sacrificing quality. 

Agile works toward that goal by using methodologies like Scrum, Kanban and Extreme Programming to deliver short and incremental development cycles. DevOps works toward that goal by combining software development (Dev) with a company’s operations (Ops). It’s less about a process and more about a fundamental change in a company’s culture. The main takeaway here is that Agile and DevOps are complementary.

As discussed above, I like to structure teams around a product or a group of products that support business capabilities. Teams that have a dedicated mission that align to business outcomes will not only drive better results for the business, but tend to take more ownership and accountability than temporary project teams. In terms of Agile, teams should have the flexibility to practice an Agile methodology that works for their product delivery, such as Scrum, Kanban, and/or Extreme Programming. However, I do strongly recommend that teams practicing Scrum align to a 2-week sprint iteration. This elevates many cross-functional planning and dependency management issues and creates a predictable delivery cadence for business stakeholders. In addition, there are a few software engineering practices that support our Agile methodology, such as pair programming, hybrid engineering, and test-driven development. 

However, these agile and engineering practices require a DevOps culture to reap the benefits. This means automating everything to have repeatable delivery processes from code merge to production deployments so that software engineers can focus on what they do best ─ writing code to solve business problems. The DevOps engineers focus on building what’s called the Continuous Integration and Continuous Deployment (CI/CD) pipelines, which includes automating infrastructure, specifically AWS infrastructure. From a functional reporting structure, having a DevOps team operate and function as a shared service for the organization will provide consistency in approach, toolchains, and process, as well as provide a career path for DevOps engineers while being cost efficient for the business.

The biggest challenge isn’t getting Agile and DevOps to work together, but rather changing the organization’s culture to work with DevOps. Since it’s normal for organizations to have silos that are very defined and very comfortable, it’s also normal for those silos to see DevOps as a threat. That’s completely understandable because DevOps can change reporting structures and how teams are defined and operate. Changing a corporate culture is never easy, but the big opportunity in implementing DevOps comes when you get leadership trained, educated, aligned, and committed. The bottom line is that both Agile and DevOps work together in harmony so that teams can fulfill business demands quickly in a cost effective manner to deliver on the right business outcomes.

Resource Strategy

Adopting and implementing Agile and DevOps product teams in your IT organization will get you a long way toward transforming your company so it can grow and scale for the future. However, this is an investment not only in the methodologies and practices your organization uses to deliver work, but more importantly, it’s an investment in your people. When you start out on this transformational journey you may not have the right skills and/or competencies in teams to deliver the business outcomes you’ve committed to delivering. As a result, the quality of the products and services you’re delivering may suffer. Delivering subpar products that don’t meet business objectives, even during a transformation, isn’t an option. Doing so can quickly erode trust with your users and stakeholders. This is where a strategic partnership with a trusted supplier who understands your products and services, your specific Agile practices, and DevOps goals, can help you along the journey. Here are a few things you’ll want to consider prior to forming that strategic partnership with a supplier. 

Staff Augmentation
Staff augmentation is a flexible strategy that enables you to hire contingent talent globally while managing your augmented team directly. Traditional IT organizations running waterfall delivery methodologies tend to employ more managed services from consulting companies. This method outsources the responsibility of development, testing, maintaining, and supporting a range of processes and functions in order to cut expenses. Unfortunately, this removes subject matter expertise from the organization and in my experience, isn’t necessarily as cost effective as it looks on paper. In Agile, rather than outsourcing the work through a managed service you’ll want to pursue a staff augmentation strategy that enhances your in-house team’s skills and abilities. All too often organizations pivoting from waterfall to Agile try to use waterfall practices, such as managed services, to staff teams. Unfortunately, this will not work and your organization will suffer a long slow death march with its Agile initiative. The takeaway here is that a pivot to Agile requires an organizational shift from a traditional managed service model to a staff augmentation model in order to supply the team with the necessary skills and competencies to deliver on the team’s mission.

Learning & Development
Another consideration to take into account when determining your resource strategy is the competency of the supplier’s workforce and their ability to teach and learn. While this seems straightforward, it’s something that is easily overlooked. Thus, you’ll want to ensure that the supplier meets your in-house job level competencies so as not to devalue or disrupt the team you’re augmenting. I advocate sharing your in-house competencies and programming standards with your supplier early in the engagement so they can recruit and hire staff that meets your delivery expectations. In addition, you’ll want to follow the same interview rigor you do for full-time employees, this includes any programming or coding assessments you may have established. While the hard skills are important, you also want to evaluate the soft skills. One competency I look for is the ability to teach and learn. The ability for the contingent staff to teach the in-house team the technology and/or skills they possess is critical for long term team success. However, this is a two-way street, the in-house team needs to be able to also teach the contingent staff about their internal standards and processes (e.g. test-driven development, compliance, etc.) or what I like to call “institutional knowledge.” This two-way teaching and learning is the biggest benefit to the organization as it creates a learning culture that can really give the organization a competitive advantage to meet market opportunities when they arise.

Timezone Proximity
I’ve managed both large global Agile teams, as well as small local Agile teams. The way you structure your practices, tools, and processes will largely depend on what timezone your core business or headquarters is in. The further away your supplier is from your core business, the less agile and more complex your delivery will be. Agile purists will tell you that all Agile team members need to be located in close proximity to one another to be effective. While I don’t disagree with this, it may not always be practical or cost-effective for an organization. In addition, what the COVID-19 pandemic has shown me, is that teams can be just as effective working together remotely as long as they’re in a timezone friendly proximity. 

How far away a timezone team members are will largely be an organizational decision. However, for a frame of reference, I set up my teams to have at least a 3-5 hour overlap with where my core business is located. This will allow in-house team members across the US and my strategic supplier to collaborate effectively in real-time. So if my core business location is San Francisco (GTM -8) I’ll want to be GTM  +/-5 of San Francisco. This will allow teams to practice our Agile methodology without early morning or late night transitions that can create team burnout.

On-call and Incident Response
A core DevOps practice is that teams must have clear, well-documented on-call processes to keep these complex systems running smoothly. Integrating the development and operations into the team helps the team to make better decisions about their products and services they build because they must also support them. Both full-time and contingent team members need to play a role in the on-call rotation and incident response. Thus, it’s important that this expectation is clear from the get go with your strategic supplier and that they are willing to support this level of commitment to your products and services.

As you can see there is a lot to consider when building high-performing global teams. Partnering with a strategic supplier that understands your delivery methodology and practices will only help you to reach your business goals sooner. 

So, how do you enable an IT organization to support a fast-growing technology company while also building a scalable delivery organization that will last? By adopting a product mindset, combining Agile and DevOps practices, and partnering with a strategic supplier that can support your staffing needs. Yes, it’s a big challenge to implement and there will be bumps along the way, but I’ve found this to be the best and most effective approach out there.