The Power of No
-
PIEBALDconsult wrote:
e.g. ones which Excel recognizes as "CSV" as it's the de facto Standard for "CSV".
That can bring problems... I am in the CSV world at the moment too, and it is a pity because German Excel wants "," for decimal separation, but c++ wants "." for decimal separator. Having a:
Line 1_1; Line 1_2;
2 empty
Line 3_1; Line 3_2; Line 3_3; Line 3_4;
Line 4_1; Line 4_2; Line 4_3; Line 4_4;
Line x_1; Line x_2; Line x_3; Line x_4;Opening in Excel to edit something and saving it, then opening with another text editor then you have:
Line 1_1; Line 1_2;;;
;;;;
Line 3_1; Line 3_2; Line 3_3; Line 3_4;
Line 4_1; Line 4_2; Line 4_3; Line 4_4;
Line x_1; Line x_2; Line x_3; Line x_4;Note the additional ";" in lines 1 and 2 And yes... I know, but that's the csv I get from customers... First line is variable and can be less or more than the data part (at least data is a "rectangle")
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Nelek wrote:
but that's the csv I get from customers
:laugh: Glad I'm not the only one! I have one customer's csv import that looks like this:
"1201,05-41-2100-AP,12033.32,07-01-2020,07-31-2020"
Yes, each line is encapsulated in double quotes not to mention the blank lines and subotals/totals spread throughout. This is what they give me, and if I can possibly make things work, I handle it...in this case checking each line for a 34 at the beginning and ending, except where matching pairs occur without a comma, etc. :doh: After 20 years of dealing with imports, nothing surprises me anymore! It has resulted in some highly customizable options bloat. One gripe I have about working with .csv files is the fact that Excel will automatically strip leading 0s simply by opening the file, even without saving. :confused:
"Go forth into the source" - Neal Morse
-
I often work with people from other cultures (programmers, customers, etc) where NO is forbidden. It makes life more polite and unnecessarily difficult. Even if I ask something as simple as "Do you understand?" and the heads politely nod 'yes' regardless of whether they followed me or not. X|
Working with the Japanese can be soooo frustrating. I built an entire solution based on their response only to find out it was completely wrong. We had to send an interpreter to Japan to get straight answers.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
You calculate / compile "function points" and using a "gearing factor" (per language), calculate total man-hours based on historical output per FP (one needs in-house FP stats or an industry estimate). That's the number management gets. How many people they budget is then their problem.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
Yeah, but this wasn't about hours, but when we could deliver to the customer.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
-
The best project manager I worked with used to take my estimates and treble them - the estimates were then generally accurate. A decent project manager will ask for an estimate knowing that it's really a bit of a guess and communicate that when asking the question.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
Never, ever, met one like that.... :sigh:
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
I've always been a fan of saying "no" when it's needed. As long as it's done the proper way, I find it only helps with planning and actually improves your professional image in the eye of your counterpart. Well, managers are often an exception to that rule, alas! :laugh: A few years ago I had a particularly funny (though it was NOT funny for me at the time!) eexperience: a big client's PM called me to discuss the schedule of a rather big project. She sent me the whole planning and we went through all the deadlines and discussed in detail all activities. In the end, it was a demanding schedule, but not impossible. I was positively surprised, and agreed that it was doable. That's when I commented on a date for a meeting: I was not available on that specific day. She told me to ignore the dates on the schedule... I said "what?". She said yeah of course the schedule was about the time it would take to complete the project, but the date on the schedule were all off: the project would start the next day instead of the next month... Let's just say that I answered with something more... articulate than a simple "no" :laugh:
In theory, there is no difference between theory and practice, but not in practice. - Anonymous A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
-
Working with the Japanese can be soooo frustrating. I built an entire solution based on their response only to find out it was completely wrong. We had to send an interpreter to Japan to get straight answers.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
In English we have "The customer is always right." In Japanese they say "The customer is God."
-
The best project manager I worked with used to take my estimates and treble them - the estimates were then generally accurate. A decent project manager will ask for an estimate knowing that it's really a bit of a guess and communicate that when asking the question.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
I use pi as a multiplier ... it sounds much more scientific when I explain how I adjusted the estimate and it gives even more wiggle room.
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
I never understood why people are so tied up in dates. Understanding dependencies is better for everyone, and just simpler. "Here are the things we need to happen before X. Whenever those things are in line, we can start work on X." You know, the basics of iterative development. It's even o.k. to give a rough timeframe for X (assuming it's reasonably well-defined, or the business people understand and buy into it being rough). But that doesn't define a date from now, it (roughly) defines a date from start of X. Good luck, Marc.
-
A company I once worked for wanted to outsource a project to a team in Romania. So, three managers (also the owners of the company) get on a flight to meet the team and discuss the project for three whole days. When they get back, one of them asks me "can you make an estimation for the project?" So obviously I ask if the remote team shouldn't make an estimation since they would be building it. They did make an estimation, but my manager didn't trust it because it was only one or two months away, which they were never going to make, and now he had more confidence in my estimations. So I aks him how many developers there were on the project. He didn't know :wtf: I asked him what the hell they talked about if they didn't talk about (believable) estimates and size of the team. He answered something like "other things, but not that." So I asked him how the hell he expected me to plan something I don't know anything about. His reply was "I know it's just guess work, so just guess" :wtf: So I "guessed" their original estimate would be accurate, but he wanted another guess :laugh: I think I answered something like "In that case I guess they'll have a hundred developers so they'll be done by tomorrow", but that wasn't the guess he wanted to hear either :laugh: It was hands down one of the weirdest conversations I've ever had :~ Ultimately, the only correct guess, and maybe you've already guessed it, was "never" :sigh: I left the company a year later and another year later they abandoned the project and lost the customer.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Yup, I sent a "no" to my boss yesterday. Again. If he wants me to produce "CSV files", I'm going to produce proper "CSV files", e.g. ones which Excel recognizes as "CSV" as it's the de facto Standard for "CSV". He, of course, replied that I should use vertical bars rather than commas because the whack-jobs downstream are using a tool which can't read CSV! In fairness, Microsoft's BCP utility can't read CSV either, but these people are supposed to be developers. And so it goes around again. Some uber-whack-job up above must have read a blog post about how good this tool is and dictated that everyone across the enterprise needs to stop using what works and switch to this one. piece of crap. Hey, it's expensive, it must be good! :sigh: And, yeah, the same uber-whack-jobs up above have also dictated that everyone needs to use "Scrum" even though every word out of their mouths proves that they have not the first clue what "Scrum" is. :doh:
At my last job the vendor and I had to transfer data between two different databases. This was at the height of the XML solves everything craze. When my boss, who was also the company owner, came to us and said to use XML we both looked at him and said no, we've already solved this issue with CSV files which are far easier to read and write.
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
After 42+ years of working in corporate development both as an employee and a consultant, I retired. It wasn't the changing technologies but simply the fact that I couldn't work for assholes any longer...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outklook.com
-
At my last job the vendor and I had to transfer data between two different databases. This was at the height of the XML solves everything craze. When my boss, who was also the company owner, came to us and said to use XML we both looked at him and said no, we've already solved this issue with CSV files which are far easier to read and write.
Best to do it without writing it to disk at all though, read from one database and write to the other. CSV is evil. Particularly in the absence of a standard. I try to avoid it. My boss was on a JSON kick for a while, he'd read a blog post. It seems that he is incapable saying "no".
-
Nelek wrote:
but that's the csv I get from customers
:laugh: Glad I'm not the only one! I have one customer's csv import that looks like this:
"1201,05-41-2100-AP,12033.32,07-01-2020,07-31-2020"
Yes, each line is encapsulated in double quotes not to mention the blank lines and subotals/totals spread throughout. This is what they give me, and if I can possibly make things work, I handle it...in this case checking each line for a 34 at the beginning and ending, except where matching pairs occur without a comma, etc. :doh: After 20 years of dealing with imports, nothing surprises me anymore! It has resulted in some highly customizable options bloat. One gripe I have about working with .csv files is the fact that Excel will automatically strip leading 0s simply by opening the file, even without saving. :confused:
"Go forth into the source" - Neal Morse
Bah! That's nothing. How about a "CSV" file which is actually multiple tables of data interleaved? Each line begins with the name of the table it belongs to. Something like this:
Teacher,Name,Subject,Room
Student,Name,Grade
Class,Name,Teacher,Room,Limit,Enrollment
Teacher,John Smith,Logic,42
Student,Jane Doe,12
Student,John Doe,12
Class,Advanced Logic,John Smith,42,20,Jane Doe|John Doe -
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
Same here. we had a PM pushed on us recently, and wanted break downs for every step on every project with completion dates for each step. That was a solid no from us also. there are just two of us devs at our community college, not only do we have daily tickets, a backlog of apps to fix, upgrade, or create we also now have a new data store/schema coming from the state that we have to migrate to in the next year. With everyone working from home, i understand they want some sort of metric on our day to day to make sure things are getting done, but this is not the way. things change too much from day to day. like the other day I got everything cleared away to get back to working on an upgraded app; 2 hours in everything got derailed when an emergency came in that used up the rest of the day. I've been told in the past (different PM), if you know how long it takes to put a button on the screen you can estimate how long to do everything else. :wtf: everyone who has actually done software development, can give educated guesses like that feature might take 3-4 days, but actually takes 1 day or 1 week, but don't hold me to the educated guesses especially when other things popup. Same PM told me all programming is simple; it's just 'click,click,click' :wtf: :wtf: I've been doing Dev work for over 20 years now and have not missed a deadline yet, and all without any PM. PM's should be there to organize information and keep all parties updated, and a source to dig up information needed, but please putting a measurement on dev's productivity with dates is dumb, might as well go back to KLOC measurements, absolutely meaningless, since I could say that feature will be done in 6 months finish it off in 3 hours and take the rest of the time off.
-
Never, ever, met one like that.... :sigh:
I have come across a few project managers who are like that, project managers who want to help the people they work with are not that rare. I sometimes wonder if the contempt some devs feel for some project managers is what is partly responsible for the occasional problems between project managers and devs. I have generally found that if as a dev I take the time to explain the complexity and issues involved then most project managers are quite grateful, understanding and do their best to support me as a dev.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
Aaaand another developer is labelled a Prima Donna that is hard to work with. Heavy sigh. Ok, yes, you should say, "No" sometimes. As a developer that wants to be helpful and driven by a sense of purpose, it is hard to say, "No". I've erred more on the optimistic side by saying, "Yes" and then having to work heroically (ie late nights and weekends) to meet my commitments. Chalk that up to experience. Instead of simply a one word answer that is perfectly realistic but not helpful, why not follow up with what you CAN do? Then list all your risks and unknowns so that the PM and the rest of the team can track them, revisit them each week until the risk is dealt with or the unknowns become known. If your worst fears are realized then you look like a prescient genius. If not, no one will bother to remember. A good PM will not simply manage the schedule but will also manage the risks and unknowns. The PM will help to develop contingency plans, re-negotiate the schedule and resources, and escalate issues that are blocking you or other team members to keep the project on track so you can focus on the technical issues. The PM can only succeed if he/she has good info to manage the project and depends on the technical folks for that information. A bad PM will only manage the schedule and hold everyone to the earliest date ever uttered by anyone at any time based on any assumptions. So, document your risks and unknowns along the way for the post mortem, err, uhh, retrospective. Keep your friends close and your PM closer. :)
-
Aaaand another developer is labelled a Prima Donna that is hard to work with. Heavy sigh. Ok, yes, you should say, "No" sometimes. As a developer that wants to be helpful and driven by a sense of purpose, it is hard to say, "No". I've erred more on the optimistic side by saying, "Yes" and then having to work heroically (ie late nights and weekends) to meet my commitments. Chalk that up to experience. Instead of simply a one word answer that is perfectly realistic but not helpful, why not follow up with what you CAN do? Then list all your risks and unknowns so that the PM and the rest of the team can track them, revisit them each week until the risk is dealt with or the unknowns become known. If your worst fears are realized then you look like a prescient genius. If not, no one will bother to remember. A good PM will not simply manage the schedule but will also manage the risks and unknowns. The PM will help to develop contingency plans, re-negotiate the schedule and resources, and escalate issues that are blocking you or other team members to keep the project on track so you can focus on the technical issues. The PM can only succeed if he/she has good info to manage the project and depends on the technical folks for that information. A bad PM will only manage the schedule and hold everyone to the earliest date ever uttered by anyone at any time based on any assumptions. So, document your risks and unknowns along the way for the post mortem, err, uhh, retrospective. Keep your friends close and your PM closer. :)
-
I have come across a few project managers who are like that, project managers who want to help the people they work with are not that rare. I sometimes wonder if the contempt some devs feel for some project managers is what is partly responsible for the occasional problems between project managers and devs. I have generally found that if as a dev I take the time to explain the complexity and issues involved then most project managers are quite grateful, understanding and do their best to support me as a dev.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
GuyThiebaut wrote:
if as a dev I take the time to explain the complexity and issues involved then most project managers are quite grateful, understanding and do their best to support me as a dev.
This has been hit and miss for me in the past. Some PMs really do care about this, others don't. If you don't make them look good, they couldn't care less about your problems. Often times promises are made there are discussions with management / clients that happen without consulting the delivery team, and then they don't want to listen to anything that makes them look bad. In my experience, some are little more than task admins. They come with a list of tasks asking "Is task x done yet?" and move on. But I have had those that really care about enabling the delivery team, and those are to be treasured.
