31 ms·

The more project management tools I have to work with, the less likely I am to work for or with a company. I have a somewhat similar stance on software archite

by moksly 5y ago

The more project management tools I have to work with, the less likely I am to work for or with a company. I have a somewhat similar stance on software architecture. Sure, I’m TOGAF certified but if you actually expect me to work with notation correct Archimare/UML/whatever and not just draw boxes on a napkin you’re either insane or sell a product with no competition. This is anecdotal of course, but after 30 years of working with hundreds of companies to supply our municipality with software, we have yet to see a correlation between quality and “best practices”. It doesn’t matter if companies do this or that testing and use the full confluence suite or if they just pull spaghetti out of their asses and support is a phone call… the quality is the same over time, hell, often we get more from the spaghetti companies than the “best practice” ones. You might think that it’s a short term thing and that the spaghetti and no testing catches up, but it doesn’t. Maybe because we don’t have to fund those 8 people, that you never really learn the role off but it sure isn’t technical, that sit in on every meeting as opposed to talking directly with the spaghetti slinger and a sales person? I’m not sure, and I’d love to tell people that following this or that “best practice” is the way to go, but that’s just not what our data shows.

quartesixte 5y ago
Credit due where credit is due: these project management software companies have done a good job of convincing people they need it. I've taken to using tools that most closely mimic notepad+pen or whiteboard+marker. Increasingly I am finding that a physical whiteboard, markers, and post-its are good enough. And if you need to create backups, the image quality on any smartphone is very, very good these days. The more time spent working on the thing that manages your work, the less you are working!
- colechristensen 5y ago
  What they do is give middle management something to do. Often questionably necessary, middle management has a hard time doing something when engineers understand the product and upper management has the right balance of setting direction and entrusting decisions to the makers. So they start asking the engineers to do things and get upper management on the train of wanting reporting. Doing that with pen-and-paper engineering and people with context is HARD... so all of these tools exist to make this middle layer of doing work better. And arguably unnecessary people earn a lot of money by convincing themselves and others that they are necessary, so companies get to be organized to have these high overhead tools to support this high overhead style of organization. Now to be honest some level of organization is necessary, and becomes necessary as the enterprise and product grows in complexity, but very very few people work long enough or with a diverse enough set of organizations to be able to see what is necessary and when and what is not. If you hire people and put them in a position and tell them they have to work a certain number of hours they will find or create work to do. Oftentimes this work is not better than doing nothing but the WASP work-ethic and general cultural norms really can't handle the idea that smart, important, useful people can provide the most value sometimes by not doing anything until they are needed.
  - xcambar 5y ago
    > general cultural norms really can't handle the idea that smart, important, useful people can provide the most value sometimes by not doing anything until they are needed. Thank you for this comment. I have had this is mind for quite some time but I never could phrase it in such a clear, articulate, phrasing.
  - jkhdigital 5y ago
    I’d say that they give middle management an out, a way to make their jobs “easy” by just throwing a tool at the problem. Middle management should be doing what middle managers do in physical production processes: removing barriers, and reviewing processes for continuous improvement. For whatever reason, management science has not caught up to the ubiquity of knowledge work in the modern economy.
    - colechristensen 5y ago
      From my perspective, some of what middle managers do is helpful, much of what they do could just was well not be done. My point being that these tools create work from top to bottom. There's information to fill out, statuses to be updated, progress to be tracked, reports to be generated, etc. etc. etc. which all fall on to a spectrum of "things which have utility" and "things which are busywork" often heavily favoring the latter. They make management jobs "easier" in that they create a clear set of "something to do" which is different than making their jobs easier in the mode of "providing value to leaders, makers, investors, etc." All being done in a cargo cult of "this is how you should work" and satisfying a certain kind of person's desire for things to be "organized".
      - quartesixte 5y ago
        I wonder if HN’s demographics contributes to a general disdain for middle management because, from my non-software engineering point of view, software doesn’t need a lot of management to produce. Hardware on the other hand, needs an organization layer on top of the production layer. Removing barriers, creating traceability, improving processes, and trying to get multiple different teams to work together efficiently.
