Companies doing software development are either:
- Technology companies, offering technology-as-a-service and/or technology products to clients and end users
- Tech-enabled companies, using tech services and products (sometimes off the shelf, but mostly bespoke) to improve their core service offering in terms of quality, speed or cost.
For tech-enabled companies that rely on bespoke products, reducing risks in development is one of the key challenges. They need to make sure they build the right product the right way, even though technology is not, and will never be, their forte. How can they do that? Clearly, not by relying on heavy investment of effort and money into their own technology delivery process. Yet, this is exactly what many of these companies insist on doing. What gives?
A typical answer goes along these lines: they tried getting external help (read outsourcing) and what they got was poor technical output, even worse communication, awful productivity, and severe cultural mismatch. Whatever the symptoms, the problem was invariably rooted in poorly constructed and executed Working Agreements. With that dismal experience, companies turned inwards, doing the familiar and safe-but-ineffective: building their own teams. The idea is that more control over the process minutiae and team members location would guarantee speed and quality. Wrong.
The safe and soothing is not always the friend of the smart. All those dark corners of operational inefficiency that initially turned companies away from using external services do not disappear when they build their own dev processes. Actually, given the reasonably expected lack of delivery expertise, backtracking into the comfort zone causes more problems than it solves.
Instead of being the best at non-core activity (tech delivery) companies should SMART-source vendors with appropriate advisory, operational, and technical expertise.
This naturally implies a different way of thinking:
- The company itself understands the right way to engage external expertise (only a few right ways, many wrong ones)
- Software product development is vendor s core business (vs staffing or staff augmentation or IT)
- The vendor has a proven track record of success in Product Development (vs projects)
- The vendor demands deep collaboration and a high level of involvement on both sides throughout the engagement (shared planning, non-contentious client-vendor relationship, shared responsibility for timelines and milestones, etc.)
With these criteria guiding their thinking, companies can establish trust-based, productive partnerships which:
- Allow the buyer to focus on what matters most: building the right product, and let the vendor focus on their own key competency – building it the right way
- Maximize cost/value ratio due to vendors expert efficiency
- Create a fast-delivery Product Roadmap rooted in non-adversarial approach to planning and execution
Finding a partner that meets these criteria is not easy, considering that most tech vendors are still project-focused. With the goal of executing as many projects as possible, few have the depth of experience and operational sophistication needed for a holistic approach to product development. Also, knowing what to ask and what to look for is not as easy as ticking the “Which vertical do you work in?” or “Do you know Java?” checkboxes. But it can be done. The rewards of reduced risk, faster time-to-value, and product quality will be worth the effort.