3 ms·

The article uses JIRA is a touchstone that seems to equate to no autonomy. I think this is wrong. I have worked at a good number of places, including a FAAMG.

The article uses JIRA is a touchstone that seems to equate to no autonomy. I think this is wrong. I have worked at a good number of places, including a FAAMG. The freedom that was given to me directly correlates to company size & seniority. When I was younger, I didn't get much autonomy, why? because I was a naive arrogant prick. I would dream up solutions to problems that didn't exist. I would make existing problems worse by trying out new things. When a company gets larger, it will bump into problems, missed features, deadlines or massive bugs. New procedures will get be implemented to make sure that those don't happen again. Ticketing is a good thing, so long as its developer lead. It allows delegation of tasks, and simple tracking of state. Its an artform that should be taught. I was at a start up for two years that was bought out by a FAAMG. We were working on cutting edge computer vision research. We had a tight process, tracked with ticketing. We had complete autonomy. We were chucked into SV "culture" only to find that is somehow managed to make cutting edge research both more chaotic and boring. Ironically I have much less freedom than I did when I worked at a large financial newspaper.

throwawaybbqed 6y ago
Can you please describe how you had a Jira/ticket system that you felt gave you autonomy? Very curious how it could be implemented in a research setting.
- q845712 6y ago
  not the GP, but I've had multiple times in my career when I and the team I was on were given pretty high-level problems to solve and left alone to solve them. The request to use JIRA was basically our managers and the product people wanting some vague reassurance that progress was being made, but nobody was concerned with the details of the tickets, etc. This included early-phase 'R&D' work on a medical device. Of course in that setting once the device was on a release cadence, if we were contributing to the 1.x line of the release we had a lot more overhead :). However even then you could always file yourself a more R&D flavor ticket, as long as it was going to the long-term branch and not to the release branch... What it came down to, per the article, was that everyone in the co. respected that the engineering team was capable of delivering results and solving problems. But i think per your question about JIRA, it gives you autonomy if: - anyone on the team can add a ticket - the team is trusted to make small changes in scope or spec to tickets in response to things they encounter as they work - there is little to no ceremony around accepting tickets as done - the team is trusted to check their own work first, and then collaborate with QA / stakeholders / etc. on releases
  - throwawaybbqed 6y ago
    Thx for your thoughts. You mentioned R&D flavor tickets. Really curious about the mechanics of this. Does the responsible engineer update once a sprint, weekly? I've seen junior staff spend months on dead ends .. curious how to manage that via process. Also, if the R&D project is a team project involving multiple people, what is a reasonable update/sprint cadence?
- cwp 6y ago
  Dunno about research, but I've worked in a few SV startups that organized development with Jira and had high autonomy for engineers. Some of the features of those teams: 1. Most tickets are opened by engineers themselves, and don't contain detailed specifications, but just notes to provide context. 2. The purpose of the ticket is to provide something to link to, and a place to put information as it emerges. So commits and PRs usually link to a ticket, as do engineering and product management planning documents, reports etc. Some tickets are terse and quickly closed, others could develop a long history, with status changes, links to other tickets and documents, ownership by different engineers over time etc. 3. We organize development into sprints, but a Scrum master would be disgusted by our process. Sprints are just short-terms planning horizons; we ship as soon as the code is ready and close tickets when the code is in production. The purpose of a sprint is to batch up all the low-level planning and prioritization so most of the time we're focused on execution. 4. High-level planning is all in GDocs, spreadsheets and Photoshop/Figma. Product management doesn't create tickets unless they are reporting a bug, and even that was pretty rare. Engineering management gets a lot of information about what's going on by observing Jira; this reduces the need for meetings to communicate status. (Doesn't eliminate meetings, of course, but it does seem to make them more interesting.) Basically, it boils down to, you have to keep status somewhere, and Jira does that pretty well.
- koonsolo 6y ago
  I had a similar experience years ago. It was not Jira but bugzilla, but you can use it in the same way (I told you it was years ago ;)). Any engineer could open any ticket for another engineer or team. You could also set the priority to how urgent it was. The receiving engineer could adjust the priority according to their own work of course. Basically all work that you do was in the tracker. You could even add things for yourself, so you had a central place for your or anyones todo list. Best work environment I ever worked as a software developer. There was never something blocking that some manager had to resolve, because you would just open a ticket an assign it to the person or team you think is relevant. All discussion was done in the ticket.
- KaiserPro 6y ago
  How it worked for us was as follows: the business goals were translated into "epic" tickets, after that it was entirely up to the engineers. An example of this would be something like: We need an API that allows secure access to service x. It must have authentication, respond with an answer inside x milliseconds, It must work with a developer admin interface (see ticket z) Ticket z would be assigned to the web team, and we would work closely on an interface between the API backend and the dev interface. After that, my team would layout and make a high level design. We'd break that design down into individual "sub epics" and let each dev create and work on tickets as they see fit.
