About the Author: Chris Tiernan serves as the Senior Director of Software Engineering for IT Business Applications at Splunk and is responsible for Architecture, Product Management, and Engineering across a Web & Mobile Applications, Customer Identity, APIs & Data Integrations, Search, and Digital Shopping portfolio for the enterprise. His passion for business operations, Agile, and DevOps is rooted in his deep experience leading teams to implement advanced practices that not only increase delivery velocity and reduce business friction, but also cultivate highly empowered teams to do the best work of their careers.

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.

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.

Key #2:
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.

Key #3:
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.

An organization's ability to learn and translate that learning into action rapidly, is the ultimate competitive advantage."
- Jack Welch

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.

“Launchpad has been a trusted strategic partner seamlessly delivering high quality technical talent coupled with critical thinking skills that not only strengthen my Agile teams for greater business agility but also realize my organization’s vision.”
- Chris Tiernan

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 is 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 earlier 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.

BONUS:
Tips for Making Staff Augmentation Excel

Even before the COVID-19 pandemic, staff augmentation required making an extra effort to keep your in-house and contingent team members working together as a cohesive unit so that they continue to mature in Tuckman's Performing stage. However, in our new reality of social distancing and with internal team members working remotely, it takes even more effort to connect and engage everyone professionally and socially. Here are a few techniques that I've found helpful connecting my organization:

Disclaimer: While the techniques below describe in person interactions, these are on hold until post-Covid, but the suggestions have been adapted during the pandemic to include virtual get togethers with similar results.

• Social Hours: Trusted relationships don’t just happen with teams through the osmosis of work. Humans need other outlets to get to know one another. Individual teams are encouraged to self organize social events weekly, bi-weekly, monthly - whatever makes the most sense for them. In addition, as a broader organization we come together to socialize once a quarter. We eat, drink, and play games. You'd be surprised how much it helps build relationships with teams and individuals across the organization.

• Volunteering: I’m a big proponent of giving back to the communities we live and work in. Every quarter we come together as a team to volunteer our time to a non-profit of my organization's choosing. This can be an online event or a local event where groups of team members can meet and connect for the greater good in person.

• Quarterly Awards: As part of my employee recognition program, both full-time and contingent team members nominate each other for various awards we’ve defined. Our award committee chooses the winners based on the submitted nominations. Rather than giving out a generic $100 gift card, we’ve come up with awards that align with our culture values, whether that's the "R2-D2 Award" that supports our Innovation value or the "Morpheus Award" that supports our Passionate value. Winners receive a cool Zoom background that they can show off during meetings.
  

• Periodic Fly-Ins: Nothing brings a team together more than face-to-face conversations. Each quarter we fly in teams to spend a week working together side-by-side pair-programming and white boarding solutions together. We’ll also schedule time during that week to go out for dinner and/or drinks. This not only helps to put a face to the name, but also continues to build trusted relationships

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.

Conclusion

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.

About the Author: Chris Tiernan serves as the Senior Director of Software Engineering for IT Business Applications at Splunk and is responsible for Architecture, Product Management, and Engineering across a Web & Mobile Applications, Customer Identity, APIs & Data Integrations, Search, and Digital Shopping portfolio for the enterprise. For more insights from Chis, follow him on LinkedIn or check out his blog here.