Team growth requires giving people room to make mistakes. Figuring out which mistakes are just “papercuts” and which are critical is one of the most difficult challenges in engineering leadership.
We’ve all seen “helicopter parents,” hovering over their kids to catch them at the slightest inclination they might fall. We swear we’d never do that, that we’d give our kids room to grow and learn from mistakes. Then we become tech leads and turn into the worst kind of “helicopter leaders.”
I was certainly guilty of micromanagement. It started with code reviews, commenting on every minor issue I could find.
Addressing vendor security is a significant and inescapable problem for any modern company. Like many other companies, Dropbox has external third-party integrations with our products, and we also use vendors for internal services, from HR workflows to sales, marketing, and IT. In many ways, vendors play a critical part in Dropbox’s overall security posture and thus require appropriate scrutiny from our security team based on the risk posed by the vendor and feasible mitigations.
Today, we’re sharing the results of an experiment to improve vendor security assessments—directly codifying reasonable security requirements into our vendor contracts. We’re also sharing our model security legal terms and making them freely available for anyone to use and modify.
Editor’s note: On January, 18, 2019 the Dropbox Design blog featured a post from Product Designer, Jenny Wen, on working with engineers. This post covers the topic from an engineer’s perspective.
One of my favorite things as an engineer building Paper is how closely I get to work with designers. It’s an important partnership. When we share the same goals, work closely together, and understand what is important to each other we can create things that we would never be able to accomplish on our own. The opposite is also true. When we don’t align early,
This is the first in a series of posts that Dropbox Principal Engineer James Cowling has published on his personal Medium blog about technical leadership. Being a strong tech lead is very different from being a strong engineer and we thought the readers of our tech blog would find his experiences relevant and interesting.
Back when I was a first-time tech lead at Dropbox I had the misfortune of juggling two intimidating responsibilities at the same time:
- Build a multi-exabyte distributed storage system and migrate our data off Amazon S3,
The Dropbox desktop client is relied on by millions of users across the world to save their most important files and keep them in sync across their devices. Weighing in at over 1 million lines of Python logic, we had a massive surface area for potential issues in our migration from Python 2 to Python 3. In this process, we knew that we had to be worthy of the trust that users place in Dropbox and keep their information safe.
Over the last few months, we’ve explored why and how we rolled out our Python 3 migration,
Apache Kafka is a popular solution for distributed streaming and queuing for large amounts of data. It is widely adopted in the technology industry, and Dropbox is no exception. Kafka plays an important role in the data fabric of many of our critical distributed systems: data analytics, machine learning, monitoring, search, and stream processing (Cape), to name a few.
At Dropbox, Kafka clusters are managed by the Jetstream team, whose primary responsibility is to provide high quality Kafka services. Understanding Kafka’s throughput limit in Dropbox infrastructure is crucial in making proper provisioning decision for different use cases,