- systemvoltage 5y ago
  If you've ever worked in manufacturing, real Kanban boards are messy but organized for the people to know what's going on. Every Kanban board I've seen is unique in its own ways. Some use post-it notes and some specialized tokens that magentically attach to the board. Design of the board and layout can vary widely, but generally when you see one, it is a workshop organization tool made by people who feel comfortable using it. Take away is that just because they're not using an off-the-shelf project management / WIP management tool, doesn't mean they're not organized.
  - bluGill 5y ago
    Whiteboards are better in every way but one : a whiteboard doesn't sync with anything central or remote. You have to decide if this matters to you. If yes get a tool, if not get a whiteboard.
    - quartesixte 5y ago
      If no sync means forcing the engineers out of their desks and onto the floor so they actually talk to the production teams and hold in their hands the product that so far has only lived in CAD for them, then I’ll take no-sync any day of the week. Of course, that’s not feasible but hey, a guy can dream.
    - marcind 5y ago
      it's not "syncing" yet but https://sharetheboard.com https://sharetheboard.com does make it easy to save and send whiteboard content with other people and tools (in real time). one-click integrations are a few weeks off. syncing is just one step after that.
- Arcanum-XIII 5y ago
  I've seen manager using the physical board to lock people in a room at their mercy... or to create busy work for them, to justify their existence. That's seriously messed up. The whiteboard was good to move forward a discussion, explain concept and other niceties. To organize work ? Hell no.
- p_l 5y ago
  To be honest, after playing with stuff like Enterprise Architect, and even JIRA - they could be game changer in many places I worked in. But that would require a lot less gatekeepng and other artificial moats around them, and possibly a rather more open organisation model which wouldn't fly with middle management (even if your specific adjacent middle managers would like to, they don't operate in vacuum). And that's before you hit cost reasons. Or cost of training, especially since companies really, really don't like training people.
Lightbody 5y ago
Say what you will about Amazon culture in general (I’ve never worked there)… but one of their leadership principals is Dive Deep > Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them. IMO this particular trait correlates well with a need for less process / project management software. I really believe if more people did this companies would be better off. Note: this isn’t the same thing as micromanaging but I understand why some people think it is.
- Zedronar 5y ago
  I worked for two years at Amazon. My managers were not diving deep at all. At least not more than any other average manager in any other average company.
  - TheDudeMan 5y ago
    Dive deep is more for engineers. Managers can only go so deep because they must be broad. Yes, I know it says "leadership". I was there for 4 years.
    - Lightbody 5y ago
      I appreciate the point you’re trying to make, but I disagree with this. It’s something that has frustrated me, as a manager, when fellow managers said it to me. I feel like it gives permission to managers to detach themselves from the reality of their organization. The trick is to know WHEN to dive deep, because you are right that managers also have to maintain a broad perspective. But being able to sniff out problems and then dive into them has always been the hallmark of a great manager/executive, at least in my own experiences.
  - hinkley 5y ago
    I worked a contract at Amazon. If the managers were doing anything other than lying about timelines, I couldn't see it. Also the dev stack was horrifyingly opaque. Every time an Amazon recruiter contacts me I have to push down the urge to explain how awful it is to work there and no thank you.
ohthehugemanate 5y ago
I see it as a similar problem as we (humans) have with all systems: we mistake the system for the actual solution. It's not. You need to focus on the real problem at hand, and devise/adapt a correct solution in context. Systems and frameworks provide helpful tools and templates, but they all require contextual adaptation. FWIW this is what I like about the foundations of Agile for project management. The manifesto points all direct you away from your tools and processes and towards the actual problem. eg "People over process," "working code over documentation," etc. Basically the people on the team should focus on working software, communicating with the customer, and adapting to change. Their processes, documentation, contracts, and plans should all be aligned to that solution, not the other way around. And out of that... we got millions or scrum certificate weilding alcolytes who will tell you that if your project failed, it's because you didn't do their system religiously enough. God certainly has a sense of irony.
- GekkePrutser 5y ago
  Yeah a lot of companies go like "we're going agile" and just do the tools bit with Jira and its Kanban and rigid time management. It's more like ticking boxes and pretending to know what they're doing than actual agile project management. So now we're stuck with a lot of overhead crap and even more workload. And the system actually slows us down when we try to adapt to a changing environment. Problem is mainly that this happened because the director of project management really liked the reports from Jira and thus the main reason for it all is to get as much data as possible in there (notice how 'accurate data' does not seem to be a focus :) )
  - BoxOfRain 5y ago
    Jira to me is a mostly a tool for managers to coerce developers into a more manager-friendly interpretation of “agile” than anything else rather than something developers would use out of choice. When you’re doing something for the sole purpose of keeping someone off your back about it then you inevitably half-arse it, so in reality we’re paying Atlassian a small fortune for nothing more than a wall of fairly bullshit estimates. Don’t even get me started on how slow and flakey the UI is on the cloud version, it’s such an intolerably poor quality bit of software to actually use as a dev. I’d be very surprised if Atlassian actually dogfooded the cloud version because it really is an abysmal effort.
