6 ms·

I’ve been pondering this a lot lately, as an engineering leader. Masters in my organization have an extremely high ratio of value shipped to hours worked. Thi

I’ve been pondering this a lot lately, as an engineering leader. Masters in my organization have an extremely high ratio of value shipped to hours worked. This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such that the cost of adding more value to the system remains constant as the system grows in complexity.

bribri 6y ago
I agree with this. The best engineers choose the best targets
taphangum 6y ago
Fantastic definition.
yowlingcat 6y ago
> the best ones can direct a whole team away from large swaths of work that is not valuable Can't overstate how valuable this is. A team which can expose its members to this kind of leadership by example and direct collaboration will grow and outproduce teams which don't by an order of magnitude.
hiimtroymclure 6y ago
> They are able to discern and avoid work that does not provide value (this is often their greatest skill) junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
- aste-risk 6y ago
  There are some teams that only work on high impact projects. If you feel that your current team is only doing work that's not valuable, you need to change teams or at least let your manager know to change your project. Ask for projects that you think will bring revenue to the company. Revenue = impact or increase in productivity of other engineers (this may involve writing an internal tool, etc.)
- mkinsella 6y ago
  This is the biggest difference between a Junior Engineer and a Senior (or Staff Engineer). A Senior Engineer knows what the highest-value work is and is influencing/driving the roadmap. A Senior Engineer says 'no' more often than 'yes' and backs it up with a 'why.'
  - ZephyrBlu 6y ago
    It's kind of a self-fulfilling prophecy though. Most Seniors are driving the roadmap simply by virtue of being a Senior, and most Juniors have no opportunity to influence the roadmap because Seniors control the decisions. Of course ideally everyone can contribute, but I think that's relatively rare.
    - mixermachine 6y ago
      If the structure of a work place is very strict, then yes this is 100% true. I how ever could already experience a more open scrum process in which we all have a say. For me it all started in an university project with four (incl me) people. I denied a good portion of the requests my supervisor gave me there, not because they were bad, but because they simply did not fit into the time budget or were not realistic. She was actually very happy about that because she was not that tech savy back then and learned a lot threw the process. Very good experience for me and we finished the project on time and exceeded expectations.
- DougWebb 6y ago
  I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal. A problem came up. Many of the libraries were government funded, and required physical possession of any books they purchased. I was in a meeting with the c-level execs, sales directors, and pms, and they were planning out the cost of building an organization that would produce a cd-rom version of the textbook products. They were going to need a large team to manage creating the books on cd, and for managing the production and mailing of the CDs when orders were received. It was going to cost a fortune. I told them to hang on a minute: I'm already converting the xml for these books into html for display in the app. I can easily generate static html too, write it to disk, and generate an iso file, every time we publish a new book. Then I can add a download link in the webapp, and if they need a physical copy they can download and burn it to disk themselves. We'll include instructions. This will take me maybe an extra week, and we'll have no ongoing operational costs. I think I got a $50 Amazon gift card for that suggestion. Or maybe a Starbucks card.
  - banner2018 6y ago
    Precisely the reason why next time you would consider debating what's in it for me, prior to blurting out a solution.
    - Ma8ee 6y ago
      I hope you are joking: “I, a paid employee, have a wonderful solution to our problem that will save the company a lot of money, but I won’t tell you if you don’t pay me even more.” I think the answer to that would be something like “hmm, if you aren’t willing to do your job for the salary we already pay you, I don’t think there’s any reason to pay you at all.”
  - hiimtroymclure 6y ago
    Thank you for the story, I definitely understand now. I am also relieved that you were compensated for this critically important pivot! /s I am hoping this will be an area I can eventually excel in. I was a senior PM for a while and decided I wanted to write code instead. Been going down this crazy career change for about 6 months now. Right now I am just trying to survive and learn the basics of software development. When I was PM I certainly had the luxury of working with invaluable devs I could brainstorm with on ways to optimize a feature idea that maintained customer value in the shortest time possible. I need to learn how to become that invaluable dev I had.
