20 ms·

> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but

> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most waste I've ever seen has always come down to poor communication rather than anything actually business or technical related.

flippinburgers 4y ago
I think there is a balance but yeah it isn't good if no record of "where we are" exists.
- steveBK123 4y ago
  Yes but I think people overestimate how automatable this actually is. Where we are context depends on if the audience is - * The next developer to pick up the task where you left off * Your technical lead asking for update * Your manager needing an update for his manager * Product management wanting to know where we are on some feature * End users wanting to know when the bug fix / feature they asked for will be in their hands Everywhere I have worked, we had multiple apps/ticketing systems/etc all trying to roll up / slice & dice data to get to the above. In the end it just turns into talking to management pinging the next level below them for adhoc status. Why? Because product is too ignorant to open Jira nor maintain status themselves. Because management above the line manager level is apparently incapable of opening Jira either, let alone 2-3 levels up. Also no one wants to hire real project managers anymore to maintain all the different views & send the weekly updates they demand to receive.
  - steveBK123 4y ago
    And remember, all of the above is a symptom of being in an organization where someone more important than you says "I don't have time to look at <insert reporting system>, tell me what the status of <deliverable> is". Fixing this from the bottom up is better accomplished via updating ones resume & LinkedIn profile.
  - dmix 4y ago
    Are your tickets even designed/written for consumption by product/management?
    - steveBK123 4y ago
      Well they were more rigidly formatted for product consumption with Acceptance Criteria, Milestone->Epic->Story hierarchy creation to roll up to larger efforts, tags, Ready For Sprint criteria, standard story point sizing, But very little detail on how one was technically to do the task, or time spent discussing technical options & tradeoffs.
michaelt 4y ago
> Ticket management is not busy work, it's a necessity for everyone to keep updated. I would say that rather depends on how much of it you do.
- flumpcakes 4y ago
  Oh, I see... I just assumed people read tickets and did the work and updated the ticket? For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to remember or write down details and statuses of things somewhere else. Are people really wasting time on 'ticket management' that isn't as I've described? Edit: I've spent some time thinking about this, and despite being the org owner for our companies Azure DevOps instance I'm actually firmly in the 'Ops' camp of Ops<->DevOps<->Dev. My job is mainly Ops and I do some DevOps/SRE work on the side as the pragmatic-infrastructure-guy. I often see lots of nonsense done in the Developer camp. I think why I don't see the downsides of tickets is because I come from the background where tickets are more Help Centre-like. It's just pieces of work that needs doing or people need help with. If the help centre started arguing about if something is 'high' or 'critical' or spent 50% of their time just 'managing tickets' then they would flat-out just get fired. I guess that's the cultural difference between HC/Ops and 'Dev' that I wasn't really seeing before.
  - swiftcoder 4y ago
    There are definitely corporate cultures where updating ticket status at regular intervals is higher priority than actually working the problem in the ticket.
    - rlpb 4y ago
      Of course it is. That means that you work on the problem, but when a regular interval arrives, you stop working on the problem to update the ticket instead. Once updated, you go back to working on the problem. That's how status updates are supposed to work. Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved.
strken 4y ago
I suspect that the presentations and diagrams which need to be made, are made. Good communication is important, but the artefacts come about from the organic need to communicate an idea rather than orders from on high. Consider "The Bar team wants to know about our new Foo architecture" vs "The Bar team needs a 30 minute presentation on our new Foo architecture". Does the Bar team actually need a presentation, and could it be a live demo? Do they just need better documentation? Are they building an integration, and would someone from your team working with them for a week unblock them in a way a presentation wouldn't? Could this be a ten minute call between you and the one engineer who needs a hand? Good and experienced engineers do their best work on open-ended tasks. This is as true of communication as it is solo work. Artificially dictating the solution without understanding the problem limits them.
- robertlagrant 4y ago
  > I suspect that the presentations and diagrams which need to be made, are made. I don't think that's true. E.g. diagrams are made, once, because of an audit, instead of made iteratively as the software changes. Or someone says, "If they want to know, they can just talk to me. You know, have a conversation?"
  - mgkimsal 4y ago
    The whole "yeah, just have a conversation" thing bugs me a lot. I like talking, and having conversations. It's rarely enough. The information needs to be written down (or codified in tests or whatever). Future people won't have the luxury of a conversation with whoever originally wrote something. Conversations aren't indexable. Conversations lose nuance, memories fade or get jumbled. Have your conversation, then document/diagram it afterwards.
    - cratermoon 4y ago
      Plus, conversations are synchronous. If it's just one person explaining to another, it's no so bad. But what if that person needs to explain it to five or ten people? Do you have multiple 1:1 conversations or try to schedule a meeting at a time everyone is available?
apozem 4y ago
Yeah, in my experience writing complete tickets forces people to actually think through designs and trade-offs. It also has the nice benefit of exposing their thinking to others in the organization, who can weigh in and go, "Oh, if you're doing that, we have to do this on our project."
- steveBK123 4y ago
  It really depends on if tickets are being written as an input to the work product, or as an agile mandated box ticking exercise. Do you spend more time wrangling over the ticket content or the format? Do you spend more time discussing context & requirements, or story points? Etc