robocat 5y ago
For anyone wondering what "Archimare" refers to: https://www.visual-paradigm.com/guide/archimate/what-is-archimate/#toc4 https://www.visual-paradigm.com/guide/archimate/what-is-arch...
albertzeyer 5y ago
I don't exactly understand your criticism on best practices. You seem to imply that UML or other project management software are considered best practices. I have never heard that. Or rather the opposite. Not using UML is currently considered as best practice. But maybe it depends who you ask.
- GekkePrutser 5y ago
  Yeah I studied UML during uni. It took a long time to 'click' and when it did I learned some useful concepts from it. Only then did OOP really make sense. However it's way too laborious using it for everything and it becomes a burden when things get complicated. For simple things it just doesn't really help because they're simple anyway. As a learning tool I think it was great. In production? Well I use it every day. The book props up my keyboard on my desk which happens to be 2cm too low :)
  - vidarh 5y ago
    UML done "right" is when you relegate it to simply being a shared vocabulary used when you have a need to communicate details, the same way "everyone" understands a basic flow chart. Having a shared vocabulary is great. Modelling everything out with it, on the other hand, is a nightmare.
- Mary-Jane 5y ago
  It's usually government types (DoD, FDA) pushing for this stuff, and lots of it. The thinking appears to be, "The more the paperwork, the better the product".
clon 5y ago
Thank you for writing this. It exactly aligns with my experience. When such a rant actually feels sensible and pragmatic, there must be something seriously wrong. I don't mean actual engineers wringing bug free code for a space telescope attitude control system. Seemingly they have it figured out - their code does not seem to fall down at a higher rate than bridges or office buildings. They have a method. But this method, whatever they implement, is surely too costly for us regular chumps, at least provided your employer, as you put it, has competitors.
hanniabu 5y ago
My favorite job and most efficient I have ever been was when all we used was a set of trello boards with a list of dev, admin, and auxiliary tasks. Dead simple to manage, everyone can see what's going on, and we would just have a meeting every week or 2 to discuss where we are and coordinate on the next steps to repopulate the boards.
joshxyz 5y ago
Reminds me of antondd's comment on some old thread > This brings back memories from the days of my early career (an ex-PM survivor here). I would be curious to see some data, even anecdotal, on the success of this approach. Here's some interesting statistics from the industry (not specific to software, but you can extrapolate): http://apepm.co.uk/project-management-statistics/ http://apepm.co.uk/project-management-statistics/ > In my view, traditional software project management is ineffective. I would put it somewhere between the Myers-Briggs personality test and modern day astrology. Commendable amount of spaghetti's mentioned though.
nivertech 5y ago
It looks like what you're describing is so called "Agile" (with the uppercase "A") methodology of SDLC[1], not true industry best practices. Agile was invented by consultants who's agenda was to maximize their profits first, not just to improve SDLC. Also, there is no silver bullet, and everything is a trade-off, so each best practice has to be adapted to a particular project. Last thing: sometimes any process, even as bad as "Agile", is better than no process at all. Especially for the dead-on-arrival cases like government-related projects. -- 1. SDLC - https://en.wikipedia.org/wiki/Systems_development_life_cycle https://en.wikipedia.org/wiki/Systems_development_life_cycle
- pas 5y ago
  Agile was invented to try to get contracts (both faster, so as small lead time as possible, which is important for smaller companies, plus smaller upfront price tag, which is again very important for smaller dev shops in order to make deals). Less time spent on specifying the what. Just pay us in time & materials, and we'll figure out, plus the requirements are constantly changing anyway. Hence Agile was seen as a big win-win-win. And I've seen it done well.