- arrosenberg 6y ago
  > Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too. Experience flips this equation around. The PM is creating the roadmap based on my input and expertise to decide what will be the most valuable use of resources. You move from construction worker to architect.
- jmchuster 6y ago
  As stated by a previous head of product, great senior engineers can choose to switch jobs and instantly become a great PM.
- deleted 6y ago
  [deleted]
- P_I_Staker 6y ago
  It's very easy to get distracted as a developer on something that adds little to no value. You will do this repeatedly throughout your career. Try not to :) It may also depend how much you're micromanaged vs. picking your own path. Sounds like you're saying none of your work is self directed, and you don't participate in design decisions yet? Anyway, even if you don't have much say there's still ways to direct your work. You can push back against whatever is demanding the low value work.
bedobi 6y ago
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
- banner2018 6y ago
  Precisely my observation of last couple decades.
- stonecharioteer 6y ago
  This happens to me at my organization fairly often. I build solutions I'm asked to build and then an abusive architect coopts that work and rewrites it in a shitty, unusable way. Users cry at me, but when I tell them what happened, they are silent. No one cares enough to cry to leadership. And the leadership have clearly said they have no intention of overruling what said architect talks about.
  - intricatedetail 6y ago
    Sounds like trauma bonding. I'd leave yesterday unless there is a bad market.
  - deleted 6y ago
    [deleted]
  - davewritescode 6y ago
    Leadership puts an architect in place because they don't have the time to care about code level details. I would personally mention it to leadership but frame it in a way that your work is being rejected but nobody is explaining to you why so that you can learn and do better next time. Unfortunately in a large software engineering organization tact and political savvy is more important than raw engineering skill. Once you've been in the industry long enough, you'll understand it. One of the problems that's common in organizations is that most of the work at the junior level is highly focused on individual contribution and that completely flips at some point in your career.
m463 6y ago
I think sometimes this means they do the unsexy stuff. For instance, having an easy build process, or understanding version numbers, or preventing an upgrade to this year's compiler.
- k3liutZu 6y ago
  Enabling the org to accomplish more with less (or keep it from falling into different pitfalls) is sexy. I feel it's a core part of my job to keep the rest of the eng team happy and producing value. A lot of times this comes down to seeing problems as they arise (ideally before them, but it gets harder to convince management of future issues if they haven't manifested yet).
  - m463 6y ago
    > it gets harder to convince management of future issues that's a tough one, maybe the tough one. It's hard to prioritize "trivialities" over features, especially when you haven't even given thought to defending the obvious. Thankfully some of these things are being codified somewhere externally, say: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
Cthulhu_ 6y ago
It reminds me of a guy I used to work with. He two-finger typed looking at his keyboard all the time, but the code he did end up writing was exactly what was needed. Consistency and quality was much more important than cold, hard "productivity".
- mechEpleb 6y ago
  Can anybody actually produce working code at the same pace as they touch type? Typing hardly registers as a factor when it comes to how long it takes for me to code anything, at least.
  - Aeolun 6y ago
    Depends on how often I’ve done something similar before.
  - tbrownaw 6y ago
    Depending on what I'm working on, just dumping stuff to an IDE buffer at 70WPM can be 10% or more of the time something takes. Which is enough that typing slower would have a noticeable impact.
  - narag 6y ago
    Can anybody actually produce working code at the same pace as they touch type? I can. Actually, when I learned touch typing I realized how much was I slowed down by typing before. You might argue that I need to think for a time before I start typing. That's right. But: 1) Once I start, it flows and it's like I'm reviewing the code as I type, correcting and expanding. 2) Writing fast somehow makes me think faster for the next "pre-typing" thinking cycle.
  - dhsysusbsjsi 6y ago
    It’s faster for typing my question into stackoverflow!
  - hliyan 6y ago
    Absolutely. Touch typing is a game changer, not only because with practice, you can just think the code and see it appear on screen, but because you no longer have to glance at the keyboard and your full attention is on the code.
