Oh no, now he’s going to smell almost like there’s an orange in the next room!
This is peak developer humor
Whoa killer, are you sure you didn’t mean throughput and not bandwidth?
-every system engineer
I know it’s a joke but time is not (or should not be at least)a synonym for bandwidth in the corporate world. A p1 ticket takes more bandwidth than a p2 even if they take the same amount of time to complete.
I’m curious how they differ in your opinion. Can you elaborate?
For context, I’m a Product Manager and it wouldn’t occur to me that either takes more bandwidth. However, I do think “bandwidth” carries a connotation of priority. “I don’t have the time to work on that P1” would be a rather shocking statement to hear, since a P1 should, by definition, be the top priority. “I don’t have the bandwidth to work on that P1” says to me that there’s something equally or more important taking that person’s focus.
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!
How are these really different? If they don’t have time it’s probably because of something equally or more important taking focus.
forgot to take the Fourier transform
What twiddle factor we talking about here?
My product manager is doing the opposite - pushing us to replace “bandwidth” and “effort” with “time”. We’re now expected to provide an accurate hour estimate for all work items, projects, and bugs. Getting it done later or sooner is penalized on the metrics.
“Hey I need you to change the colour on this thing here. How long will it take?”
“let me see… tips furiously on a calculator how about 390 days?”
If you get it done sooner. Just don’t submit it. You are still working on it. Only on the day you predicted you finish it.
Sparkling water gives me PTSD flashbacks of working in a office. I don’t want to go back. I can’t go back. AAAAAAAAAAAAAAAAA
Haha, hey guys! Did you see we have sparkling on tap in the break room? This place is great, isn’t it? Be sure to grab a snack before the morning huddle. Great to be with the team again!
Oh hey GluWu, good to see you back in the office! Whenever you get a chance can you swing by my office? No rush or anything, I just have some questions about your PTO request.
You’re evil. This makes me want to cry.