safety1st 4y ago
Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers. Off the top of my head these are the most common two "negative engineer" behaviors I have seen 1) Biggest one: an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place. This is the key to never shipping and destroying entire companies. 2) Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well). This is the key to your product dying a slow death over several years. There are negative engineers doing this stuff ALL. THE. TIME. EVERYWHERE. Despite unquantifiable volumes of both ink and blood spilled trying to prevent them.
- svachalek 4y ago
  These are so common. The problem engineer will tend to be seen as a genius with inadequate help, the only one who can save us (from the pit he dug for us).
  - passwordoops 4y ago
    And it's funny how wherever things finally come to a head and you part ways to much hand-wringing and doom and gloom scenarios... Lo and behold, turns out the new guy can make it work just fine. In fact he's refactoring out the unnecessary complexity as we speak
  - mgkimsal 4y ago
    Holy tamole. Had worked someplace for a short stint. There was a guy who'd started a couple months before I did. His work was 'revolutionary' and 'groundbreaking' - he'd been trying to build some sort of AOP-style PHP system - PHP4, mind you - without any extensions or internals work. It was just 'program this way' - undocumented patterns that encouraged copy/paste to half-way almost get you something usable (except, not really). "Build a form to take a few fields input and store in a database" example took days to develop, because... he was just winging it. Session management? nope - we'll need to roll our own, and that'll take a few weeks. About half the team (20ish folks) were enraptured by this guy. Someone rambled about great this guy was, said something along the lines of "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it? that's where we're at, and it's just so awesome - I can't wait to learn more!" This guy saying that was, at the time, like... the #2 guy on the team, had been there for years, and was the defacto 'team lead' for that work, and he was taken in by a huckster. The aop guy was there for about 10 months, then left abruptly - left on a friday, sent an email on monday with "i resign, i got another job". somehow, some folks were "shocked" at his "unprofessionalism". The entire tenure had been unprofessional, but few cared to label it that. You're so good and smart that you built something we all need to use, but you can't explain it (let alone why it's good/better), everyone else plainly admits they don't understand much about it, and use the lack of understanding as evidence that they're so bad this must be genius-level work. Insane...
d23 4y ago
I'm going to go out on a limb and suggest that the author probably thinks a healthy balance exists between zero communication and spending 100% of one's time playing JIRA games and visibility hacking.
- ssgodderidge 4y ago
  Agreed. I think the nuance got lost here. "Typical examples" is the key phrase here. Not all presentations are created equal. Text you throw on a slide in 10 min to guide a 1 hour conversation, versus trying to make everything pixel perfect for 40 hours prepping the deck for the public. Ticket management is critical, but do you really need to spend 4 hours doing it each day?
- onos 4y ago
  It’s a jira version of “talks a lot, has little to say.”
jrussino 4y ago
I recently heard a quote that resonated with me: "If you want to go fast, go alone. If you want to go far, go together". I wonder if someone who treats these tasks as "non-work" is thinking of themselves as being more productive because they go faster than the folks around them, not considering that these other tasks that slow them down individually also help the team go farther in the long run...
- watwut 4y ago
  Unless of course, they are not helping the team at all. Unless they are busywork we go through without ever looking at again or using it practically. Unless they are made to avoid making decision and then to avoid it again. The company I work for have quite a lot of all hands presentations with content relevant to like ... 5 people. While everyone else nods, sleeps, reads reddit, zooms out daydreaming. We have diagrams that have nothing to do with anything, but make manager feel like she is controlling something. We do not spend much time on ticked management tho. Which an argument against that idea too - you can in fact have functional ticket management without everyone spending too much time on it. But, I did seen overly complicated systems in the past that required constant fiddling.
  - danaris 4y ago
    It's always a balance. There is no universally-correct amount (or types) of meta-work to make a team function optimally. For some teams, especially very small ones (and most especially if they're all volunteers), adding significant amounts of bookkeeping to their tasks is likely to be much more trouble than it's worth. (Though, again, even for some solo developers, the bookkeeping can be very valuable—it's all about the specifics of the projects and the ways different people operate.) For other teams, not having the extra bookkeeping will mean that the people struggle to keep their tasks straight, or get abused by their managers, or have a variety of other problems. The most important thing is to be reflecting on your and your team's work and processes, and being open to changes that might improve them.
  - jamesfinlayson 4y ago
    > We have diagrams that have nothing to do with anything, but make manager feel like she is controlling something. Guh, I remember at a previous job, one of my managers would always dedicate a multiple minutes to pie charts of types of tests done at the end of each sprint - the business stakeholders and the developers at the retrospectives couldn't have cared less that 30% of testing effort was spent on smoke testing compared to 28% last sprint.
cratermoon 4y ago
Yes but I've also been buried in presentations, diagrams, and ticket management that don't contribute to communication. That's doubly wasteful because not only is time wasted making all these artifacts, but even when produced they still don't improve understanding. Might as well have a chatbot write them, they couldn't be worse. Ticket management fails to keep anyone updated when it's just a performative way to make managers and execs believe they are seeing progress when in fact the ticket board is a fiction unrelated to real effort.
denton-scratch 4y ago
> Common examples include presentations, diagrams, and ticket management. Ticket management is stuff that needs doing, obviously. Diagrams are illustrations; if something is so complicated it can only be understood with a picture, it's too complicated. But a quick diagram on a whiteboard (or with a pencil on the back of a fag packet) might be helpful. Presentations (with slide-decks) are for managers[0], not engineers. They are a huge drain on time. I got severely dinged by my manager for doing a presentation without a slide-deck; I hadn't prepared one, because I had real work to do. But I think I showed my manager up, because all the other engineers had turned up with slide decks. A crap slide deck is quick to make, and completely useless. A really good slide deck can take days to make; it's a specialist trade, like making good user documentation. Slides must augment the presentation, not distract from it. [0] I've been forced into formal management once or twice; my experience was that at least half of management is bragging to other managers about how important your team is, and slide decks are great for that.
- danaris 4y ago
  > if something is so complicated it can only be understood with a picture, it's too complicated Absolutes like this contribute significantly, depending on the perspective they're spoken from, to the anti-intellectualism in our society today, or to a culture of elitism. For the first, some things are complex, and that complexity is part of the real-life systems and structures they have to interface with or represent. Explaining complex things with a diagram can be an extremely effective method for making what might otherwise require a very high cognitive load much easier to process. And for the second, if someone needs a diagram to understand something complex, it's not because they're stupid, and insisting that everything worth explaining can—and must—be explained in text only does them a disservice.
  - knsv 4y ago
    I find that I write most diagrams for myself as a reader. It takes much less time to get an overview some logic I have not touched in a while when there is a diagram to start with. Once I remember the big picture I dig deeper via the code.
  - 4y ago