mstipetic 6y ago
Can we stop using this word leader? What's wrong with the word manager?
- JackMorgan 6y ago
  They're totally different words. I used to be an engineering manager with direct reports who wasn't really much a leader. Today I'm an engineering leader without any direct reports. Leadership happens from the front and doesn't really have anything at all to do with year end reports and making sure everyone shows up on time. Management rarely does more than HR busywork. The way many engineering mangers work they often have skills so outdated as to be effectively non-technical. Leadership can happen at all levels regardless of title. Leaders often are some of the most skilled technicians, able to have an outsized impact on both the team and the direction.
  - mstipetic 6y ago
    I think that's an artificial split. Management is not only about HR busywork, it should also include all the things you've mentioned in the leader category. Is it an official title? I keep seeing it everywhere now, everyone is a "leader." What exactly does it mean? Do you proclaim yourself a leader, is there some vote on it? From my perspective it's completely meaningless and usually ego stroking.
dusted 6y ago
One has to be very careful in determining what work amounts to "value shipped". It's not uncommon to have a few persons who seem to ship all the value, while the rest.. just enable them to do so, by doing the required, but invisible stuff, like the refactoring required for the new feature to ship, or fixing the bugs that makes the customers not leave, or attend those meetings that has to be attended by someone. This is somewhat related to the 10x engineer story, sure, some are a lot better than others, but sometimes it's not entirely undue to their situation. Maybe it is a skill too, to be aggressive enough to grab the work that looks most valuable and push that through, leaving your team to do the rest.
hyperpallium2 6y ago
(just unpacking) Prediction of value, initially and over time, requires market analysis. Given that, predicting which projects will produce that value, and which designs will accommodate future additions of value, is engineering. I still like Parnas's On the Criteria to Be Used in Decomposing Systems into Modules, where the choice of "information hiding" requires predicting what is likely to change - and predicting value.
jl2718 6y ago
Imagine an evaluation system based on this principle. It would be simple cost minus benefit, without regard to technical merit or project milestones or other silly process-based evaluation. This is the opposite of most companies. Generally promotions have to do with the size/cost of an employee’s piece of a project, not the benefit. Managers would be fighting to reduce their team sizes. I don’t know how you would back-propagate value though.
pacificleo12 6y ago
Essentially avoid downstream defect correction

bribri 6y ago

I agree with this. The best engineers choose the best targets

taphangum 6y ago

Fantastic definition.

yowlingcat 6y ago

> the best ones can direct a whole team away from large swaths of work that is not valuable Can't overstate how valuable this is. A team which can expose its members to this kind of leadership by example and direct collaboration will grow and outproduce teams which don't by an order of magnitude.

hiimtroymclure 6y ago

> They are able to discern and avoid work that does not provide value (this is often their greatest skill) junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.

aste-risk 6y ago
There are some teams that only work on high impact projects. If you feel that your current team is only doing work that's not valuable, you need to change teams or at least let your manager know to change your project. Ask for projects that you think will bring revenue to the company. Revenue = impact or increase in productivity of other engineers (this may involve writing an internal tool, etc.)
mkinsella 6y ago
This is the biggest difference between a Junior Engineer and a Senior (or Staff Engineer). A Senior Engineer knows what the highest-value work is and is influencing/driving the roadmap. A Senior Engineer says 'no' more often than 'yes' and backs it up with a 'why.'
- ZephyrBlu 6y ago
  It's kind of a self-fulfilling prophecy though. Most Seniors are driving the roadmap simply by virtue of being a Senior, and most Juniors have no opportunity to influence the roadmap because Seniors control the decisions. Of course ideally everyone can contribute, but I think that's relatively rare.
  - mixermachine 6y ago
    If the structure of a work place is very strict, then yes this is 100% true. I how ever could already experience a more open scrum process in which we all have a say. For me it all started in an university project with four (incl me) people. I denied a good portion of the requests my supervisor gave me there, not because they were bad, but because they simply did not fit into the time budget or were not realistic. She was actually very happy about that because she was not that tech savy back then and learned a lot threw the process. Very good experience for me and we finished the project on time and exceeded expectations.
