혁신세: 개발자의 비생산성과 불만족으로 인해 발생하는 비용은 어느 정도입니까?

Mark Porter
March 23, 2021 | Updated: November 8, 2021

저는 개발자의 응석을 받아줘야 한다고 생각하는 사람이 아닙니다. 개발자나 최고 경영진과 같이 조직에서 실질적인 권한을 가진 사람들의 특권을 옹호하는 문화에 찬성하지도 않습니다. 우리 모두는 현실 세계에서 전문가로 일하고 있는 성인입니다. 역할이나 책임에 관계없이 서로를 어른으로 대해야 합니다. 컴퓨터 프로그래머에서부터 재무 분석가, 영업 담당자에 이르기까지 모든 직원이 회사에 고유한 가치를 제공하고 있습니다.

따라서 저 같은 경영진은 모든 팀원들이 발휘하는 중요한 역량을 이해하고 인정 및 육성하기 위해 노력해야 합니다.

그럼 제가 가장 좋아하는 개발자 집단부터 살펴보겠습니다. 디지털 시대를 살아가는 지금 흔히 듣는 말이 있습니다. 바로 “모든 기업이 소프트웨어 기업이 되어가고 있다”는 것입니다. 이 말은 디지털 분야의 혁신(애플리케이션 개발)이 새로운 비즈니스 창출과 경쟁 우위 확보의 주요 원동력이라는 뜻입니다. 새로운 애플리케이션을 신속하게 배포하고 애플리케이션에 다양한 혁신 기능을 적용할 수 있는 능력은 비즈니스의 성공에 직접적인 영향을 미칩니다.

애플리케이션이 새로운 디지털 경제의 화폐라면 개발 팀은 시장 조성자입니다. 그러나 제 경험상, 전략적으로 디지털 경제의 속도와 혁신을 부단히 강조하는 분위기에도 불구하고 대기업과 중소기업 모두 개발 팀이 오해를 받거나, 잘못 관리되거나, 소외되는 일이 계속 발생하고 있습니다.

이것은 부당한 일일 뿐만 아니라, 엄청난 비용 손실을 야기합니다. 저는 이것을 회사에서 창출 가능한 혁신의 양에 대한 세금으로 생각합니다. 개발자가 수행하는 업무의 속성을 이해하지 못하거나, 안전하고 생산적인 업무 환경을 제공하지 못할 때 기업은 이러한 세금을 지불하게 됩니다. 이러한 부분을 간과한 기업은 오랫동안 살아남을 수 없습니다.

저는 요즘 프로덕션 코드를 개발하고 있지는 않지만, 마음만은 여전히 개발자입니다. MongoDB의 경우, 수 십 개의 팀에 수 백 명의 개발자가 분산되어 있기 때문에 개발자 문제가 계속해서 발생하고 있습니다. 저는 지금까지 일해오면서 개발자를 위한 생산적인 문화를 조성하기 위해 해야 할 것과 하지 말아야 할 것을 배웠습니다. 이 문제는 뒤에서 다시 말씀드리겠습니다. 먼저, 현재 지불하고 있는 "혁신세"를 줄이고 싶다면 다음의 몇 가지 사항을 고려해야 합니다.

• 개발자에게 비즈니스 컨텍스트를 제공

개발자의 지능이나 성숙도를 모욕해서는 안 됩니다. 개발자는 자신의 업무에 대한 비즈니스 근거를 이해할 수 있고, 또 이해해야 합니다. 실제로 개발자를 위한 전략적 목표를 설정하면 소프트웨어의 아키텍처와 설계 경험 측면에서 중요한 결정을 조율할 때 더 나은 결과물이 도출됩니다. 비즈니스 컨텍스트를 이해한 개발자는 저 같은 CTO가 주도하는 하향식 혁신이 아니라, 상향식으로 혁신을 달성하는 효과적인 방법을 찾을 수 있습니다.

• 기술 부채를 중요시 여기고 원금을 상환

