For context, I’m a senor dev at a large corporation, that works at a much slower pace than your typical continuous integration web app. If I was to translate “Do you have bandwidth for x” from corpo speak I would say “Are you able to work x to completion without the stakeholders noticing it not progressing” . That encompasses time, but it also needs to account for all the other resources needed to do that task and more intangible things like the latency expected in updates or the amount of mental capacity (some at my company call it “mind ram” which I think is a good metaphor).
Here’s an example. If I have a p1 that takes 1 hour of my time a day before being blocked by other people (this is common in my industry, it’s common for dozens of developers from various specialties to work on the same issue). Because it is high priority and involves many people the important thing is that I work on it immediately when the issue is with me. This is a ticket that takes a lot of bandwidth, but not a lot of time.
If I have been assigned this issue I can work 2 or 3 p2 tickets in addition to that without missing anything. However I wouldn’t have the bandwidth to work on another p1, because if they both needed my attention at the same time, or have a meeting at the same time I wouldn’t be able to appropriately meet the needs of both p1 tickets.
As another example, I need specialized hardware to test certain things. That HW is in short supply and those tests can sometimes run for days. If I have an issue that ties up that hardware, I don’t have the BW for another issue that uses that HW. Although I have all the time in the world for other issues, I lack the BW for any issue that needs that HW.
I was thinking of time and bandwidth as nearly synonymous, with mildly different connotations, but I think your definition of bandwidth is perfect and helps me realize what I subconsciously thought about it but hadn’t defined.
My industry/product are different enough from what you described to not have the same examples, but I realized when I talk about bandwidth (or more often, “capacity”), it’s most often when asking my direct reports if they’re able to take on new work. I realize that like you said, that means if they can work it to completion in whatever timeframe is allotted given their other priorities, and so stakeholders—myself included—see the progress. Given we’re on the Product side, the timescale could be anywhere from hours to a year depending on the topic/project. And typically I want to know because if they don’t think they have the capacity, then we can discuss priorities and what should drop, I can take the work on myself, or I can go back to my own stakeholders and set realistic expectations.
Thanks for taking the time to help me think about this!
For context, I’m a senor dev at a large corporation, that works at a much slower pace than your typical continuous integration web app. If I was to translate “Do you have bandwidth for x” from corpo speak I would say “Are you able to work x to completion without the stakeholders noticing it not progressing” . That encompasses time, but it also needs to account for all the other resources needed to do that task and more intangible things like the latency expected in updates or the amount of mental capacity (some at my company call it “mind ram” which I think is a good metaphor).
Here’s an example. If I have a p1 that takes 1 hour of my time a day before being blocked by other people (this is common in my industry, it’s common for dozens of developers from various specialties to work on the same issue). Because it is high priority and involves many people the important thing is that I work on it immediately when the issue is with me. This is a ticket that takes a lot of bandwidth, but not a lot of time.
If I have been assigned this issue I can work 2 or 3 p2 tickets in addition to that without missing anything. However I wouldn’t have the bandwidth to work on another p1, because if they both needed my attention at the same time, or have a meeting at the same time I wouldn’t be able to appropriately meet the needs of both p1 tickets.
As another example, I need specialized hardware to test certain things. That HW is in short supply and those tests can sometimes run for days. If I have an issue that ties up that hardware, I don’t have the BW for another issue that uses that HW. Although I have all the time in the world for other issues, I lack the BW for any issue that needs that HW.
I love the “mind RAM” phrase, lol.
I was thinking of time and bandwidth as nearly synonymous, with mildly different connotations, but I think your definition of bandwidth is perfect and helps me realize what I subconsciously thought about it but hadn’t defined.
My industry/product are different enough from what you described to not have the same examples, but I realized when I talk about bandwidth (or more often, “capacity”), it’s most often when asking my direct reports if they’re able to take on new work. I realize that like you said, that means if they can work it to completion in whatever timeframe is allotted given their other priorities, and so stakeholders—myself included—see the progress. Given we’re on the Product side, the timescale could be anywhere from hours to a year depending on the topic/project. And typically I want to know because if they don’t think they have the capacity, then we can discuss priorities and what should drop, I can take the work on myself, or I can go back to my own stakeholders and set realistic expectations.
Thanks for taking the time to help me think about this!