RandomLensman 5y ago
You can sell processes as well best practice and manage towards KPIs related to them. Most organizations really don't have enough quality and skill to run in more outcome oriented way, I reckon. Also, most best practices peddled are supported only be flimsy data and anecdotes - only very few areas that are different. I have seen some examples in medicine that had a lot data behind them (not all of medicine by a long shot, though).
hinkley 5y ago
It's the kind that matters as much as the quantity. There's a high correlation for me between bad managers and managers that think they can get you to use a tracking tool that provides zero benefit to yourself and gets used to do their job for them and also occasionally to pick favorites, lay people off, or deny raises/promotions. You're dealing with smart creatives, nobody is volunteering for that shitshow. You got a tool that helps me keep track of my day or be prepared for meetings? Maybe. But if I have to stop what I'm doing to use it, then no fucking way.

by moksly 5y ago

quartesixte 5y ago

Credit due where credit is due: these project management software companies have done a good job of convincing people they need it. I've taken to using tools that most closely mimic notepad+pen or whiteboard+marker. Increasingly I am finding that a physical whiteboard, markers, and post-its are good enough. And if you need to create backups, the image quality on any smartphone is very, very good these days. The more time spent working on the thing that manages your work, the less you are working!

colechristensen 5y ago
What they do is give middle management something to do. Often questionably necessary, middle management has a hard time doing something when engineers understand the product and upper management has the right balance of setting direction and entrusting decisions to the makers. So they start asking the engineers to do things and get upper management on the train of wanting reporting. Doing that with pen-and-paper engineering and people with context is HARD... so all of these tools exist to make this middle layer of doing work better. And arguably unnecessary people earn a lot of money by convincing themselves and others that they are necessary, so companies get to be organized to have these high overhead tools to support this high overhead style of organization. Now to be honest some level of organization is necessary, and becomes necessary as the enterprise and product grows in complexity, but very very few people work long enough or with a diverse enough set of organizations to be able to see what is necessary and when and what is not. If you hire people and put them in a position and tell them they have to work a certain number of hours they will find or create work to do. Oftentimes this work is not better than doing nothing but the WASP work-ethic and general cultural norms really can't handle the idea that smart, important, useful people can provide the most value sometimes by not doing anything until they are needed.
- xcambar 5y ago
  > general cultural norms really can't handle the idea that smart, important, useful people can provide the most value sometimes by not doing anything until they are needed. Thank you for this comment. I have had this is mind for quite some time but I never could phrase it in such a clear, articulate, phrasing.
- jkhdigital 5y ago
  I’d say that they give middle management an out, a way to make their jobs “easy” by just throwing a tool at the problem. Middle management should be doing what middle managers do in physical production processes: removing barriers, and reviewing processes for continuous improvement. For whatever reason, management science has not caught up to the ubiquity of knowledge work in the modern economy.
  - colechristensen 5y ago
    From my perspective, some of what middle managers do is helpful, much of what they do could just was well not be done. My point being that these tools create work from top to bottom. There's information to fill out, statuses to be updated, progress to be tracked, reports to be generated, etc. etc. etc. which all fall on to a spectrum of "things which have utility" and "things which are busywork" often heavily favoring the latter. They make management jobs "easier" in that they create a clear set of "something to do" which is different than making their jobs easier in the mode of "providing value to leaders, makers, investors, etc." All being done in a cargo cult of "this is how you should work" and satisfying a certain kind of person's desire for things to be "organized".
    - quartesixte 5y ago
      I wonder if HN’s demographics contributes to a general disdain for middle management because, from my non-software engineering point of view, software doesn’t need a lot of management to produce. Hardware on the other hand, needs an organization layer on top of the production layer. Removing barriers, creating traceability, improving processes, and trying to get multiple different teams to work together efficiently.
systemvoltage 5y ago
If you've ever worked in manufacturing, real Kanban boards are messy but organized for the people to know what's going on. Every Kanban board I've seen is unique in its own ways. Some use post-it notes and some specialized tokens that magentically attach to the board. Design of the board and layout can vary widely, but generally when you see one, it is a workshop organization tool made by people who feel comfortable using it. Take away is that just because they're not using an off-the-shelf project management / WIP management tool, doesn't mean they're not organized.
- bluGill 5y ago
  Whiteboards are better in every way but one : a whiteboard doesn't sync with anything central or remote. You have to decide if this matters to you. If yes get a tool, if not get a whiteboard.
  - quartesixte 5y ago
    If no sync means forcing the engineers out of their desks and onto the floor so they actually talk to the production teams and hold in their hands the product that so far has only lived in CAD for them, then I’ll take no-sync any day of the week. Of course, that’s not feasible but hey, a guy can dream.
  - marcind 5y ago
    it's not "syncing" yet but https://sharetheboard.com https://sharetheboard.com does make it easy to save and send whiteboard content with other people and tools (in real time). one-click integrations are a few weeks off. syncing is just one step after that.
