Why build vs. buy is a winning talent strategy

683 readers like this.

“Buy vs. Build” is a mantra IT leaders are adopting as a means to better manage their budgets and resources. But while this may work for technology and tools, it may not be the best strategy for dealing with people issues in IT, according to Damon Edwards, co-founder of SimplifyOps, Inc.

At the upcoming DevOps Enterprise Summit in San Francisco, Nov. 7-9, Edwards will discuss why acquiring talent from the outside to fill every skills gap is an expensive strategy that won't pay off in the end. Instead, he argues, IT leaders must fix the systemic issues within their organization and focus on building talent from within. We caught up with him to learn more.

CIO_Q and A

The Enterprisers Project (TEP): We often hear IT leaders tout a "buy vs. build" strategy. But when it comes to talent, why would you say this isn't the best approach?

Damon EdwardsEdwards: The best performing companies I see are those who have the organizational systems in place to grow and support their talent. That also leads to being able to retain talent and then attract new, and even better, raw (or seasoned) talent. It's a virtuous cycle.

There is nothing inherently wrong with a "buy" position. However, if it is "vs. build," rather than "AND build," you are going to be in trouble. If you don't have the systems and organizational dynamics in place to grow and support your people, you are wasting your money on "buy" quick-fixes. Adrian Cockcroft, formerly of Netflix, a company known for "building" and "buying" the best talent, tells a great story of how he was asked by a room full of enterprise IT execs "where do you find all of your great talent?" His response was, "I hired them from you!"

TEP: What are some of the systemic issues that prevent new talent from delivering business results?

Edwards: For new talent or your most senior veterans, it's always the same things that get in the way. The presence of silos, the work isn't visible, there isn't an improvement system in place, unnecessary complexity (especially in operations), and faulty org design are some of the problems I see the most.

TEP: What can IT leaders do to fix those issues and develop skills among their existing talent?

Edwards: First, put a formal but lightweight improvement system in place to empower and encourage everyone – bottom-up and top-down – to find and fix what is getting in the way, improve how the workflows, and elevate their craft.

Second, work to remove the organizational conditions that keep people frustrated working in disconnected silos and buried in WIP, rework, unnecessary complexity, and technical debt.

I could also list all of the good hygiene HR practices (training availability, one-on-ones, clear responsibilities, etc., this) but these alone don't solve the problems. There are plenty of companies with great HR departments that are a nightmare to work for, have retention problems, and can't deliver. This isn't an HR problem, this is a business and technology managers' problem.

TEP: How does this approach help IT leaders advance their DevOps journeys? What other problems does it solve?

Edwards: The high-performing companies are the ones that are truly learning companies. They have the collective ability to find and fix what's getting in the way. Their people are always evolving and pushing both themselves and the company forward. Their core skill and their core advantage is "being good at getting better." That's the engine. Trying to "fix DevOps problems" without building that engine is just chasing symptoms.

Carla Rudder is a community manager and program manager for The Enterprisers Project. She enjoys bringing new authors into the community and helping them craft articles that showcase their voice and deliver novel, actionable insights for readers.  

Comments

There are a few factors that need to be considered (1) type of business (2) role of system and (3) capability. Are we a business that should be deevloping bespoke applications versus buying off the shelf? IS this system/product already built (i.e. lets build an ERP)- no need to recreate the wheel - especially if this is not part of your strategic advantage and finally - if you do not have the capability - the people, process, tools, culture - think hard. What should be build - first when it is part of the strategic competency - this bespoke solution will help us win!. second - when there is nothing to buy that works and finally - when yoou have the capability

*Note: The comments that I post hear are my own