제 경험으로 미루어볼 때 개발자들의 사기를 떨어트리는 가장 큰 원인은 과도한 기술 부채와 이를 묵살하는 경영진의 태도입니다. 제품 출시를 위한 약간의 부채를 지는 것은 괜찮습니다. 부채라는 것을 인식하고 나중에 원금을 갚는다면 말입니다. 하지만 부채 증가에 신경 쓰지 않는 리더는 자신이 간트 차트에 매달리느라 엔지니어링 정신과 멀어지고 있다는 것을 개발자에게 여실히 보여주는 셈입니다. 이러한 인지 부조화 상태에서는 개발자가 제 역량을 발휘하지 못합니다. 이렇게 손을 쓸 수 없는 상태에서 개발자에게 혁신 기술을 개발하도록 지시한다면 이들로부터 신뢰를 잃게 되고 개발자의 인내심도 바닥이 날 것입니다. 그리고 무엇보다 혁신의 속도가 점차 느려지면서 비용 손실이 발생하게 됩니다.

• 개발자의 실질적인 업무 이해

이 부분에 대해서는 할 말이 많지만 요점만 말하자면, 리더가 개발자의 업무 방식을 이해하지 못하면 팀을 이끌어갈 수 없다는 것입니다. 새로운 기능에만 집중하는 것은 쉽습니다. 하지만 리더라면 데이터베이스나 레거시 스테이징 환경을 유지 관리하는 등의 관련 업무가 혁신 가치를 제공하지 않고 개발자의 시간을 빼앗으며 사기를 저해하는 아주 고된 작업이라는 사실을 인정하고, 이를 해결해야 합니다. 그 이유를 이해하려면 인접하거나 종속된 시스템을 개조해야 한다고 주장하는 개발자의 말을 들어보십시오.

• OKR 및 허영 지표 제거

하향식으로 혁신한다는 것 자체가 모순입니다. 개발자가 원하는 것은 자신의 아이디어를 실현하는 것뿐이라는 사실을 믿어야 합니다. 경영진이 목표, 주요 성과 및 기타 KPI(Key Performance Indicator)를 통해 개발자의 업무 방식을 통제하려고 할수록 혁신의 범위는 제한됩니다. 목표를 설정했다면 개발자에게 맡기고 한 발 물러나야 합니다.

• 목표 조정

이는 비즈니스 컨텍스트를 제공하는 것과 관련이 있습니다. 리더와 개발자는 같은 목표를 향해 나아가고 있음을 체감해야 합니다. 적대적인 관계는 개발자의 이탈을 초래하고, 단 한 번의 부정적인 상호 작용만으로도 하루 종일 수행한 업무의 성과가 날아갈 수 있습니다. 다시 말하지만, 컴퓨터 프로그래머의 응석을 받아주자는 것이 아닙니다. 개발자는 다른 사람들과 마찬가지로 기업의 성공을 위해 복잡한 레시피에서 자신의 역할을 수행하고 있습니다. 하지만 이를 위해서는 비즈니스와 기술 및 조직의 목표를 조율하고 개발자와 정직하고 투명한 관계를 구축해야 합니다.

앞서 말했듯이 이 주제에 관해서는 며칠이라도 이야기를 할 수 있을 정도로 할 말이 많습니다. 당부드리건대, 개발자를 잘못 관리하면 혁신세가 발생한다는 것을 명심하십시오. 저는 앞으로 몇 달에 걸쳐 혁신세와 관련된 다른 숨은 비용들을 살펴볼 것입니다. 모쪼록 본 게시글이 해야 할 일과 하지 말아야 할 일에 대한 대화를 나눌 시작점이 되기를 바랍니다. 트위터에서 자유롭게 @MarkLovesTech를 추가하거나 삭제하실 수 있습니다.

← Previous

The Innovation Tax: How much are unproductive and unhappy developers costing you?

