> Dropbox measures the success of its engineers largely on business impact.
Why call them engineers? I understand this is standard in the industry but I'm a bit fed up with the confusing corporate vocabulary that has multiple loaded meanings. If business impact is the priority, then you are a business person. Software engineering is about software engines, computer science and mathematical logic.
> If business impact is the priority, then you are a business person. Software engineering is about software engines, computer science and mathematical logic.
Don’t worry, if the AI hype is correct, this line will be drawn much more clearly.
> Software engineering is about software engines, computer science and mathematical logic.
That might be a bit naive as a definition though; ultimately, it's about applying all of that to build things and, in the context of companies selling the things being built, driving value. Outside of the kind of RnD that essentially bankrolls folks to give them the space to go deep on ideas and not necessarily think about marketability, most engineering is about making something so it can create some business or community value somewhere.
Looking at how impact is defined here is also important, looking at the same section:
> Impact starts and ends with better serving our customers, which, in turn, helps Dropbox succeed as a business. Adoption and consistent usage of new features, keeping a demanding component of our infrastructure going, improving efficiency in our operations, reducing operational or capital expenses, improving durability of our data storage, and malware scanning of shared files are all examples that help our customers and Dropbox win.
These are great examples of how engineers can have an impact on the business without being "business people".
I'm aware this is the current industry standard, at least in large orgs. It seems to me it's undermining the amount of effort it takes to learn and practice engineering because it is evidently not enough value by itself. I think worrying about what the customer wants or coordinating and scheduling projects is not strictly engineering. Some non-technical tasks are required of course, but allowing technical roles to optimize and maximize their expertise, I would think, has huge payoffs for the business, i.e. feature development gets automated in ways that are decoupled from business requirements, drastically reducing development time.
I've always seen engineering largely as "science applied to the context of business/public good", that was the definition that was embedded in much of my education as an engineer as well (in part represented by the ethics / general business / project management et al. courses that were complementary to the ones focused on technology). In that lens, software/computer engineering always seemed like "computer science, but with more formal emphasis on feasibility (cost/time/effort/resources) and ethics. This also keeps front and center the idea that technology doesn't exist in a vacuum (i.e. code that implements feature isn't produced in isolation from the people who will use, sell and/or distribute it and should take that into consideration to be a true fit).
While I agree that focus can, in certain cases, make things happen faster, I also think that disconnect from how things are used and how they are used can easily lead folks to build the wrong thing quickly and have to circle back, whereas a more holistic vision of the product can help steer development in the right direction earlier. That's not to say that the "non-technical" (here, specifically "concerns that aren't directly related to the technology and implementation) should have a disproportionate weight, but I find that having it occupy some space can benefit the end result, because adding dimensions to engineering work beyond the pure technical stuff can add interesting perspective. In a way, it's not that different from the non-engineering electives that act as complementary coursework in most curricula that I've seen or heard of.
Digging into a few key points that caught my eye in the above:
> It seems to me it's undermining the amount of effort it takes to learn and practice engineering because it is evidently not enough value by itself.
I would love to know more about this: why is framing engineering work in terms of business value undermining the effort needed to get there? In the end, the business still needs technical experts (of all kinds, because other departments can be pretty technical in their own way), but the business also exists to do business and tends to frame everything it does in terms of "how does this help us win in the marketplace?"
> I think worrying about what the customer wants or coordinating and scheduling projects is not strictly engineering.
To my earlier bit about engineering having (IMO) a broader scope than the pure technical execution, I think that it's not necessarily about worrying about it, but rather taking it into consideration. Caring about business impact is less "how can I build this so the user will love it and renew" (that would be the main focus of other roles) and more "knowing how this is used by people, how can I make it better fit?"
Similarly, I would argue that coordinating and scheduling projects is squarely within engineering concerns (back to the thoughts about engineering being "science-applied-to-business") -- as an engineer matures, it's likely that they'll take a greater hand in driving projects (not as management but as seasoned technical voices, because technically-focused paths should and are a thing) to completion. It's all part of having a growing sphere of influence (i.e. at first, hyperfocus on your individual piece, but as time grows, more and more awareness of how the team's pieces fit with other teams'). At least, that's my anecdotal datapoint of how I work at $JOB and how a well-rounded org could operate.
5 comments
[ 3.1 ms ] story [ 35.0 ms ] threadWhy call them engineers? I understand this is standard in the industry but I'm a bit fed up with the confusing corporate vocabulary that has multiple loaded meanings. If business impact is the priority, then you are a business person. Software engineering is about software engines, computer science and mathematical logic.
Don’t worry, if the AI hype is correct, this line will be drawn much more clearly.
That might be a bit naive as a definition though; ultimately, it's about applying all of that to build things and, in the context of companies selling the things being built, driving value. Outside of the kind of RnD that essentially bankrolls folks to give them the space to go deep on ideas and not necessarily think about marketability, most engineering is about making something so it can create some business or community value somewhere.
Looking at how impact is defined here is also important, looking at the same section:
> Impact starts and ends with better serving our customers, which, in turn, helps Dropbox succeed as a business. Adoption and consistent usage of new features, keeping a demanding component of our infrastructure going, improving efficiency in our operations, reducing operational or capital expenses, improving durability of our data storage, and malware scanning of shared files are all examples that help our customers and Dropbox win.
These are great examples of how engineers can have an impact on the business without being "business people".
I've always seen engineering largely as "science applied to the context of business/public good", that was the definition that was embedded in much of my education as an engineer as well (in part represented by the ethics / general business / project management et al. courses that were complementary to the ones focused on technology). In that lens, software/computer engineering always seemed like "computer science, but with more formal emphasis on feasibility (cost/time/effort/resources) and ethics. This also keeps front and center the idea that technology doesn't exist in a vacuum (i.e. code that implements feature isn't produced in isolation from the people who will use, sell and/or distribute it and should take that into consideration to be a true fit).
While I agree that focus can, in certain cases, make things happen faster, I also think that disconnect from how things are used and how they are used can easily lead folks to build the wrong thing quickly and have to circle back, whereas a more holistic vision of the product can help steer development in the right direction earlier. That's not to say that the "non-technical" (here, specifically "concerns that aren't directly related to the technology and implementation) should have a disproportionate weight, but I find that having it occupy some space can benefit the end result, because adding dimensions to engineering work beyond the pure technical stuff can add interesting perspective. In a way, it's not that different from the non-engineering electives that act as complementary coursework in most curricula that I've seen or heard of.
Digging into a few key points that caught my eye in the above:
> It seems to me it's undermining the amount of effort it takes to learn and practice engineering because it is evidently not enough value by itself.
I would love to know more about this: why is framing engineering work in terms of business value undermining the effort needed to get there? In the end, the business still needs technical experts (of all kinds, because other departments can be pretty technical in their own way), but the business also exists to do business and tends to frame everything it does in terms of "how does this help us win in the marketplace?"
> I think worrying about what the customer wants or coordinating and scheduling projects is not strictly engineering.
To my earlier bit about engineering having (IMO) a broader scope than the pure technical execution, I think that it's not necessarily about worrying about it, but rather taking it into consideration. Caring about business impact is less "how can I build this so the user will love it and renew" (that would be the main focus of other roles) and more "knowing how this is used by people, how can I make it better fit?"
Similarly, I would argue that coordinating and scheduling projects is squarely within engineering concerns (back to the thoughts about engineering being "science-applied-to-business") -- as an engineer matures, it's likely that they'll take a greater hand in driving projects (not as management but as seasoned technical voices, because technically-focused paths should and are a thing) to completion. It's all part of having a growing sphere of influence (i.e. at first, hyperfocus on your individual piece, but as time grows, more and more awareness of how the team's pieces fit with other teams'). At least, that's my anecdotal datapoint of how I work at $JOB and how a well-rounded org could operate.