“We need to track everything in our CRM: every lead source, every touchpoint, every stage, literally everything about our prospects. To do that we need a weekly BI dashboard that shows every metric, literally, everything. All the fields.”
The client was straight, the brief clear. The project manager shrugged and relayed it without fuss.
The team delivered what was required in less than a month: a dashboard spanning 14 screens, 73 charts, and a scrolling odyssey of filters. Every conceivable KPI, sub-metric, and legacy data blip was dutifully piped in.
Data pipelines were refactored; DevOps stayed late to wrangle permissions.
No question was asked about which numbers drove action; the goal was “all of them.”
Launch day: The client’s senior manager clicked in, stared at the data torrent, blinked, and asked quietly,
“Which one of these should I be worried about?” No one knew it. It triggered endless requests for clarifications:
"Wait, is this a duplicate? Why is April so high?" but the dashboard stayed, impressive and unhelpful.
Later, at the project “retrospective,” the team groaned when a new request landed: “Can you just show us the important figures, and what they mean for our targets?”
Everything was delivered as specified, on time, on budget and totally off the mark. The real failure: not incompetence of execution, but incompetence of thought.
This article explores the misguided belief that fulfilling requirements is the project’s goal, and why successful projects demand more than puzzle-solving skills.
Discover the root cause of problems: requests based on assumptions rather than thorough analysis.
Clients typically have limited knowledge of the specific matter, which is appropriate as their focus should remain on their core mission. However, when it comes to digital solutions designed to streamline their processes, their descriptions of needs can be inaccurate. This often stems from a lack of trust; they tend to propose solutions rather than articulating the underlying problem and remaining open to suggestions from the provider. This likely occurs because it appears straightforward. However, it may also stem from a lack of confidence in the provider's ability to offer suitable solutions, viewing them merely as technical specialists.
Common issues: clients mistaking features for outcomes.
Contrast: The team is technically sharp but often strategically disengaged.
Too often the more a team excels technically the more it lacks strategic engagement. It may lead to solutions that, though properly implemented, may not align with the business’ goals.
They can build anything, but should they build what they were asked?
When project culture implies compartmentalized responsibilities, it often leads to a lack of ownership. Where "logic" and "process framing" are seen as "someone else's job", drives a fragmented approach, causing inefficiencies, communication issues and reduced accountability for overall project success.
It works, but not in the way anyone hoped: A CRM that diligently tracks 67 fields per lead but can't answer the basic question: “which leads convert best?” Because the team faithfully executed a flawed concept.
This technically functional solution fails to meet its true objectives. The team, by diligently delivering exactly what was requested, produced something perfectly wrong, a fundamental misalignment between output and need, executed with precision despite inherent conceptual flaws.
Strict adherence to instructions, especially flawed ones, can hinder success. Focusing only on "what" without "why" misses crucial elements.
Missing aspects when blind obedience prevails:
Systems Thinking: Overlooking how tasks impact the larger ecosystem and broader value chain.
Understanding Business Logic and User Motivations: Lacking insight into the request's purpose, leading to misdirected or ineffective solutions.
Courage (and Skill) to Challenge the Brief: The bravery and analytical ability to question directives, propose improvements, and collaborate for better outcomes.
Inability to Ask "Why" or Reframe the Request Without Feeling It's "Insubordinate": A culture that stifles questions, hindering innovation and problem-solving.
While foundational instruction following is incomplete without critical analysis, strategic thinking and the courage to advocate for improvement, the most valuable contributions come from those who actively engage with the purpose and shape the path to success.
Strategic Technical Leadership: Develop technical professionals as holistic problem-solvers who marry engineering discipline with strategic thinking and practical wisdom.
Establish the non-negotiable: "If the rationale isn't clear, the implementation shouldn't begin."
Create space for constructive challenge where teams can diplomatically surface flawed reasoning before it scales into larger problems.
Technology has evolved into such a vast and intricate domain that true technical mastery requires dedicated focus and continuous deep learning. Expecting technical experts to simultaneously maintain cutting-edge technical proficiency while developing sophisticated business strategy skills creates an unrealistic dual burden that dilutes effectiveness in both areas.
Organizations need specialized professionals who operate at the intersection, individuals with sufficient technical literacy to understand system implications but whose primary expertise lies in business process analysis and solution validation. These bridge professionals can:
Evaluate whether proposed technical solutions actually address the underlying business problems
Challenge project assumptions before they reach the technical implementation phase
Serve as intelligent intermediaries who can translate business needs into technical requirements and technical constraints into business language
Focus their cognitive resources on understanding organizational workflows, stakeholder needs, and strategic alignment rather than mastering the latest frameworks or architectural patterns
This approach leverages the principle of specialized excellence: let technical experts excel at technical complexity while empowering business-technical analysts to excel at solution appropriateness and strategic alignment. The result is better technical solutions that actually solve the right problems, rather than technically impressive solutions that miss the business mark.
The key insight: questioning the "why" requires different skills than optimizing the "how."
Links:
https://studycorgi.com/the-perils-of-obedience-book-by-stanley-milgram/
https://journeymagazineptbo.com/2020/01/24/is-there-a-mystery-to-blind-obedience/
Core Books on Organizational Design and Technical Management
Brooks, Fred Jr. The Mythical Man-Month: Essays on Software Engineering (Anniversary Edition). Addison-Wesley, 1995. Classic work exploring the complexity of software projects and team organization; introduced Conway's Law to broader audience Available: Amazon, Google Books, O'Reilly
Conway, Melvin E. "How Do Committees Invent." Datamation, vol. 14, no. 4, April 1968, pp. 28-31. Original paper establishing Conway's Law: organizations design systems that mirror their communication structures. Available online: http://www.melconway.com/Home/Committees_Paper.html
Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009.
Discusses role specialization and cross-functional team dynamics Available: https://www.mountaingoatsoftware.com/books
Skelton, Matthew, and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019.
Comprehensive framework for organizing technical teams and defining clear boundaries between roles Official site: https://teamtopologies.com/book Available: https://itrevolution.com/product/team-topologies/ Amazon: https://www.amazon.com/Team-Topologies-Organizing-Business-Technology/dp/1942788819
Kim, Gene, et al. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.
Explores the integration of business and technical concerns through organizational design Available: https://itrevolution.com/product/the-devops-handbook/
Humble, Jez, and David Farley. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley, 2010.
Addresses the need for business-technical alignment in delivery processes Available:
https://continuousdelivery.com/
Wiegers, Karl, and Joy Beatty. Software Requirements (3rd Edition). Microsoft Press, 2013.
Standard reference for bridging business needs and technical solutions Available: Microsoft Press, Amazon, O'Reilly
International Institute of Business Analysis. A Guide to the Business Analysis Body of Knowledge (BABOK Guide) (Version 3.0). IIBA, 2015.
Comprehensive framework for business analysis roles and competencies. Official site: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Pohl, Klaus. Requirements Engineering: Fundamentals, Principles, and Techniques. Springer, 2010.
Academic approach to the translation between business and technical domains. Available: Springer, Google Scholar
Gottesdiener, Ellen, and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, 2012.
Modern approach to business analysis in agile environments
Alexander, Ian, and Ljerka Beus-Dukic. Discovering Requirements: How to Specify Products and Services. Wiley, 2009.
Practical techniques for requirement elicitation and validation
Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice (4th Edition). Addison-Wesley, 2021.
Comprehensive coverage of architectural decision-making and stakeholder management
Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.
Establishes the importance of business domain expertise in technical design
Vernon, Vaughn. Implementing Domain-Driven Design. Addison-Wesley, 2013.
Practical application of business-driven technical design principles
Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
Classic reference for business-technical integration patterns
Hohmann, Luke. Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley, 2003.
Focus on the business context of technical architectural decisions
Gladwell, Malcolm. Outliers: The Story of Success. Little, Brown and Company, 2008.
Explores the development of deep expertise and the 10,000-hour rule
Newport, Cal. Deep Work: Rules for Focused Success in a Distracted World. Grand Central Publishing, 2016.
Argues for the importance of specialized, focused expertise
Brooks, David. The Social Animal: The Hidden Sources of Love, Character, and Achievement. Random House, 2011.
Examines how specialization and collaboration interact in organizations
Heath, Chip, and Dan Heath. Made to Stick: Why Some Ideas Survive and Others Die. Random House, 2007.
Principles for effective communication across different expertise domains
Klayman, Joshua, and Young-Won Ha. "Confirmation, Disconfirmation, and Information in Hypothesis Testing." Psychological Review, vol. 94, no. 2, 1987, pp. 211-228.
Academic research on how different professional backgrounds affect problem-solving approaches
Clarkston Consulting. "What is a Business Translator?" and "The Business Translator Role in Analytics." Clarkston Consulting Insights, 2024.
Modern definition and application of business translator roles in analytics and technology projects Available: https://www.clarkstonconsulting.com/insights/
McKinsey & Company. "The Age of Analytics: Competing in a Data-Driven World." McKinsey Global Institute, 2016.
Industry report on the need for business-technical translation roles. Available: https://www.mckinsey.com/capabilities/mckinsey-analytics/our-insights
Cataldo, Marcelo, et al. "Conway's Law Revisited: The Evidence for a Task-Based Perspective." IEEE Transactions on Software Engineering, vol. 39, no. 2, 2013.
Recent research validating and refining Conway's Law in modern software development
Herbsleb, James D. "Global Software Engineering: The Future of Socio-technical Coordination." Future of Software Engineering, 2007.
Research on coordination challenges in complex technical organizations
International Institute of Business Analysis. Business Analysis Competency Model. IIBA, 2014.
Professional competency framework for business analysis roles
Project Management Institute. Business Analysis for Practitioners: A Practice Guide. PMI, 2015.
Integration of business analysis with project management practices
Pichler, Roman. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age. Pichler Consulting, 2016.
Modern approach to product strategy that bridges business and technical concerns
Torres, Teresa. Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk, 2021.
Framework for ongoing business-technical validation
Camille, Fournier. The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change. O'Reilly Media, 2017.
Discusses the transition from technical contributor to strategic technical leader
Larson, Will. Staff Engineer: Leadership Beyond the Management Track. No Starch Press, 2021.
Explores technical leadership roles that focus on strategy rather than implementation
Brynjolfsson, Erik, and Andrew McAfee. The Second Machine Age: Work, Progress, and Prosperity in a Time of Brilliant Technologies. W. W. Norton & Company, 2014.
Implications of AI for specialized vs. generalized roles
Ford, Martin. The Rise of the Robots: Technology and the Threat of a Jobless Future. Basic Books, 2015.
Discussion of how automation affects the need for human bridge roles
Westerman, George, et al. Leading Digital: Turning Technology into Business Transformation. Harvard Business Review Press, 2014.
Framework for managing the intersection of business and technology strategy
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.