innovation

4 results

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

혁신세: 생산성이 낮고 사기가 떨어진 개발자가 유발하는 비용

저는 개발자들의 응석을 다 받아줘야 한다고 생각하지 않습니다. 개발자든, 최고 경영 책임자든 누군가에게 특권을 부여하는 문화에 동조하지도 않습니다. 우리 모두는 현실을 살아가는 성인이고 전문가입니다. 직책에 관계없이 서로를 동등한 성인으로 대해야 합니다. 컴퓨터 프로그래머부터 금융 분석가, 영업 담당자에 이르는 모두가 회사에 고유한 가치를 제공하고 있습니다. 저 같은 경영자는 모든 팀원들이 보유하고 있는 중요한 역량들을 이해하고, 인정하고, 후원하려고 노력해야 합니다. 개발자부터 시작해보겠습니다. 제가 가장 아끼는 구성원 중 하나죠. 디지털 시대로 접어들면서 귀에 못이 박히게 듣고 있는 말이 있습니다. “모든 회사가 소프트웨어 회사로 변모하고 있다"는 말입니다. 디지털 분야, 특히 애플리케이션 개발에서의 혁신이 새로운 비즈니스 창출 및 경쟁 우위에 중요한 역할을 한다는 것을 강조하기 위한 표현이라 하겠습니다. 새로운 애플리케이션을 신속하게 배포하고 다양한 혁신 기술을 함께 제공할 수 있는 능력이 비즈니스 성공의 직접적인 동인으로 자리 잡았습니다. 애플리케이션이 새로운 경제의 통화라면 개발 팀은 시장 조성자입니다. 하지만 제 경험에 따르면 디지털 경제에서 속도와 혁신을 부단히 그리고 전략적으로 강조하고 있음에도 불구하고, 개발 팀은 오해를 받고 제대로 관리되지 않아 방치되기 일쑤입니다. 이러한 현상은 기업의 규모와는 관계가 없습니다. 뭔가 앞뒤가 맞지 않습니다. 게다가 엄청난 비용이 발생하고 있습니다. 저는 이것을 혁신하는 회사가 대가로 치르는 세금이라고 생각합니다. 개발자가 수행하는 업무의 속성을 이해하지 못하거나 개발자에게 안전하고 생산적인 환경을 제공하지 못하는 기업은 이 세금을 치르게 됩니다. 그리고 이 문제를 제대로 해결하지 못하면 장기적으로 시장에서 살아남을 수 없습니다. 요즘에는 프로덕션 코드를 작성하고 있지 않지만, 그럼에도 불구하고 저는 여전히 개발자입니다. MongoDB는 수십 개 팀에 소속된 수백 명의 개발자들을 이끌고 있기 때문에 저는 항상 개발자 문제에 부딪히게 됩니다. 개발자를 위해 생산적인 문화를 조성하려면 해야 할 일과 하지 말아야 할 일이 몇 가지 있습니다. 이 업계에서 경력을 쌓으면서 터득한 것이죠. 물론 앞으로도 계속해서 논의가 필요한 문제겠지만, 일단 소개해보겠습니다. 현재 지불하고 있는 "혁신세"를 줄이고 싶다면 꼭 생각해 봐야 할 몇 가지가 있습니다. 개발자에게 비즈니스 맥락을 제공하라 개발자의 지능이나 성숙도를 우습게 보지 마십시오. 개발자는 자신이 일하는 이유와 근거를 이해할 수 있고 또 이해해야 합니다. 실제로 개발자가 전략적 목표를 그려놓으면 소프트웨어의 아키텍처 및 설계 경험과 조율해 중요한 의사 결정을 내리게 되면서 더 나은 결과물이 나옵니다. 비즈니스 맥락을 이해하는 개발자는 최고 책임자, 심지어 저 같은 CTO 보다 훨씬 현명하게 상향식 관점에서 성과를 내는 방법을 찾을 수 있습니다. '기술 부채'를 인정하고 원금을 갚아라 제 경험으로 볼 때, 개발자들의 사기를 떨어뜨리는 가장 큰 원인은 과도한 기술 부채와 이를 해결하려는 경영진의 의지 부족입니다. 탈출구를 마련하기 위해 약간의 부채를 지는 것도 나쁘지는 않습니다. 부채라는 것을 알고 나중에 원금을 갚기만 한다면 말입니다. 그러나 개발자들은 리더가 기술 부채 증가에 관심을 기울이지 않고 있다는 사실을 본능적으로 눈치 챕니다. 기술 부채 증가에 관심을 기울이지 않는 리더들은 프로젝트 일정에만 집착하고 엔지니어링 정신을 잃어가기 때문입니다. 그러면 개발자들은 인지 부조화에 빠지게 됩니다. 상황은 재앙에 가까운데도 개발자에게 차기 혁신을 내놓으라고 요구하는 리더는 신뢰를 잃게 되고, 개발자들은 인내심을 잃게 됩니다. 회사는 혁신 속도가 지체되면서 비용 손실을 입게 됩니다. 개발자가 실제로 어떤 일을 하는지 파악하라 여기에 대해서는 며칠이고 얘기할 수 있을 정도로 할 말이 많지만, 결론은 이렇습니다. 개발자가 업무 시간을 어떻게 쓰고 있는지 이해하지 못하는 리더는 팀을 이끌 자격이 없습니다. 새로운 기능에 초점을 맞추기는 쉽습니다. 하지만 리더라면 개발에 관련된 부수적인 작업(데이터베이스나 레거시 스테이징 환경의 유지관리 등)이 지루하고 고된 단순 반복작업이라는 점을 인정하고 문제를 해결하기 위해 애써야 합니다. 그러지 않으면 혁신 가치도 제공하지 않으면서 개발자의 시간만 많이 잡아먹게 되어 개발자의 사기만 떨어지고 말 것입니다. 개발과 관련된 부수적인 시스템을 쇄신해야 한다는 개발자의 목소리에 귀를 기울여 그 중요성을 이해해야 합니다. OKR과 허영 지표를 제거하라 하향식 혁신이라는 말에는 모순이 있습니다. 개발자가 원하는 것은 오직 자신이 개발한 기술을 실현하는 것이라는 사실을 믿어야 합니다. 목표, 주요 성과 또는 기타 KPI를 통해 개발자를 압박할수록 개발자는 스스로 혁신의 범위를 제한하게 됩니다. 목표를 설정했다면, 개입하지 말고 빠져줘야 합니다. 목표를 조정하라 이는 비즈니스 맥락을 제공하라는 말과 같습니다. 리더와 개발자는 같은 목표를 달성하기 위해 협력하고 있다는 사실을 믿어야 합니다. 대립 관계가 되면 개발자의 업무에 차질이 생기고, 리더는 단 한 번의 마찰로 인해 하루라는 귀중한 시간을 낭비하게 됩니다. 다시 말하지만, 응석을 받아주라는 말이 아닙니다. 개발자는 다른 모든 직원들과 마찬가지로 회사의 성공을 위해 맡은 바 역할을 수행해야 합니다. 제 말은 비즈니스 목표와 기술 목표, 조직 목표를 조율해서 개발자들과 솔직하면서도 투명한 관계를 구축해야 한다는 것입니다. 앞서 말했듯이 이 주제에 대해서는 며칠이고 말할 수 있을 정도로 할 말이 많습니다. 개발자에 대한 관리 미흡은 혁신세의 한 형태라는 것을 기억하시기 바랍니다. 앞으로 몇 달에 걸쳐 여기에 숨겨진 다른 세금은 없는지 살펴볼 것입니다. 지금까지 초보 리더들이 해야 할 일과 하지 말아야 할 일에 대해 알아봤습니다. 이에 대한 논의가 앞으로도 계속되었으면 합니다. 덧붙이고 싶거나 빼야 한다고 생각하는 내용이 있으시면 언제든 자유롭게 Twitter( @MarkLovesTech )에 올려주시기 바랍니다.

