BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles "Outsourcing is Bad": Why Good Vendors Agree

"Outsourcing is Bad": Why Good Vendors Agree

Bookmarks

Jim Fowler, CIO at GE Capital underscores in a recent article what most of us in software dev have been seeing for a while:IT insourcing is growing; outsourcing is shrinking. The article states:

Fowler wants the in-house versus outsourcing ratio to be down to 50-50 in the next two years, "and I know I'm not done" at that point, he says.

We've outsourced some of our expertise, and we've given up some of the knowledge of how we run the business, how the place is wired, that we need to get back in-house.

Statements like Fowler’s enervate outsourcing vendors and inspire outsourcing critics. So as a software development vendor, why am I encouraged? Because I believe good outsourcing  requires exactly what Fowler is building: a strong and strategic internal IT department that demands a stronger, more strategic and more integrated level of outsourcing. Fowler is adding credibility to an approach to IT, software development, and outsourcing thatI believe is necessary for success. Andwhen the “big guys” articulate a strategy or approach, the less-than-early adopters are more likely to get on board. The risks associated with failing to adopt appear greater than the risks associated with adopting. Fowler and GE Capital are opening the yellow brick road to more IT departments. The road will take you home with no clicking of the heels, and I believe it is the only road that will do so.  Here’s why:

When Software IS the Business

Business has been changing. Not all business, but a lot of it. We know there are businesses that rely very heavily on software, apps, and technology overall. Think Amazon, Apple, Alibaba and Overstock—all companies that are either entirely technology driven or largely so. Companies like Tesla consider software to be the product they are selling—not a car, but a software solution (think of the Tesla’s Version 7.0 software release including its autopilot feature). But companies like GE are app driven as well. GE is first and foremost a software company. Yes, GE, the maker of ENGINES, isa software company. CEO Jeff Immelt drives the “Industrial Internet of Things” as he transforms jet engines, locomotives, and other giant machines into data-spewing computers.

For both obviously tech driven and less obviously tech driven companies, success hinges upon strategic software development that meets business goals. IT is now more than ever in the driver’s seat—or has the chance to be. That means ensuring “t’s are crossed and i’s are dotted.” You can’t do that unless your internal software development folks are strong, and your external software development resources are integrated with them in a meaningful way. I refer to this latter integration as “team augmentation”—not to be confused with staff augmentation. Team aug (at least my version of it) requires any third party team members to be grown up and into, embrace and support today’s business and IT culture of rapid development, big picture thinking, knowledge sharing, ownership, and quality.

Rapid Development

ERP systems still exist and are necessary. Back office systems still exist and are necessary. But in addition, software must be deployed, tested, modified and re-deployed in weeks, not months, and definitely not years. This means assessment and understanding the market, testing products and tools, implementing, and then immediately assessing all over again—and doing all this in real time. With a strong internal IT team and as necessary an equally strong outsourced team, rapid development can be a reality. With “throw it over the fence” outsourcing—no way.

Why Are We Building This? Big Picture Thinking

So the software dev lead (CIO, head of engineering, director of application engineering depending upon the firm) needs to speak businessAND IT. This person needs to understand the needs of marketing, finance, operations, etc. and how they relate to IT. This person needs also to be able to explain the dev process and inter-relatedness of each app, project, functionality to non-IT folks in a non-technical way. For progress to happen fast, communication needs to be clear. This can’t happen without a strong internal software dev team working closely with an outsourced team, if outsourcing is required. If your vendors don’t get why you’re building what you’re building, you’ve got a leak in the development boat that will sink the ship eventually.

Outsourcing Redefined

By the same token, IT-specific communication needs to be just as clear. No, CLEARER. There must be an internal technical project lead (or equivalent) who can work directly with his/her own software dev team to get stuff done fast and well and pivot with pleasure. Yes, with pleasure. This is what’s FUN about IT today. It’s a living, breathing thing! Likewise, any outsourced partners HAVE to provide their own technical project lead (or equivalent) to make sure the “team aug” members understand and work toward client needs and bigger picture relations among previous, current and future apps/projects. This is what I call “Tech to Tech.”

In my experience it simply does not work to have either of the following two scenarios in play and expect a strong, lasting, flexible result: 1. Someone outside IT (e.g., marketing director, VP of finance, COO, etc.) driving software dev, or 2. Outsourced team members working directly with the client team without their own vendor-provided technical project lead. Success requires flat, fast, and LEADERSHIP. This is the part that is critical given the integral role of software in today’s business world. No coding in the corner.  The leaders on both sides (client and vendor) can be “servant leaders” (I like this term), but they must lead. Software dev is not an assembly line. We are not putting together a car. We are designing an engine that must work in myriad driving conditions with myriad drivers with myriad needs.

Knowledge Sharing

You don’t have time (the market won’t give it to you) to share knowledge in anything but the most efficient manner possible. But sharing knowledge isn’t about just passing work and research back and forth. It’s about culture.  Yes, you need daily meetings between and among teams and team members, whether all internal or distributed teams. But beyond that and most important, team leads and their members on both internal and external sides must be expected to open up the black box of code and determine answers to questions like: is it secure? Scalable? Robust? Maintainable? Can someone hack into the system? Can we go from 1,000 transactions to a million transactions without incident? Is the code object code or spaghetti code?