polalavik 4y ago
I don’t know. Tickets can still be busy work depending on when you demand them to be done. Sometimes a ticket might best be handled at a different stage in the project to give it the time and context it deserves. If you are just closing out tickets, sometimes out of context and as fast as possible, you are doing busy work. This could just be bad ticket management with where I work. Or we use tickets in a less standard way. I’m not sure, I work in fpga design so it’s not like a user submitted bug, it’s a request from one of the 1000 review meetings.
NikolaNovak 4y ago
FWIW :) I used to despise the incredible amount of time we could spend on a single powerpoint slide sometimes. Then one day when going over same slide for the 5th time with my boss and mentor, I realized: * This slide will be seen by a person in power * they will make a decision based upon that slide * I would like to spend 3 hours explaining them the intricacies of my project/architecture/problem/whatever * But they have 10/100/1000 other projects, and they have 20/10/5/1 minute to devote to me before they make a decision * A slide or set of slides might therefore have an impact across 1/10/100 people over week/month/years due to a decision based on a slide or set of slides * therefore, it can at times be rationally logical to spend a lot of time word-smithing a slide in order to help the right decision As programmers, we understand that we might spend 10min/hour/days/weeks on a small but crucial piece of code, because we need the computer to understand it and do the exactly right thing in a complicated scenario; and we do not consider it a waste of time (though our management might! It's a curiously symmetrical situation :-) Sometimes, slides are exactly that, but for people - distilled information to enable executive stakeholder to do the correct thing. Same with other items - diagrams? They can be phenomenally useful! A good diagram can spread understanding of goal and ensure we all build the right thing. Bad diagram can set 100 smart people on divergent paths!
jupp0r 4y ago
You have never seen JIRA properly configured then.
strangattractor 4y ago
The only 10X engineers I have ever worked with were the ones that helped get 2X out of the five normally 1X engineers they worked with.
chang1 4y ago
I've discovered that this can be a deflection tactic for some. Usually it happens in a situation where I try my best to explain a part of an app or system. The other person is overwhelmed or confused but doesn't just say that, and instead kicks the can down the road by saying there is a lack of documentation to reference or are in need of diagrams. When I then take the time to add info to a wiki or spend time diagramming concepts with those developers, it seems to not help aid understanding at all. Then I realize I just wasted a lot of time.
nico 4y ago
Everyone is different. The key is not forcing people into your own worldview. Some people do better with documentation or tickets or code or meetings. The point is that forcing people to do shit they don’t want to do will backfire and make teams unhappy and unproductive.
- jltsiren 4y ago
  Everyone is different, but it doesn't matter that much. When you have a small team, you can often organize the work the way people prefer. Then you'll find that people who can be incredibly productive under ideal circumstances are actually quite common. But as the organization grows, you have to focus more on the process and the structure. Individual productivity doesn't matter if you can't channel that productivity to advance the organization's goals. You rely increasingly on people who can work productively within the system. People who thrive in a wide range of environments, even when they would prefer having things organized in a different way.
  - nico 4y ago
    Why does the organization need to grow?
ResearchCode 4y ago
It's busy work if you do it more than 1 hour any given week. If you do it full-time, you're something like a -10x engineer.
treeman79 4y ago
Had many times where I saved a company months of work by forcing a meeting to lock in UX requirements. Basically go through screen to screen on a whiteboard what should happen. This almost always leads to major changes to the whiteboard during the meeting. Had many times were I couldn’t get company to do this exercise. First time leadership sees UX is on completed project. Team then spends months rewriting application. Everyone generally pissed.
wpietri 4y ago
> Ticket management is not busy work, it's a necessity for everyone to keep updated. Yes and no. If I oversimplify one of the important Lean points, you can divide activity into 3 buckets: 1) value-creating, 2) necessary waste, 3) pure waste. It's important here that "value" is always measured from the customer perspective. For example, imagine a hamburger joint. You have ordered a cheeseburger. The person at the grill cooks a patty for you, puts some cheese on it, and assembles a burger. Then somebody else walks that burger to you. Except they get distracted after they've picked it up, so they end up walking to the back before coming up to give it to you. Making the burger is value creating. You wouldn't want a raw patty, and you want it put together right. Walking the burger to you is necessary waste, in that moving the burger does not increase its value, but we have to do it to deliver value. The little stroll to the back is unnecessary waste in that you could receive the same value without it. Make sense? With that framework, let's think about software. Ticket management is not a value-creating activity. If I do an extra hour of ticket management, that does not guarantee increased value. At best, it's necessary waste: I just can't figure out how to get you what you want without N hours of ticket management. But quite often it's unnecessary waste, labor performed for some purpose other than customer value. For example, a lot of planning activity is about making high-status people feel important. Or part of somebody's ongoing battle for increased status. Or the downstream consequence of previous unaddressed failures causing distrust. So can ticket management be necessary waste? Sure. But it's often pure waste. I've done whole companies with no more ticket management than you get out of a bunch of index cards on the wall. [1] And we got there by relentlessly cutting the waste of heavier processes, something that a lot of companies won't even think about, much less attempt, because there productivity is relatively unimportant. [1] e.g.: https://williampietri.com/writing/2015/the-big-board/ https://williampietri.com/writing/2015/the-big-board/
- bstpierre 4y ago
  If the ticket is a direct conduit to the customer, I think you could argue that ticket management in the form of asking clarifying questions so that you build the right thing (or fix the right bug) is creating value?
  - wpietri 4y ago
anonytrary 4y ago
Engineer who implements correct, comprehensible code but doesn't manage ticket statuses is more valuable than one who manages ticket statuses but scatters the codebase with technical debt and confusing abstractions/code. If "better communication" means spending an extra 10 hours with the latter dev to correct/re-teach them, then yes, communication is the problem. The most time I've lost at work is correcting/teaching engineers who eventually got let go due to low performance.
- doesnt_know 4y ago
  I don't really think the first part of your comment is true, at least not in my experience. All other stakeholders would prefer someone that updates their tickets and communicates what they are doing effectively, even if they produce absolute garbage, bug ridden software. I've personally only ever seen someone removed from a team for having poor technical skills once and it was under pretty extreme circumstances. While I've seen many good (from a technical perspective) developers removed because they thought they were somehow above doing the everyday "busy work" like ticket management. Unless you work alone, then refusing to do non-technical work is just saying you're going to let the rest of the team do it. You're much more likely to be removed or have your contract ended if the team doesn't want to work with you.
  - asdff 4y ago
    Without going into anything identifying, what exactly were those circumstances? I'm imagining something like this happening, but at the same time I can't help but think if its a technical skill issue, handing them a book on the relevant technology and telling them studying this book is their job for the next two weeks would be better than trying to roll the dice again, put out a new job ad, interview, vet, rehire, and hope they aren't somehow just as technically incompetent as the original engineer.
alfalfasprout 4y ago
1000%. A lot of this stuff seems like busy work to junior engineers and bad senior/staff engineers. But this is how you spend a few days to save months of wasted effort.
com 4y ago
I’m a big fan of putting more time and effort into communication. I just think that there’s an incredible set of decreasing returns after about 30 minutes into building any diagram or presentation, for most people and most use cases. That’s why quick whiteboard or lucidchart or Miro sketches are so powerful - and are designed to communicate in the moment! - and most PowerPoints, swimlane diagrams etc which have tens or hundreds of hours of work are like polished turds. Very few diagrams or presentations show history and almost none are ever updated to show the status of things today. Which means that they just cause confusion. Generally, someone starts again and creates something with new blind spots and which takes about as much time again to create, and is out of date before others see it. Drawing and presenting is mostly interesting if the people who are present for the drawing or description process can go forth and explain, draw or present it in their own words or images, and therefore communication has been achieved; this seems to be very uncommon in most drawing and presentation-heavy environments I’ve been in though.
40yearoldman 4y ago
But at what point does that communication cost more than just hiring somebody else who needs less hand holding and less "communication" to understand what is going on and figure out what to next. I say this because there always seems to be those who don't need this. And it's the ones who need this who never seem to produce as much or are able to solve the problems on their own. So I ask. If you could hire people who need this "communication" or hire people who don't need the "communication" and they both can get the job done, why would you hire those that require time consuming processes. Good teams don't need Jira, good teams don't need power points, good teams don't need all the hand holding. These are tools to include those who can't and often bring minimal usefulness to the table. Poor communication is code for "I have no clue what I am doing and am going to blame others for why I am not useful, but I don't want to admit to others I have no clue what I am doing.". Next time you find your self thinking somebody is poorly communicating, try this in stead. Say "Hey, I don't know what I am doing, I am lost, where can I start? More often than not this "poor communicator" is going to be able to direct you to a task that will not only make you useful, but also not require much more than 5 minutes of exchange and as a result you will probably learn something that will make you more useful in the long run. > in my experience it has been the sub-par employees who are the ones that don't do this. To directly call this out, the sub-par are often the ones doing all this stuff, because they simply can't do the actual work. Sub-par is probably not fair, as a good manager will build a team with a few of these folks to tend the toil. So they are useful in a way. Also you all can think back on the time that you hired somebody and they knew more than just about everybody about how the product works and should work within just a few weeks. This person clearly did not need the documentation, they simply read the code -- the code is the documentation -- and the quicker folks stop thinking like tis anything else other than a big manual the faster they will be able to learn new code bases and become useful. The constant translation between weird human social ideas of what is good communication and a solid structured communication such as code its an incredible waste of time. Just remember, your job is to write code to tell a computer what to do, and if you can't also read that code to figure out what the program should do, you might be computer illiterate which makes you less valuable than somebody who can both write and read code in the same manner as the systems that will consume it. If you have ever had somebody tell you "it's like you compile the code in your head" you will know what I am talking about.
mathattack 4y ago
Yes. Disorganization is the largest cause I’ve seen of preventable waste.
asdff 4y ago
These examples imo are often sources of added fluff to process. The goal of the presentation is to get the point across. Unfortunately, I see too many people make these terrible powerpoints, where its clear they spent too much time making the template sexy and not enough time considering what content the content is. My favorite powerpoints are the ones where people use the default white background and text, and just put up a single figure per slide and describe them versus talking off bullet points with a bunch of junk imagery. If I am reading a sentence on your slide, I am incapable of listening what is coming out of your mouth at the same time. Basically, the slide deck should only take you as much time to make as pasting your figures over to it.
novembermike 4y ago
Yeah, these things are all part of being a team of 1x engineers rather than a team of .5x engineers. If you have a single 10x (and I've worked with some) then it's not important but those guys have their own issues.
mesozoic 4y ago
The important part is that you do it for something that's not all that important then make sure to get the project dumped before any real progress is made.
not_enoch_wise 4y ago
These idiot, overpaid engineers don’t understand how important tickets & tracking metrics are. As if turning a measurement into a target could make it cease to become a good measurement!
deleted 4y ago
[deleted]

flippinburgers 4y ago

I think there is a balance but yeah it isn't good if no record of "where we are" exists.

steveBK123 4y ago
Yes but I think people overestimate how automatable this actually is. Where we are context depends on if the audience is - * The next developer to pick up the task where you left off * Your technical lead asking for update * Your manager needing an update for his manager * Product management wanting to know where we are on some feature * End users wanting to know when the bug fix / feature they asked for will be in their hands Everywhere I have worked, we had multiple apps/ticketing systems/etc all trying to roll up / slice & dice data to get to the above. In the end it just turns into talking to management pinging the next level below them for adhoc status. Why? Because product is too ignorant to open Jira nor maintain status themselves. Because management above the line manager level is apparently incapable of opening Jira either, let alone 2-3 levels up. Also no one wants to hire real project managers anymore to maintain all the different views & send the weekly updates they demand to receive.
- steveBK123 4y ago
  And remember, all of the above is a symptom of being in an organization where someone more important than you says "I don't have time to look at <insert reporting system>, tell me what the status of <deliverable> is". Fixing this from the bottom up is better accomplished via updating ones resume & LinkedIn profile.
- dmix 4y ago
  Are your tickets even designed/written for consumption by product/management?
  - steveBK123 4y ago
    Well they were more rigidly formatted for product consumption with Acceptance Criteria, Milestone->Epic->Story hierarchy creation to roll up to larger efforts, tags, Ready For Sprint criteria, standard story point sizing, But very little detail on how one was technically to do the task, or time spent discussing technical options & tradeoffs.

michaelt 4y ago

> Ticket management is not busy work, it's a necessity for everyone to keep updated. I would say that rather depends on how much of it you do.

flumpcakes 4y ago
Oh, I see... I just assumed people read tickets and did the work and updated the ticket? For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to remember or write down details and statuses of things somewhere else. Are people really wasting time on 'ticket management' that isn't as I've described? Edit: I've spent some time thinking about this, and despite being the org owner for our companies Azure DevOps instance I'm actually firmly in the 'Ops' camp of Ops<->DevOps<->Dev. My job is mainly Ops and I do some DevOps/SRE work on the side as the pragmatic-infrastructure-guy. I often see lots of nonsense done in the Developer camp. I think why I don't see the downsides of tickets is because I come from the background where tickets are more Help Centre-like. It's just pieces of work that needs doing or people need help with. If the help centre started arguing about if something is 'high' or 'critical' or spent 50% of their time just 'managing tickets' then they would flat-out just get fired. I guess that's the cultural difference between HC/Ops and 'Dev' that I wasn't really seeing before.
- swiftcoder 4y ago
  There are definitely corporate cultures where updating ticket status at regular intervals is higher priority than actually working the problem in the ticket.
  - rlpb 4y ago
    Of course it is. That means that you work on the problem, but when a regular interval arrives, you stop working on the problem to update the ticket instead. Once updated, you go back to working on the problem. That's how status updates are supposed to work. Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved.

strken 4y ago

I suspect that the presentations and diagrams which need to be made, are made. Good communication is important, but the artefacts come about from the organic need to communicate an idea rather than orders from on high. Consider "The Bar team wants to know about our new Foo architecture" vs "The Bar team needs a 30 minute presentation on our new Foo architecture". Does the Bar team actually need a presentation, and could it be a live demo? Do they just need better documentation? Are they building an integration, and would someone from your team working with them for a week unblock them in a way a presentation wouldn't? Could this be a ten minute call between you and the one engineer who needs a hand? Good and experienced engineers do their best work on open-ended tasks. This is as true of communication as it is solo work. Artificially dictating the solution without understanding the problem limits them.

robertlagrant 4y ago
> I suspect that the presentations and diagrams which need to be made, are made. I don't think that's true. E.g. diagrams are made, once, because of an audit, instead of made iteratively as the software changes. Or someone says, "If they want to know, they can just talk to me. You know, have a conversation?"
- mgkimsal 4y ago
  The whole "yeah, just have a conversation" thing bugs me a lot. I like talking, and having conversations. It's rarely enough. The information needs to be written down (or codified in tests or whatever). Future people won't have the luxury of a conversation with whoever originally wrote something. Conversations aren't indexable. Conversations lose nuance, memories fade or get jumbled. Have your conversation, then document/diagram it afterwards.
  - cratermoon 4y ago
    Plus, conversations are synchronous. If it's just one person explaining to another, it's no so bad. But what if that person needs to explain it to five or ten people? Do you have multiple 1:1 conversations or try to schedule a meeting at a time everyone is available?

apozem 4y ago

Yeah, in my experience writing complete tickets forces people to actually think through designs and trade-offs. It also has the nice benefit of exposing their thinking to others in the organization, who can weigh in and go, "Oh, if you're doing that, we have to do this on our project."

steveBK123 4y ago
It really depends on if tickets are being written as an input to the work product, or as an agile mandated box ticking exercise. Do you spend more time wrangling over the ticket content or the format? Do you spend more time discussing context & requirements, or story points? Etc

safety1st 4y ago

Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers. Off the top of my head these are the most common two "negative engineer" behaviors I have seen 1) Biggest one: an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place. This is the key to never shipping and destroying entire companies. 2) Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well). This is the key to your product dying a slow death over several years. There are negative engineers doing this stuff ALL. THE. TIME. EVERYWHERE. Despite unquantifiable volumes of both ink and blood spilled trying to prevent them.