chris11 6y ago
> The article uses JIRA is a touchstone that seems to equate to no autonomy. Technically I don't think JIRA by itself means no autonomy, it's just how it's used. But JIRA can expose a ton of metrics to upper management. And I think that management influencing how JIRA is used probably indicates lower autonomy. For instance, story points and velocity being tracked by management might be problematic. Is the team tracking everything with story points? Otherwise certain types of work could be hidden, and slow down velocity. Is management using those metrics for team or individual performance reviews?
letitbeirie 6y ago
> JIRA is a touchstone that seems to equate to no autonomy Jira doesn't intrinsically take away engineers' autonomy but in many cases it's the most visible manifestation of company policies/procedures that do.
bigiain 6y ago
Jira, for all it's warts, is a massively configurable piece of software that can be deployed/used in a hugely broad variety of ways. I once worked at a place where Jira was without doubt a positive force within the company. There was an Altassian-trained Jira specialist working there who collaborated setting up each Jira project, and provided ongoing advice/assistanece to users (both PMs and devs). This was in a company of around 40 devs, 8 QAs, and 6 PMs, running perhaps 10-12 concurrent projects (almost all websites/webapps). It worked _really really_ well. (And I've spent th3e last 5-6 years looking for excuses/opportunities to poach that specialist...) The key takeaways I learned from her was to identify and get leadership agreement right up front about whether a particular project was going to be "agile" or "waterfall" - because if you are going to be agile, Jira wants to be set up as a high level todo list of features/functions. If _any_ of the Jira tickets start to decree (from a PM/BA/manager) _how_ a feature or function is to be accomplished, you're fooling yourself and should have set it up as a waterfall project full of disposable-worker-bee style tickets. I'm sure my takeaway was only scratching the surface of the deep understanding she had about project planning and managements styles, but that has work OK for me over the years. Either provide Jira tickets for features, and let the devs create their own sub tickets to document how they're doing things (and to get discussion/signoff on thing they ask for input on), or have the PM/BAs document a project in minute detail and fill each dev's schedule with sprints full of tickets representing 2 hours work or less. I guess my point here is "Don't blame Jira. It's widely criticised flaws are largely a problem with the way it's used rather than a fundamental flaw in the tool. Poor project management results in shitty Jira use. Great project management will shine even if using postit notes stuck to devs laptops every day."
- mark-r 6y ago
  Yes, Jira is very configurable. But whether you'll be allowed to configure it is an open question. I worked on a team that had a very finely tuned Jira workflow. Then one day we discovered that all our customizations had been eliminated. The company had decided that it wanted all configurations to be based on a company standard, and no deviations would be allowed. We weren't even warned ahead of time.
  - 6y ago

throwawaybbqed 6y ago

Can you please describe how you had a Jira/ticket system that you felt gave you autonomy? Very curious how it could be implemented in a research setting.

q845712 6y ago
not the GP, but I've had multiple times in my career when I and the team I was on were given pretty high-level problems to solve and left alone to solve them. The request to use JIRA was basically our managers and the product people wanting some vague reassurance that progress was being made, but nobody was concerned with the details of the tickets, etc. This included early-phase 'R&D' work on a medical device. Of course in that setting once the device was on a release cadence, if we were contributing to the 1.x line of the release we had a lot more overhead :). However even then you could always file yourself a more R&D flavor ticket, as long as it was going to the long-term branch and not to the release branch... What it came down to, per the article, was that everyone in the co. respected that the engineering team was capable of delivering results and solving problems. But i think per your question about JIRA, it gives you autonomy if: - anyone on the team can add a ticket - the team is trusted to make small changes in scope or spec to tickets in response to things they encounter as they work - there is little to no ceremony around accepting tickets as done - the team is trusted to check their own work first, and then collaborate with QA / stakeholders / etc. on releases
- throwawaybbqed 6y ago
  Thx for your thoughts. You mentioned R&D flavor tickets. Really curious about the mechanics of this. Does the responsible engineer update once a sprint, weekly? I've seen junior staff spend months on dead ends .. curious how to manage that via process. Also, if the R&D project is a team project involving multiple people, what is a reasonable update/sprint cadence?