You’re not going to get answers to these questions unless your culture supports the asking and the answering. Your distributed team (if you have one) needs to feel as challenged, trusted, and respected as your internal team. This takes an investment. This is where the rubber hits the road, where the assembly line becomes an AI operation.  If you’re working with a distributed team that’s not used to asking questions or questioning authority, train through inquisition, by asking questions like this: What do YOU think? What are we missing? How could we enhance this?

Require that your distributed team use the same tools and methodologies as does your internal team for knowledge sharing—avoid multiple expectations, cultures, and tool kits. This can include, depending upon your culture, use of electronic boards; use of same code repository; requiring on-site planning sessions; requiring use of, say, chat tools rather than email if that’s how your team works best; providing smaller “jump in and code” projects so your distributed team can learn your platform in real time; pair programming; training to include sales/marketing ramp-up materials so your distributed team is able to execute and be accountable for big picture thinking. And my experience is that if you’re working with a distributed team, experience (lots of it) working intimately with your company’s country of origin results in a better cultural fit.

Ownership

Back to Fowler and my aggressive agreement with his approach: The “insourcing” of strategic IT is, in my opinion, a response to poor quality resulting from letting go of apps, projects, and initiatives that require internal ownership. If you’re outsourcing, don’t give away your system or the maintenance of it. It is yours. Another team can help but you must drive. Your team must not only check a vendor’s work functionally, but also check the code itself. How is the project architected, coded, designed? Is it junk code or great code? Can you add or modify it without overall structure falling down? Is the architecture multi-threaded?

Is it scalable, maintainable?

Quality

If your approach is right, you’ll end up with quality inside and out. By “approach” I mean:

  • Internal technical project lead: Do you have someone within IT who can lead the software dev team AND work with a vendor’s technical project lead and team?It must be someone who understands the project beyond the code—has a sense of how the project fits into the overall business.
  • Team augmentation, not staff augmentation: Are you working with a TEAM, including a technical project lead on the vendor side? If not, I think you’re doomed.
  • Are you trusting but verifying? Check the code, check the functionality. Check the fit with existing structure and future needs.

Coders Without Borders

My message and what I stand behind with every client engagement: Don’t outsource app development. Throw something over the fence and you’ll never know what comes back unless you take it apart again. Don’t outsource; instead, extend your team. This doesn’t mean hiring internally (necessarily). It means require that your outsourced support is fully engaged and integrated with your internal team, including a technical lead on your end and a technical lead on theirs.

We can and should go even farther, including nurturing children and young adults toward an approach to programming that goes beyond the code and focuses on teamwork, communication, strategic planning and big picture thinking. Look at what Mark Zuckerberg and his wife Priscilla Chan are doing beyond Facebook—opening a private school [http://fortune.com/2015/10/22/facebook-zuckerberg-school/]. Think about the next generation of programmers, and the generation after that. The seeds are being planted today for tomorrow’s IT strategic players—be they insourced, outsourced, at an ecommerce company, a health care provider, a non-profit or an engine maker.

At every company in every industry, software touches every single employee whether directly or indirectly. So to be good at what I do, whether I’m a customer service rep, a marketer, a mechanic, an accountant or  a coder, I have to understand code. Now, does this mean I have to be able to code my own apps? No, not necessarily. But in order to be good at what I do and make sure my contributions move the company forward as a whole, I must understand code—conceptually and funtionally.

A contributor today and tomorrow needs to understand, manage, and own code that’s being built on a company’s behalf, whether internally, onshore, nearshore, or offshore. Because the company IS the code. The code is a large part of the company’s assets. Take Provide Commerce (now FTD), an online flower company. The company doesn’t sell flowers; it sells software that sells flowers. If I work there as a contributor in any department, I need to understand as much the difference between a tulip and a tuberose as I do the difference between Java and JavaScript.

I believe this means that starting in grade 1 children should be taught code just like they are taught to read, write, and do math. By the time a child graduates from high school he/she should be quite familiar with CSS, Java, and JavaScript--at least. This ensures we are producing makers that use and users that make, not one or the other. This is knowledge sharing at a macro level. On a micro level, it’s (for instance) outsourcing in an environment of shared culture, shared risk, shared accountability. Some would say this isn’t possible with outsourcing. I would say it’s possible (we’re doing it) and it’s the only type of outsourcing that will survive.

For more info about my approach and proof that it works, contact me via this link.

About the Author

Yousef Awad graduated from San Diego State University with a Bachelor of Science degree in Information Systems and has 20+ years’ experience in the custom software development industry.  He joined Integrant in 1997 after a successful career in programming, database administration and project management.  He is responsible for establishing the company’s wholly owned development centers in Amman, Jordan and Cairo, Egypt. With over 140 full-time employees, Integrant specializes in providing custom software development, offering clients outsourcedteams that allow IT departments to stay in control of their projects and expand their software development teams effortlessly. Beyond Integrant, Yousef’s passion is to bring an understanding of the power of programming to children and young adults.  Yousef is working towards giving younger children access to coding classes that provide real-world, hands-on mentoring.  

Rate this Article

Adoption
Style

BT