svachalek 4y ago
These are so common. The problem engineer will tend to be seen as a genius with inadequate help, the only one who can save us (from the pit he dug for us).
- passwordoops 4y ago
  And it's funny how wherever things finally come to a head and you part ways to much hand-wringing and doom and gloom scenarios... Lo and behold, turns out the new guy can make it work just fine. In fact he's refactoring out the unnecessary complexity as we speak
- mgkimsal 4y ago
  Holy tamole. Had worked someplace for a short stint. There was a guy who'd started a couple months before I did. His work was 'revolutionary' and 'groundbreaking' - he'd been trying to build some sort of AOP-style PHP system - PHP4, mind you - without any extensions or internals work. It was just 'program this way' - undocumented patterns that encouraged copy/paste to half-way almost get you something usable (except, not really). "Build a form to take a few fields input and store in a database" example took days to develop, because... he was just winging it. Session management? nope - we'll need to roll our own, and that'll take a few weeks. About half the team (20ish folks) were enraptured by this guy. Someone rambled about great this guy was, said something along the lines of "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it? that's where we're at, and it's just so awesome - I can't wait to learn more!" This guy saying that was, at the time, like... the #2 guy on the team, had been there for years, and was the defacto 'team lead' for that work, and he was taken in by a huckster. The aop guy was there for about 10 months, then left abruptly - left on a friday, sent an email on monday with "i resign, i got another job". somehow, some folks were "shocked" at his "unprofessionalism". The entire tenure had been unprofessional, but few cared to label it that. You're so good and smart that you built something we all need to use, but you can't explain it (let alone why it's good/better), everyone else plainly admits they don't understand much about it, and use the lack of understanding as evidence that they're so bad this must be genius-level work. Insane...