Arcanum-XIII 5y ago
I've seen manager using the physical board to lock people in a room at their mercy... or to create busy work for them, to justify their existence. That's seriously messed up. The whiteboard was good to move forward a discussion, explain concept and other niceties. To organize work ? Hell no.
p_l 5y ago
To be honest, after playing with stuff like Enterprise Architect, and even JIRA - they could be game changer in many places I worked in. But that would require a lot less gatekeepng and other artificial moats around them, and possibly a rather more open organisation model which wouldn't fly with middle management (even if your specific adjacent middle managers would like to, they don't operate in vacuum). And that's before you hit cost reasons. Or cost of training, especially since companies really, really don't like training people.

Lightbody 5y ago

Say what you will about Amazon culture in general (I’ve never worked there)… but one of their leadership principals is Dive Deep > Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them. IMO this particular trait correlates well with a need for less process / project management software. I really believe if more people did this companies would be better off. Note: this isn’t the same thing as micromanaging but I understand why some people think it is.

Zedronar 5y ago
I worked for two years at Amazon. My managers were not diving deep at all. At least not more than any other average manager in any other average company.
- TheDudeMan 5y ago
  Dive deep is more for engineers. Managers can only go so deep because they must be broad. Yes, I know it says "leadership". I was there for 4 years.
  - Lightbody 5y ago
    I appreciate the point you’re trying to make, but I disagree with this. It’s something that has frustrated me, as a manager, when fellow managers said it to me. I feel like it gives permission to managers to detach themselves from the reality of their organization. The trick is to know WHEN to dive deep, because you are right that managers also have to maintain a broad perspective. But being able to sniff out problems and then dive into them has always been the hallmark of a great manager/executive, at least in my own experiences.
- hinkley 5y ago
  I worked a contract at Amazon. If the managers were doing anything other than lying about timelines, I couldn't see it. Also the dev stack was horrifyingly opaque. Every time an Amazon recruiter contacts me I have to push down the urge to explain how awful it is to work there and no thank you.

ohthehugemanate 5y ago

I see it as a similar problem as we (humans) have with all systems: we mistake the system for the actual solution. It's not. You need to focus on the real problem at hand, and devise/adapt a correct solution in context. Systems and frameworks provide helpful tools and templates, but they all require contextual adaptation. FWIW this is what I like about the foundations of Agile for project management. The manifesto points all direct you away from your tools and processes and towards the actual problem. eg "People over process," "working code over documentation," etc. Basically the people on the team should focus on working software, communicating with the customer, and adapting to change. Their processes, documentation, contracts, and plans should all be aligned to that solution, not the other way around. And out of that... we got millions or scrum certificate weilding alcolytes who will tell you that if your project failed, it's because you didn't do their system religiously enough. God certainly has a sense of irony.

GekkePrutser 5y ago
Yeah a lot of companies go like "we're going agile" and just do the tools bit with Jira and its Kanban and rigid time management. It's more like ticking boxes and pretending to know what they're doing than actual agile project management. So now we're stuck with a lot of overhead crap and even more workload. And the system actually slows us down when we try to adapt to a changing environment. Problem is mainly that this happened because the director of project management really liked the reports from Jira and thus the main reason for it all is to get as much data as possible in there (notice how 'accurate data' does not seem to be a focus :) )
- BoxOfRain 5y ago
  Jira to me is a mostly a tool for managers to coerce developers into a more manager-friendly interpretation of “agile” than anything else rather than something developers would use out of choice. When you’re doing something for the sole purpose of keeping someone off your back about it then you inevitably half-arse it, so in reality we’re paying Atlassian a small fortune for nothing more than a wall of fairly bullshit estimates. Don’t even get me started on how slow and flakey the UI is on the cloud version, it’s such an intolerably poor quality bit of software to actually use as a dev. I’d be very surprised if Atlassian actually dogfooded the cloud version because it really is an abysmal effort.

robocat 5y ago