March 23, 2021

Speaker Lineup for MongoDB San Francisco

MongoDB San Francisco , 10gen’s most popular event of the year, is coming up on May 10. San Francisco has become a stronghold of tech innovation, and our lineup of exceptional speakers is testament to the exceptional MongoDB-powered ecosystem in the Bay Area. Here are just a few of the awesome talks on the agenda for MongoDB San Francisco: Using MongoDB for Groupon's Place Data, by Peter Bakkum, Member of Technical Staff, Groupon The Merchant data team at Groupon uses MongoDB to create “the most comprehensive database of places and merchants in the world.” This is a mission-critical part of the Groupon platform providing real-time data for the business. In this session, get an inside view of Groupon’s MongoDB cluster: Peter will introduce attendees to the data model, data processing pipeline and the dynamics of parallel querying in their Storm cluster. Managing a Maturing MongoDB Ecosystem, by Charity Majors, Systems Engineer, Parse Parse, which was recently acquired by Facebook , provides scalable, cross-platform services and tools for developers. Parse engineer, Charity Majors, has a tremendous amount of experience managing Parse’s MongoDB clusters from their infancy into their golden years and will show best practices for keeping MongoDB clusters healthy. Charity’s scaling and performance tuning tips will help you become a MongoDB ops specialist. How ServiceSource Revolutionized Its Business and Moved to the Cloud with MongoDB, by Greg Olsen, CTO, ServiceSource In late 2012, ServiceSource released Renew OnDemand, designed to increase recurring revenue for the world's largest technology companies. Built on MongoDB, Renew is representative of a new generation of cloud-native enterprise applications that exploit innovative datastore and compute approaches to achieve fundamental improvements in capability and scale. Greg Olsen, CTO of ServiceSource, will discuss how his team has implemented MongoDB in a sharded environment, describe some of the unique characteristics of the platform and provide insight into how other service providers can be equally adaptive using MongoDB. Storing eBay's Media Metadata on MongoDB , by Yuri Finkelstein, Architect, eBay eBay is the largest secondary marketplace on the web. The eBay development team has been using MongoDB for project Zoom, where they store all of the website’s metadata, which includes references to every item’s photos on eBay. This cluster is eBay's first of many MongoDB installations on the platform, and was chosen for its flexible data model and improved performance. Yuri Finkelstein, an Enterprise Architect on the team, will provide a technical overview of this mission-critical project and its underlying architecture and discuss why the team chose MongoDB for project Zoom. MongoDB and Meteor: an Architecture for Real-time Web Apps, Matt DeBergalis, Architect, Meteor Meteor is a new JavaScript application platform -- specifically designed to work with MongoDB -- for building modern real-time web applications. These applications, like live analytics dashboards or those that show live data feeds, all have a way to send real-time updates to connected users when documents in their database change. Meteor and MongoDB offer an elegant architecture for managing the flow of data in a realtime app using the familiar MongoDB APIs. This talk will dig into the architecture of a realtime app built on MongoDB. Matt will cover tips and tricks for using MongoDB in a realtime app and demonstrate some of the design patterns they’ve developed. A Year of Monitoring Production Deployments with MongoDB , Simon Maynard, Co-Founder, Bugsnag Bugsnag is a fast growing error monitoring service for web and mobile applications that is processing millions of errors every day, and was designed from the ground up to utilize MongoDB and its strengths. In this talk, CTO Simon Maynard will discuss hints and tips from two years of running production MongoDB deployments. The talk will cover all aspects of developing for and maintaining a MongoDB deployment, including using the profiler to tune performance, as well as schema and index design considerations and what to monitor and how to monitor it. Want to see these talks and more? Join the community at MongoDB San Francisco : use the discount code mongodb_blog for 25% off on tickets.