d23 4y ago

I'm going to go out on a limb and suggest that the author probably thinks a healthy balance exists between zero communication and spending 100% of one's time playing JIRA games and visibility hacking.

ssgodderidge 4y ago
Agreed. I think the nuance got lost here. "Typical examples" is the key phrase here. Not all presentations are created equal. Text you throw on a slide in 10 min to guide a 1 hour conversation, versus trying to make everything pixel perfect for 40 hours prepping the deck for the public. Ticket management is critical, but do you really need to spend 4 hours doing it each day?
onos 4y ago
It’s a jira version of “talks a lot, has little to say.”

jrussino 4y ago

I recently heard a quote that resonated with me: "If you want to go fast, go alone. If you want to go far, go together". I wonder if someone who treats these tasks as "non-work" is thinking of themselves as being more productive because they go faster than the folks around them, not considering that these other tasks that slow them down individually also help the team go farther in the long run...

watwut 4y ago
Unless of course, they are not helping the team at all. Unless they are busywork we go through without ever looking at again or using it practically. Unless they are made to avoid making decision and then to avoid it again. The company I work for have quite a lot of all hands presentations with content relevant to like ... 5 people. While everyone else nods, sleeps, reads reddit, zooms out daydreaming. We have diagrams that have nothing to do with anything, but make manager feel like she is controlling something. We do not spend much time on ticked management tho. Which an argument against that idea too - you can in fact have functional ticket management without everyone spending too much time on it. But, I did seen overly complicated systems in the past that required constant fiddling.
- danaris 4y ago
  It's always a balance. There is no universally-correct amount (or types) of meta-work to make a team function optimally. For some teams, especially very small ones (and most especially if they're all volunteers), adding significant amounts of bookkeeping to their tasks is likely to be much more trouble than it's worth. (Though, again, even for some solo developers, the bookkeeping can be very valuable—it's all about the specifics of the projects and the ways different people operate.) For other teams, not having the extra bookkeeping will mean that the people struggle to keep their tasks straight, or get abused by their managers, or have a variety of other problems. The most important thing is to be reflecting on your and your team's work and processes, and being open to changes that might improve them.