I am not someone who believes that developers should be coddled. And I don’t subscribe to a culture of entitlement for developers, or any other part of an organization for that matter, including the C-suite. We are all professional adults operating in the real world. We should treat each other like grownups, regardless of role or responsibility. From the coder to the financial analyst to the sales rep, we all bring our unique value to the company. So execs like me need to strive to understand, appreciate, and foster the critical skills every team member brings to the table. Let’s start with developers, one of my favorite cohorts. We’ve all heard the now overused adage of the digital age: “Every company is becoming a software company.” What this trope is trying to convey is that innovation in the digital space - application development - is a major force in driving new business creation and competitive advantage. The speed with which a new application can be deployed, coupled with the quantity of innovative features in it, is a direct lever on the success of a business. If applications are the currency of the new economy, then development teams are the market makers. In my experience, however, despite the relentless strategic emphasis on speed and innovation in the digital economy, these teams continue to be misunderstood, mismanaged, and marginalized inside both large and small companies. It’s not rational. Worse, it’s incredibly costly. I think about this as a tax on the amount of innovation that a company can produce. Companies pay this tax when they fail to understand the nature of the work developers do, or provide a safe and productive environment for them to do it. And if you don’t get that right, you’re not going to be in this game for very long. Though I don’t write any production code these days, at heart, I’m still a developer. And MongoDB leads hundreds of developers spread across tens of teams, so I’m constantly exposed to developer issues. Over the course of my career, I’ve learned a few things about how – and how not – to cultivate a productive culture for developers. This will be an ongoing discussion, for sure. But to get things started, here are a few things to think about if you’re trying to reduce the “Innovation Tax” your currently paying: Give your developers business context Don’t insult the intelligence or maturity of your developers. They can – and must – understand the business rationale for their work. In fact, painting the strategic target for developers will result in a better work product as they align their key decisions in the architecture and design experience of your software. Once they understand the business context, they’ll find better ways of achieving it bottoms-up than any tops-down leader, even a CTO like me, possibly can. Respect tech debt — and pay down the principal In my experience, the single biggest source of low morale among developers is the combination of too much tech debt and management’s dismissal of it. Taking on some debt to get a release out is fine - if you do it knowingly and pay down the principal later. But leaders who don’t pay attention to mounting debt demonstrate in a very visceral way to developers that they’ve become Gantt-chart leaders, and lost touch with their ethos of engineering. Developers don’t do well with cognitive dissonance, so when you tell them to build the next great thing on top of a dumpster fire, you lose credibility, they lose patience, and your company loses money as the pace of innovation slows to a crawl. Understand what your developers are really doing I could talk about this one for days, but the bottom line is that if leaders don’t understand how developers spend their time, they have no business leading the teams. It’s easy to just focus on new features, but you must acknowledge and address the fact that adjacent work like maintaining databases or a legacy staging environment is pure drudgery that provides no innovation value, costs a fortune in developer time, and saps morale. Listen to the developers when they say that they need to revamp an adjacent or dependent system to understand why it’s important. Remove OKRs and vanity metrics Top-down innovation is an oxymoron. You have to trust that developers want nothing more than to see their work come to life. The more management tells them how to do their job – through objectives and key results or any other key performance indicators – the more they limit the scope of innovation. Paint the target, then get out of the way. Align your goals This goes back to providing business context. Leaders and developers need to believe they are working together toward the same goal. An oppositional relationship takes developers out of flow, and you can lose a whole day of productivity from a single negative interaction. Again, I’m not advocating coddling; developers have their part to play in the complex recipe that builds a successful company, just like everybody else. But for that to work, you must align business, technical, and organizational goals, and build honest and transparent relationships with your devs. Like I said, I could riff on this topic for many more days (or posts). And keep in mind, mismanaging developers is just one form of innovation tax. I’ll be exploring other hidden levies in this space over the coming months. But hopefully this starter list of dos and don’ts gets the conversation going. Please feel free to add to it (or subtract from it) on Twitter at @MarkLovesTech .

March 23, 2021
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024