cwp 6y ago
Dunno about research, but I've worked in a few SV startups that organized development with Jira and had high autonomy for engineers. Some of the features of those teams: 1. Most tickets are opened by engineers themselves, and don't contain detailed specifications, but just notes to provide context. 2. The purpose of the ticket is to provide something to link to, and a place to put information as it emerges. So commits and PRs usually link to a ticket, as do engineering and product management planning documents, reports etc. Some tickets are terse and quickly closed, others could develop a long history, with status changes, links to other tickets and documents, ownership by different engineers over time etc. 3. We organize development into sprints, but a Scrum master would be disgusted by our process. Sprints are just short-terms planning horizons; we ship as soon as the code is ready and close tickets when the code is in production. The purpose of a sprint is to batch up all the low-level planning and prioritization so most of the time we're focused on execution. 4. High-level planning is all in GDocs, spreadsheets and Photoshop/Figma. Product management doesn't create tickets unless they are reporting a bug, and even that was pretty rare. Engineering management gets a lot of information about what's going on by observing Jira; this reduces the need for meetings to communicate status. (Doesn't eliminate meetings, of course, but it does seem to make them more interesting.) Basically, it boils down to, you have to keep status somewhere, and Jira does that pretty well.
koonsolo 6y ago
I had a similar experience years ago. It was not Jira but bugzilla, but you can use it in the same way (I told you it was years ago ;)). Any engineer could open any ticket for another engineer or team. You could also set the priority to how urgent it was. The receiving engineer could adjust the priority according to their own work of course. Basically all work that you do was in the tracker. You could even add things for yourself, so you had a central place for your or anyones todo list. Best work environment I ever worked as a software developer. There was never something blocking that some manager had to resolve, because you would just open a ticket an assign it to the person or team you think is relevant. All discussion was done in the ticket.
KaiserPro 6y ago
How it worked for us was as follows: the business goals were translated into "epic" tickets, after that it was entirely up to the engineers. An example of this would be something like: We need an API that allows secure access to service x. It must have authentication, respond with an answer inside x milliseconds, It must work with a developer admin interface (see ticket z) Ticket z would be assigned to the web team, and we would work closely on an interface between the API backend and the dev interface. After that, my team would layout and make a high level design. We'd break that design down into individual "sub epics" and let each dev create and work on tickets as they see fit.

chris11 6y ago

> The article uses JIRA is a touchstone that seems to equate to no autonomy. Technically I don't think JIRA by itself means no autonomy, it's just how it's used. But JIRA can expose a ton of metrics to upper management. And I think that management influencing how JIRA is used probably indicates lower autonomy. For instance, story points and velocity being tracked by management might be problematic. Is the team tracking everything with story points? Otherwise certain types of work could be hidden, and slow down velocity. Is management using those metrics for team or individual performance reviews?

letitbeirie 6y ago

> JIRA is a touchstone that seems to equate to no autonomy Jira doesn't intrinsically take away engineers' autonomy but in many cases it's the most visible manifestation of company policies/procedures that do.

bigiain 6y ago

Jira, for all it's warts, is a massively configurable piece of software that can be deployed/used in a hugely broad variety of ways. I once worked at a place where Jira was without doubt a positive force within the company. There was an Altassian-trained Jira specialist working there who collaborated setting up each Jira project, and provided ongoing advice/assistanece to users (both PMs and devs). This was in a company of around 40 devs, 8 QAs, and 6 PMs, running perhaps 10-12 concurrent projects (almost all websites/webapps). It worked _really really_ well. (And I've spent th3e last 5-6 years looking for excuses/opportunities to poach that specialist...) The key takeaways I learned from her was to identify and get leadership agreement right up front about whether a particular project was going to be "agile" or "waterfall" - because if you are going to be agile, Jira wants to be set up as a high level todo list of features/functions. If _any_ of the Jira tickets start to decree (from a PM/BA/manager) _how_ a feature or function is to be accomplished, you're fooling yourself and should have set it up as a waterfall project full of disposable-worker-bee style tickets. I'm sure my takeaway was only scratching the surface of the deep understanding she had about project planning and managements styles, but that has work OK for me over the years. Either provide Jira tickets for features, and let the devs create their own sub tickets to document how they're doing things (and to get discussion/signoff on thing they ask for input on), or have the PM/BAs document a project in minute detail and fill each dev's schedule with sprints full of tickets representing 2 hours work or less. I guess my point here is "Don't blame Jira. It's widely criticised flaws are largely a problem with the way it's used rather than a fundamental flaw in the tool. Poor project management results in shitty Jira use. Great project management will shine even if using postit notes stuck to devs laptops every day."

mark-r 6y ago
Yes, Jira is very configurable. But whether you'll be allowed to configure it is an open question. I worked on a team that had a very finely tuned Jira workflow. Then one day we discovered that all our customizations had been eliminated. The company had decided that it wanted all configurations to be based on a company standard, and no deviations would be allowed. We weren't even warned ahead of time.
- 6y ago