- jamesfinlayson 4y ago
  > We have diagrams that have nothing to do with anything, but make manager feel like she is controlling something. Guh, I remember at a previous job, one of my managers would always dedicate a multiple minutes to pie charts of types of tests done at the end of each sprint - the business stakeholders and the developers at the retrospectives couldn't have cared less that 30% of testing effort was spent on smoke testing compared to 28% last sprint.

cratermoon 4y ago

Yes but I've also been buried in presentations, diagrams, and ticket management that don't contribute to communication. That's doubly wasteful because not only is time wasted making all these artifacts, but even when produced they still don't improve understanding. Might as well have a chatbot write them, they couldn't be worse. Ticket management fails to keep anyone updated when it's just a performative way to make managers and execs believe they are seeing progress when in fact the ticket board is a fiction unrelated to real effort.

denton-scratch 4y ago

> Common examples include presentations, diagrams, and ticket management. Ticket management is stuff that needs doing, obviously. Diagrams are illustrations; if something is so complicated it can only be understood with a picture, it's too complicated. But a quick diagram on a whiteboard (or with a pencil on the back of a fag packet) might be helpful. Presentations (with slide-decks) are for managers[0], not engineers. They are a huge drain on time. I got severely dinged by my manager for doing a presentation without a slide-deck; I hadn't prepared one, because I had real work to do. But I think I showed my manager up, because all the other engineers had turned up with slide decks. A crap slide deck is quick to make, and completely useless. A really good slide deck can take days to make; it's a specialist trade, like making good user documentation. Slides must augment the presentation, not distract from it. [0] I've been forced into formal management once or twice; my experience was that at least half of management is bragging to other managers about how important your team is, and slide decks are great for that.