DougWebb 6y ago
I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal. A problem came up. Many of the libraries were government funded, and required physical possession of any books they purchased. I was in a meeting with the c-level execs, sales directors, and pms, and they were planning out the cost of building an organization that would produce a cd-rom version of the textbook products. They were going to need a large team to manage creating the books on cd, and for managing the production and mailing of the CDs when orders were received. It was going to cost a fortune. I told them to hang on a minute: I'm already converting the xml for these books into html for display in the app. I can easily generate static html too, write it to disk, and generate an iso file, every time we publish a new book. Then I can add a download link in the webapp, and if they need a physical copy they can download and burn it to disk themselves. We'll include instructions. This will take me maybe an extra week, and we'll have no ongoing operational costs. I think I got a $50 Amazon gift card for that suggestion. Or maybe a Starbucks card.
- banner2018 6y ago
  Precisely the reason why next time you would consider debating what's in it for me, prior to blurting out a solution.
  - Ma8ee 6y ago
    I hope you are joking: “I, a paid employee, have a wonderful solution to our problem that will save the company a lot of money, but I won’t tell you if you don’t pay me even more.” I think the answer to that would be something like “hmm, if you aren’t willing to do your job for the salary we already pay you, I don’t think there’s any reason to pay you at all.”
- hiimtroymclure 6y ago
  Thank you for the story, I definitely understand now. I am also relieved that you were compensated for this critically important pivot! /s I am hoping this will be an area I can eventually excel in. I was a senior PM for a while and decided I wanted to write code instead. Been going down this crazy career change for about 6 months now. Right now I am just trying to survive and learn the basics of software development. When I was PM I certainly had the luxury of working with invaluable devs I could brainstorm with on ways to optimize a feature idea that maintained customer value in the shortest time possible. I need to learn how to become that invaluable dev I had.
arrosenberg 6y ago
> Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too. Experience flips this equation around. The PM is creating the roadmap based on my input and expertise to decide what will be the most valuable use of resources. You move from construction worker to architect.
jmchuster 6y ago
As stated by a previous head of product, great senior engineers can choose to switch jobs and instantly become a great PM.
deleted 6y ago
[deleted]
P_I_Staker 6y ago
It's very easy to get distracted as a developer on something that adds little to no value. You will do this repeatedly throughout your career. Try not to :) It may also depend how much you're micromanaged vs. picking your own path. Sounds like you're saying none of your work is self directed, and you don't participate in design decisions yet? Anyway, even if you don't have much say there's still ways to direct your work. You can push back against whatever is demanding the low value work.

bedobi 6y ago

I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.

banner2018 6y ago
Precisely my observation of last couple decades.
stonecharioteer 6y ago
This happens to me at my organization fairly often. I build solutions I'm asked to build and then an abusive architect coopts that work and rewrites it in a shitty, unusable way. Users cry at me, but when I tell them what happened, they are silent. No one cares enough to cry to leadership. And the leadership have clearly said they have no intention of overruling what said architect talks about.
- intricatedetail 6y ago
  Sounds like trauma bonding. I'd leave yesterday unless there is a bad market.
- deleted 6y ago
  [deleted]
- davewritescode 6y ago
  Leadership puts an architect in place because they don't have the time to care about code level details. I would personally mention it to leadership but frame it in a way that your work is being rejected but nobody is explaining to you why so that you can learn and do better next time. Unfortunately in a large software engineering organization tact and political savvy is more important than raw engineering skill. Once you've been in the industry long enough, you'll understand it. One of the problems that's common in organizations is that most of the work at the junior level is highly focused on individual contribution and that completely flips at some point in your career.

m463 6y ago

I think sometimes this means they do the unsexy stuff. For instance, having an easy build process, or understanding version numbers, or preventing an upgrade to this year's compiler.