For anyone wondering what "Archimare" refers to: https://www.visual-paradigm.com/guide/archimate/what-is-archimate/#toc4 https://www.visual-paradigm.com/guide/archimate/what-is-arch...

albertzeyer 5y ago

I don't exactly understand your criticism on best practices. You seem to imply that UML or other project management software are considered best practices. I have never heard that. Or rather the opposite. Not using UML is currently considered as best practice. But maybe it depends who you ask.

GekkePrutser 5y ago
Yeah I studied UML during uni. It took a long time to 'click' and when it did I learned some useful concepts from it. Only then did OOP really make sense. However it's way too laborious using it for everything and it becomes a burden when things get complicated. For simple things it just doesn't really help because they're simple anyway. As a learning tool I think it was great. In production? Well I use it every day. The book props up my keyboard on my desk which happens to be 2cm too low :)
- vidarh 5y ago
  UML done "right" is when you relegate it to simply being a shared vocabulary used when you have a need to communicate details, the same way "everyone" understands a basic flow chart. Having a shared vocabulary is great. Modelling everything out with it, on the other hand, is a nightmare.
Mary-Jane 5y ago
It's usually government types (DoD, FDA) pushing for this stuff, and lots of it. The thinking appears to be, "The more the paperwork, the better the product".

clon 5y ago

Thank you for writing this. It exactly aligns with my experience. When such a rant actually feels sensible and pragmatic, there must be something seriously wrong. I don't mean actual engineers wringing bug free code for a space telescope attitude control system. Seemingly they have it figured out - their code does not seem to fall down at a higher rate than bridges or office buildings. They have a method. But this method, whatever they implement, is surely too costly for us regular chumps, at least provided your employer, as you put it, has competitors.

hanniabu 5y ago

My favorite job and most efficient I have ever been was when all we used was a set of trello boards with a list of dev, admin, and auxiliary tasks. Dead simple to manage, everyone can see what's going on, and we would just have a meeting every week or 2 to discuss where we are and coordinate on the next steps to repopulate the boards.

joshxyz 5y ago

Reminds me of antondd's comment on some old thread > This brings back memories from the days of my early career (an ex-PM survivor here). I would be curious to see some data, even anecdotal, on the success of this approach. Here's some interesting statistics from the industry (not specific to software, but you can extrapolate): http://apepm.co.uk/project-management-statistics/ http://apepm.co.uk/project-management-statistics/ > In my view, traditional software project management is ineffective. I would put it somewhere between the Myers-Briggs personality test and modern day astrology. Commendable amount of spaghetti's mentioned though.

nivertech 5y ago

It looks like what you're describing is so called "Agile" (with the uppercase "A") methodology of SDLC[1], not true industry best practices. Agile was invented by consultants who's agenda was to maximize their profits first, not just to improve SDLC. Also, there is no silver bullet, and everything is a trade-off, so each best practice has to be adapted to a particular project. Last thing: sometimes any process, even as bad as "Agile", is better than no process at all. Especially for the dead-on-arrival cases like government-related projects. -- 1. SDLC - https://en.wikipedia.org/wiki/Systems_development_life_cycle https://en.wikipedia.org/wiki/Systems_development_life_cycle

pas 5y ago
Agile was invented to try to get contracts (both faster, so as small lead time as possible, which is important for smaller companies, plus smaller upfront price tag, which is again very important for smaller dev shops in order to make deals). Less time spent on specifying the what. Just pay us in time & materials, and we'll figure out, plus the requirements are constantly changing anyway. Hence Agile was seen as a big win-win-win. And I've seen it done well.

RandomLensman 5y ago

You can sell processes as well best practice and manage towards KPIs related to them. Most organizations really don't have enough quality and skill to run in more outcome oriented way, I reckon. Also, most best practices peddled are supported only be flimsy data and anecdotes - only very few areas that are different. I have seen some examples in medicine that had a lot data behind them (not all of medicine by a long shot, though).

hinkley 5y ago

It's the kind that matters as much as the quantity. There's a high correlation for me between bad managers and managers that think they can get you to use a tracking tool that provides zero benefit to yourself and gets used to do their job for them and also occasionally to pick favorites, lay people off, or deny raises/promotions. You're dealing with smart creatives, nobody is volunteering for that shitshow. You got a tool that helps me keep track of my day or be prepared for meetings? Maybe. But if I have to stop what I'm doing to use it, then no fucking way.