April 30, 2013

Post+Beam's MongoDB-powered innovation factory

When your business is innovation, throttling creativity with rigid, upfront schema design is a recipe for frustration. It’s therefore not surprising that Post+Beam , an innovation and communications “factory,” turned to MongoDB to enable rapid development. Part startup incubator, part branding and communication agency, part development firm, Post+Beam takes ideas and turns them into products. Post+Beam’s first MongoDB-based product is Linea, a cross-platform photo browsing application that extends from web to mobile and enables users to create and share stories through photos, focusing on the photos and the collaboration around them, not photo storage. In talking with lead engineer Jeff Chao, he mentioned MongoDB’s dynamic schema as a primary reason for using the NoSQL database: The most important reason for using MongoDB from the start is rapid development. We wanted to spend just enough development time in spec’ing out a schema so we could get started on writing the application. We were then able to incrementally adjust the schema depending on various technical and non-technical requirements. Another reason for choosing MongoDB is because of its default data representation. We were able to build out an API to allow iOS clients to interact with our web service via JSON. This is particularly interesting given that Post+Beam’s development team has extensive relational database technology. According to Chao, MongoDB’s documentation and community support” made it easy to get up-to-speed. The initial set-up consists of a three-node replica set (for automatic fail-over), all running in one cluster on Amazon EC2. While the team continues to use Postgres for some transactional components of the Linea app, it needed MongoDB’s flexible data model to support its business model, which demands continuous iteration Which, of course, is how innovation happens. Chao noted that Post+Beam plans to expand its use of MongoDB, particularly for those applications that “require a relatively short delivery time combined with requirements that might not be fully matured at the time of the [client] request.” This sounds like most applications, most of the time, in most enterprises. Indeed, this is one of the primary reasons we see for MongoDB’s mass adoption. As our friends at MongoLab say , “It’s a data model thing.” Tagged with: data model, Post+Beam, case study, Linea, innovation, flexibility, replica sets, ease of use

February 19, 2013