k3liutZu 6y ago
Enabling the org to accomplish more with less (or keep it from falling into different pitfalls) is sexy. I feel it's a core part of my job to keep the rest of the eng team happy and producing value. A lot of times this comes down to seeing problems as they arise (ideally before them, but it gets harder to convince management of future issues if they haven't manifested yet).
- m463 6y ago
  > it gets harder to convince management of future issues that's a tough one, maybe the tough one. It's hard to prioritize "trivialities" over features, especially when you haven't even given thought to defending the obvious. Thankfully some of these things are being codified somewhere externally, say: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Cthulhu_ 6y ago

It reminds me of a guy I used to work with. He two-finger typed looking at his keyboard all the time, but the code he did end up writing was exactly what was needed. Consistency and quality was much more important than cold, hard "productivity".

mechEpleb 6y ago
Can anybody actually produce working code at the same pace as they touch type? Typing hardly registers as a factor when it comes to how long it takes for me to code anything, at least.
- Aeolun 6y ago
  Depends on how often I’ve done something similar before.
- tbrownaw 6y ago
  Depending on what I'm working on, just dumping stuff to an IDE buffer at 70WPM can be 10% or more of the time something takes. Which is enough that typing slower would have a noticeable impact.
- narag 6y ago
  Can anybody actually produce working code at the same pace as they touch type? I can. Actually, when I learned touch typing I realized how much was I slowed down by typing before. You might argue that I need to think for a time before I start typing. That's right. But: 1) Once I start, it flows and it's like I'm reviewing the code as I type, correcting and expanding. 2) Writing fast somehow makes me think faster for the next "pre-typing" thinking cycle.
- dhsysusbsjsi 6y ago
  It’s faster for typing my question into stackoverflow!
- hliyan 6y ago
  Absolutely. Touch typing is a game changer, not only because with practice, you can just think the code and see it appear on screen, but because you no longer have to glance at the keyboard and your full attention is on the code.

mstipetic 6y ago

Can we stop using this word leader? What's wrong with the word manager?

JackMorgan 6y ago
They're totally different words. I used to be an engineering manager with direct reports who wasn't really much a leader. Today I'm an engineering leader without any direct reports. Leadership happens from the front and doesn't really have anything at all to do with year end reports and making sure everyone shows up on time. Management rarely does more than HR busywork. The way many engineering mangers work they often have skills so outdated as to be effectively non-technical. Leadership can happen at all levels regardless of title. Leaders often are some of the most skilled technicians, able to have an outsized impact on both the team and the direction.
- mstipetic 6y ago
  I think that's an artificial split. Management is not only about HR busywork, it should also include all the things you've mentioned in the leader category. Is it an official title? I keep seeing it everywhere now, everyone is a "leader." What exactly does it mean? Do you proclaim yourself a leader, is there some vote on it? From my perspective it's completely meaningless and usually ego stroking.

dusted 6y ago

One has to be very careful in determining what work amounts to "value shipped". It's not uncommon to have a few persons who seem to ship all the value, while the rest.. just enable them to do so, by doing the required, but invisible stuff, like the refactoring required for the new feature to ship, or fixing the bugs that makes the customers not leave, or attend those meetings that has to be attended by someone. This is somewhat related to the 10x engineer story, sure, some are a lot better than others, but sometimes it's not entirely undue to their situation. Maybe it is a skill too, to be aggressive enough to grab the work that looks most valuable and push that through, leaving your team to do the rest.

hyperpallium2 6y ago

(just unpacking) Prediction of value, initially and over time, requires market analysis. Given that, predicting which projects will produce that value, and which designs will accommodate future additions of value, is engineering. I still like Parnas's On the Criteria to Be Used in Decomposing Systems into Modules, where the choice of "information hiding" requires predicting what is likely to change - and predicting value.

jl2718 6y ago

Imagine an evaluation system based on this principle. It would be simple cost minus benefit, without regard to technical merit or project milestones or other silly process-based evaluation. This is the opposite of most companies. Generally promotions have to do with the size/cost of an employee’s piece of a project, not the benefit. Managers would be fighting to reduce their team sizes. I don’t know how you would back-propagate value though.

pacificleo12 6y ago

Essentially avoid downstream defect correction