danaris 4y ago
> if something is so complicated it can only be understood with a picture, it's too complicated Absolutes like this contribute significantly, depending on the perspective they're spoken from, to the anti-intellectualism in our society today, or to a culture of elitism. For the first, some things are complex, and that complexity is part of the real-life systems and structures they have to interface with or represent. Explaining complex things with a diagram can be an extremely effective method for making what might otherwise require a very high cognitive load much easier to process. And for the second, if someone needs a diagram to understand something complex, it's not because they're stupid, and insisting that everything worth explaining can—and must—be explained in text only does them a disservice.
- knsv 4y ago
  I find that I write most diagrams for myself as a reader. It takes much less time to get an overview some logic I have not touched in a while when there is a diagram to start with. Once I remember the big picture I dig deeper via the code.
- 4y ago

polalavik 4y ago

I don’t know. Tickets can still be busy work depending on when you demand them to be done. Sometimes a ticket might best be handled at a different stage in the project to give it the time and context it deserves. If you are just closing out tickets, sometimes out of context and as fast as possible, you are doing busy work. This could just be bad ticket management with where I work. Or we use tickets in a less standard way. I’m not sure, I work in fpga design so it’s not like a user submitted bug, it’s a request from one of the 1000 review meetings.

NikolaNovak 4y ago

FWIW :) I used to despise the incredible amount of time we could spend on a single powerpoint slide sometimes. Then one day when going over same slide for the 5th time with my boss and mentor, I realized: * This slide will be seen by a person in power * they will make a decision based upon that slide * I would like to spend 3 hours explaining them the intricacies of my project/architecture/problem/whatever * But they have 10/100/1000 other projects, and they have 20/10/5/1 minute to devote to me before they make a decision * A slide or set of slides might therefore have an impact across 1/10/100 people over week/month/years due to a decision based on a slide or set of slides * therefore, it can at times be rationally logical to spend a lot of time word-smithing a slide in order to help the right decision As programmers, we understand that we might spend 10min/hour/days/weeks on a small but crucial piece of code, because we need the computer to understand it and do the exactly right thing in a complicated scenario; and we do not consider it a waste of time (though our management might! It's a curiously symmetrical situation :-) Sometimes, slides are exactly that, but for people - distilled information to enable executive stakeholder to do the correct thing. Same with other items - diagrams? They can be phenomenally useful! A good diagram can spread understanding of goal and ensure we all build the right thing. Bad diagram can set 100 smart people on divergent paths!

jupp0r 4y ago

You have never seen JIRA properly configured then.

strangattractor 4y ago

The only 10X engineers I have ever worked with were the ones that helped get 2X out of the five normally 1X engineers they worked with.

chang1 4y ago

I've discovered that this can be a deflection tactic for some. Usually it happens in a situation where I try my best to explain a part of an app or system. The other person is overwhelmed or confused but doesn't just say that, and instead kicks the can down the road by saying there is a lack of documentation to reference or are in need of diagrams. When I then take the time to add info to a wiki or spend time diagramming concepts with those developers, it seems to not help aid understanding at all. Then I realize I just wasted a lot of time.

nico 4y ago

Everyone is different. The key is not forcing people into your own worldview. Some people do better with documentation or tickets or code or meetings. The point is that forcing people to do shit they don’t want to do will backfire and make teams unhappy and unproductive.

jltsiren 4y ago
Everyone is different, but it doesn't matter that much. When you have a small team, you can often organize the work the way people prefer. Then you'll find that people who can be incredibly productive under ideal circumstances are actually quite common. But as the organization grows, you have to focus more on the process and the structure. Individual productivity doesn't matter if you can't channel that productivity to advance the organization's goals. You rely increasingly on people who can work productively within the system. People who thrive in a wide range of environments, even when they would prefer having things organized in a different way.
- nico 4y ago
  Why does the organization need to grow?

ResearchCode 4y ago

It's busy work if you do it more than 1 hour any given week. If you do it full-time, you're something like a -10x engineer.

treeman79 4y ago

Had many times where I saved a company months of work by forcing a meeting to lock in UX requirements. Basically go through screen to screen on a whiteboard what should happen. This almost always leads to major changes to the whiteboard during the meeting. Had many times were I couldn’t get company to do this exercise. First time leadership sees UX is on completed project. Team then spends months rewriting application. Everyone generally pissed.

wpietri 4y ago

> Ticket management is not busy work, it's a necessity for everyone to keep updated. Yes and no. If I oversimplify one of the important Lean points, you can divide activity into 3 buckets: 1) value-creating, 2) necessary waste, 3) pure waste. It's important here that "value" is always measured from the customer perspective. For example, imagine a hamburger joint. You have ordered a cheeseburger. The person at the grill cooks a patty for you, puts some cheese on it, and assembles a burger. Then somebody else walks that burger to you. Except they get distracted after they've picked it up, so they end up walking to the back before coming up to give it to you. Making the burger is value creating. You wouldn't want a raw patty, and you want it put together right. Walking the burger to you is necessary waste, in that moving the burger does not increase its value, but we have to do it to deliver value. The little stroll to the back is unnecessary waste in that you could receive the same value without it. Make sense? With that framework, let's think about software. Ticket management is not a value-creating activity. If I do an extra hour of ticket management, that does not guarantee increased value. At best, it's necessary waste: I just can't figure out how to get you what you want without N hours of ticket management. But quite often it's unnecessary waste, labor performed for some purpose other than customer value. For example, a lot of planning activity is about making high-status people feel important. Or part of somebody's ongoing battle for increased status. Or the downstream consequence of previous unaddressed failures causing distrust. So can ticket management be necessary waste? Sure. But it's often pure waste. I've done whole companies with no more ticket management than you get out of a bunch of index cards on the wall. [1] And we got there by relentlessly cutting the waste of heavier processes, something that a lot of companies won't even think about, much less attempt, because there productivity is relatively unimportant. [1] e.g.: https://williampietri.com/writing/2015/the-big-board/ https://williampietri.com/writing/2015/the-big-board/

bstpierre 4y ago
If the ticket is a direct conduit to the customer, I think you could argue that ticket management in the form of asking clarifying questions so that you build the right thing (or fix the right bug) is creating value?
- wpietri 4y ago

anonytrary 4y ago

Engineer who implements correct, comprehensible code but doesn't manage ticket statuses is more valuable than one who manages ticket statuses but scatters the codebase with technical debt and confusing abstractions/code. If "better communication" means spending an extra 10 hours with the latter dev to correct/re-teach them, then yes, communication is the problem. The most time I've lost at work is correcting/teaching engineers who eventually got let go due to low performance.

doesnt_know 4y ago
I don't really think the first part of your comment is true, at least not in my experience. All other stakeholders would prefer someone that updates their tickets and communicates what they are doing effectively, even if they produce absolute garbage, bug ridden software. I've personally only ever seen someone removed from a team for having poor technical skills once and it was under pretty extreme circumstances. While I've seen many good (from a technical perspective) developers removed because they thought they were somehow above doing the everyday "busy work" like ticket management. Unless you work alone, then refusing to do non-technical work is just saying you're going to let the rest of the team do it. You're much more likely to be removed or have your contract ended if the team doesn't want to work with you.
- asdff 4y ago
  Without going into anything identifying, what exactly were those circumstances? I'm imagining something like this happening, but at the same time I can't help but think if its a technical skill issue, handing them a book on the relevant technology and telling them studying this book is their job for the next two weeks would be better than trying to roll the dice again, put out a new job ad, interview, vet, rehire, and hope they aren't somehow just as technically incompetent as the original engineer.

alfalfasprout 4y ago

1000%. A lot of this stuff seems like busy work to junior engineers and bad senior/staff engineers. But this is how you spend a few days to save months of wasted effort.

com 4y ago

I’m a big fan of putting more time and effort into communication. I just think that there’s an incredible set of decreasing returns after about 30 minutes into building any diagram or presentation, for most people and most use cases. That’s why quick whiteboard or lucidchart or Miro sketches are so powerful - and are designed to communicate in the moment! - and most PowerPoints, swimlane diagrams etc which have tens or hundreds of hours of work are like polished turds. Very few diagrams or presentations show history and almost none are ever updated to show the status of things today. Which means that they just cause confusion. Generally, someone starts again and creates something with new blind spots and which takes about as much time again to create, and is out of date before others see it. Drawing and presenting is mostly interesting if the people who are present for the drawing or description process can go forth and explain, draw or present it in their own words or images, and therefore communication has been achieved; this seems to be very uncommon in most drawing and presentation-heavy environments I’ve been in though.

40yearoldman 4y ago

But at what point does that communication cost more than just hiring somebody else who needs less hand holding and less "communication" to understand what is going on and figure out what to next. I say this because there always seems to be those who don't need this. And it's the ones who need this who never seem to produce as much or are able to solve the problems on their own. So I ask. If you could hire people who need this "communication" or hire people who don't need the "communication" and they both can get the job done, why would you hire those that require time consuming processes. Good teams don't need Jira, good teams don't need power points, good teams don't need all the hand holding. These are tools to include those who can't and often bring minimal usefulness to the table. Poor communication is code for "I have no clue what I am doing and am going to blame others for why I am not useful, but I don't want to admit to others I have no clue what I am doing.". Next time you find your self thinking somebody is poorly communicating, try this in stead. Say "Hey, I don't know what I am doing, I am lost, where can I start? More often than not this "poor communicator" is going to be able to direct you to a task that will not only make you useful, but also not require much more than 5 minutes of exchange and as a result you will probably learn something that will make you more useful in the long run. > in my experience it has been the sub-par employees who are the ones that don't do this. To directly call this out, the sub-par are often the ones doing all this stuff, because they simply can't do the actual work. Sub-par is probably not fair, as a good manager will build a team with a few of these folks to tend the toil. So they are useful in a way. Also you all can think back on the time that you hired somebody and they knew more than just about everybody about how the product works and should work within just a few weeks. This person clearly did not need the documentation, they simply read the code -- the code is the documentation -- and the quicker folks stop thinking like tis anything else other than a big manual the faster they will be able to learn new code bases and become useful. The constant translation between weird human social ideas of what is good communication and a solid structured communication such as code its an incredible waste of time. Just remember, your job is to write code to tell a computer what to do, and if you can't also read that code to figure out what the program should do, you might be computer illiterate which makes you less valuable than somebody who can both write and read code in the same manner as the systems that will consume it. If you have ever had somebody tell you "it's like you compile the code in your head" you will know what I am talking about.

mathattack 4y ago

Yes. Disorganization is the largest cause I’ve seen of preventable waste.

asdff 4y ago

These examples imo are often sources of added fluff to process. The goal of the presentation is to get the point across. Unfortunately, I see too many people make these terrible powerpoints, where its clear they spent too much time making the template sexy and not enough time considering what content the content is. My favorite powerpoints are the ones where people use the default white background and text, and just put up a single figure per slide and describe them versus talking off bullet points with a bunch of junk imagery. If I am reading a sentence on your slide, I am incapable of listening what is coming out of your mouth at the same time. Basically, the slide deck should only take you as much time to make as pasting your figures over to it.

novembermike 4y ago

Yeah, these things are all part of being a team of 1x engineers rather than a team of .5x engineers. If you have a single 10x (and I've worked with some) then it's not important but those guys have their own issues.

mesozoic 4y ago

The important part is that you do it for something that's not all that important then make sure to get the project dumped before any real progress is made.

not_enoch_wise 4y ago

These idiot, overpaid engineers don’t understand how important tickets & tracking metrics are. As if turning a measurement into a target could make it cease to become a good measurement!

deleted 4y ago

[deleted]