14 ms·

Great insight, my key takeaway is this: > The fewer people you need to make decisions, the faster you can make them. This is the only way I’ve seen a “rocksta

Great insight, my key takeaway is this: > The fewer people you need to make decisions, the faster you can make them. This is the only way I’ve seen a “rockstar” or “10x” get stuff done as fast as they do. They only have to talk to a couple of people at most to start making big changes. The more large and stable a company gets, the more they seem to want to spread decision making power around the org. This appears to be very counterproductive, and it’s nice to see the simple truth called out.

azemetre 4y ago
I feel this in my soul, I'm not even allowed to update internal documentation in our repo without linking it to a JIRA ticket.
- mr-ron 4y ago
  I mean, thats pretty normal for any stage tech organization. The question is, who gets the right to create a jira ticket? Maybe you can do it, or just one other person. Thats not a big limitation at all to moving quick. Edit because this is causing a stir: Engineers within teams should have the right to create tickets themselves. Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds. Updating documentation may require a pull request. Controls (SOC compliance) may require that work is tracked to tickets. The core questions I have is, who can create the tickets, and how detailed do they need to be?
  - notyourwork 4y ago
    What is normal about this? Engineers should be empowered with ownership. Adding. friction or barriers to enabling engineers to make what they own better is backwards and counter productive at best. At worst, it discourages proactive willingness to make an improvement.
    - mr-ron 4y ago
      What is normal about this that Ive seen is work and tickets is often written into controls that are required for things like SOC compliance. And documentation often requires a pull request. And again read what I said, that engineers can and could be empowered to make these tickets, which can be minimal at best. Done right, its not a limitation at all, and instead adds accountability.
      - eropple 4y ago
        > Done right, its not a limitation at all Context switches are limiters, IME. Smash somebody's stack and you've made them useless for half an hour.
        mr-ron 4y ago
        This is why tickets can be used to protect the engineering team. You dont want people ad-hoc adding scope, or interrupting work for engineers. You want engineers to have focus time, on a clear actionable item, that is set up for success, and will add value. Allowing engineers to work on whatever they want, or change scope on what they want, without saying 'why', can end up creating a lot of wasted work.
        eropple 4y ago
        Tickets can, theoretically, be used to protect a development team. I agree with you there. But they usually aren't, and most folks are living in the land of what-is, not what-can-be.
        mr-ron 4y ago
        Yes I agree and thats why Scrum / Agile gets a bad rap around here.
      - knightofmars 4y ago
        "...things like SOC compliance." This is an important point. If you work in a regulated industry or work with software used in a regulated industry you need a "paper trail". Having to document and follow a process is often frustrating to people who work or have worked in industries that don't require it. That said, a poorly implemented process in a regulated industry is even worse. As you're overloading teams with busy work and likely still failing to meet the requirements of the regulations you're following. Regulated software is not a place to "move fast and break things" that's what prototypes that never see the light of production are for. Build it without regulation to figure out how to do it and then build it again following the documentation process. It may sound odd but having a second chance to correct errors of assumption from the first time around is quite valuable, buying information when done right is a great tool.
  - whynotmaybe 4y ago
    You find it normal that you need a Jira ticket to update documentation? If while reading a document, you find a mistake, instead of changing it, the normal reflex is to create a Jira ticket?
    - mr-ron 4y ago
      It depends on the documentation. Is it within a repo? Does it require a pull request? Is it a quick edit, or is this a multi hour effort that is redoing the scope?
    - timmytokyo 4y ago
      I find this whole back-and-forth fascinating, because it mirrors my experiences in the workplace. There are some people who really like process around everything an engineer does, and some people who really don't like it. They're almost two distinct personality types, and it's virtually impossible to get them to agree because it's like asking someone to change their personality. I happen to be one of the types who dislikes heavy process-oriented project management, and reading mr-ron's responses is admittedly making my blood boil. But I bet he reads some of the responses to his remarks and probably has similar reactions. Some people thrive with heavy process, and some people wither. Some people thrive with light-weight process, and some people wither. I don't know how to structure an organization to support both types of people in it, but it's not an easy problem to solve. That's why there are so many project management methodologies, with new ones popping up every few years and then inevitably disappearing in favor of something new and better.
      - mr-ron 4y ago
        Im not sure why you are describing my example of PRs needing tickets to be 'heavy process'. Especially since Im pushing for engineers being able to create quick ad-hoc tickets within 30 seconds.
        timmytokyo 4y ago
        It feels heavy to me, because you're asking for a process gate to be put in front of something that is so trivial. It feels utterly unnecessary and demotivating. If I see a minor problem in the documentation and decide to correct it, now I have to go through an extra step of creating a JIRA ticket describing the minor problem I'm trying to solve, doing the correction, updating the JIRA ticket status, and possibly monitoring the ticket for future issues. It's. all. so. bureaucratic. And sadly it will probably lead me to thinking the fix is not worth my time. Instead of trying to convince everyone that they should feel the way you do, maybe try to understand why others feel the way they do.
  - azemetre 4y ago
    I disagree with it moving quickly, all it does is encourage me to not update documentation and not actively improve the code in other ways due to inane bureaucracy. And surprised surprise, no on else on the team wants to document anything either; people get burnt out because they have no autonomy and just leave. All is good tho! We followed the process and that's the only thing that matters. I wonder what the corporate equivalent to "I was just following orders" is?
    - mr-ron 4y ago
      If an engineer can create a ticket and work on it, thats not reducing autonomy. Thats adding accountability. If documentation requires a pull request / merge to update, often you have set controls that require a jira ticket. Its super common to not allow engineers to make solo commits without a pull request. If an engineer sees the creation of a jira ticket as a limitation, or if they are not empowered to create their own tickets, then Id agree its a problem.
      - carlisle_ 4y ago
        Is creating the ticket really adding value to the engineering process? In your example you already have the engineer making a PR (presumably peer reviewed) and a commit, what’s the ticket really needed for?
        mr-ron 4y ago
        It can add value if done right. Just as you typically want to make a design doc / rfc before working on a project, you often want to describe what you are doing before you do it. This can protect the engineer / team against scope creep, as well as determine the context of why work was done when you may need to understand more context (in the case of a bug for example). Also it increases accountability and transparency. It is common that teams want to know what other engineers are working on and why.
        carlisle_ 4y ago
  - RayFrankenstein 4y ago
    Cute Agilist gaslighting about not needing a ticket because that’s “asking for permission” and it’s supposed to be implicitly bundled into feature work.
  - ianbutler 4y ago
    Is it? I've never needed a ticket to make off the cuff improvements. A PR and a review from other engs to make sure they agree, certainly, but a ticket for that seems like a certain degree of dev micromanagement/big brother/power trip for highly paid and skilled professionals.
    - Rapzid 4y ago
      At my previous gig we reduced the friction for doc contributions to just a PR but with no review requirement; if the contributor felt the need for feedback or review they would seek it, otherwise just merge the changes.
  - sanderjd 4y ago
    That's a stupid compliance requirement, unless documentation changes aren't themselves versioned (which they should be). You don't need to track the exact same thing in two separate places.
  - lupire 4y ago
    If it's so important to have a ticket, the patch submission pipeline should create one automatically.
  - Too 4y ago
    ”Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds” This type of placeholder-documentation is literally the WORST type of tracking you can have. And a sign that everybody in your company forgot the reason why this type of traceability was implemented in the first place. If I review a PR that links to a Jira ticket that says absolutely nothing except “update documentation”. What’s the whole point?! What’s worse is when people see a link to a Jira as an excuse to write bad commit messages. I would much rather read a commit message detailing out the background and rationale of the change, rather than a nonsense commit message linking to another nonsense kpi-chasing Jira ticket. PRs are code reviewed anyway so it’s not like you have a bonanza of unknown changes being pushed left and right. Code reviews not only catches coding bugs but also accountability within the team, eg “why are you refactoring something that works, when our backlog has 100 other more important things to do.”
duxup 4y ago
“Jim is so productive!” -by design Jim is the only one allowed to be productive- :P
nickjj 4y ago
This is really it. There's a world of a difference in what you can do if you have free reign to make most technical decisions with full autonomy (self guided R&D, picking stuff, spiking it out, doing it for real, etc.), perhaps only reporting back weekly outcomes to a CTO and also asking their advice as needed to align on big picture goals while nothing is ever blocked. vs. Most decisions needs to go through someone else, which then turns into an adhoc request for another department which then has to ticket it out and implement things on their schedule. They could be a great team and do everything in the best way you can realistically hope for but before you know it, things that were literally 1 or 2 hours of dev time end up taking 3-4 weeks simply because they have other things going on too. You keep repeating this pattern and it's how something ends up taking 6 months instead of 2 weeks. It's also one of the most frustrating things to be blocked. It forces you to context switch between many things to keep yourself busy. You spend all of your time reacting to eventually getting unblocked in an uncontrolled way instead of just sitting down and cranking it out. That means you might have to jump back into something you worked on 2 weeks ago and re-get all of that context back in your head. I know in an Agile sense every team should be self sustained and can own their work from beginning to end but from an infrastructure perspective you may run into scenarios where you need resources created by another team because in a bigger org it's company policy. The blockers could be a combo of waiting on that other team or waiting until multiple people sign off on moving forward with XYZ tech.
altacc 4y ago
One of the reasons enterprise organisations are so slow to adapt and release new products is the number of people needed to make a decision. I've seen large companies try to implement agile and it generally fails because they can't shift to quick & effective decision making processes. Greenfield projects that get developed quickly due to independence and have great promise for the future get the hug of death as soon as management decides to bring the project into the same decision making as the rest of the org.
- salmonfalls 4y ago
  This is the exact case that I have been in the last two years or so. As a greenfield project being one of the first in the newly implemented Agile work. Everything was amazing in the beginnig with quick decision making. However as soon as we 'went live' and were forced into the established change control workflow development grinded to a halt. We now implement features at a snails pace compared to before.
jeffbee 4y ago
I don't think it's about largeness, and the autonomy of "rockstars" is of dubious value. Google is the largest company where I've worked, and also the most productive. For code that an IC owns, they only need the sign-off of literally anyone else in the company to land changes, and all that is expected is those changes are generally consistent with team goals. For code an IC does not own, they only need the approval of one owner. Pretty straight-forward. A medium-sized company where I worked had a "rockstar" who was really just an early employee with a high title and no idea what he was doing, so every week he committed a thousand lines of brand-new unreviewed tech debt. Much of the rest of the company was unwittingly dedicated to overcoming his tech debt. Said company currently trades at about 1/3rd below its IPO valuation. The experience of these two companies led me to the belief that hiring practices and review culture are more important than project management culture. You can get a lot done with good talent, code and design review, and vaguely disorganized project leadership, and you can run in place achieving nothing with formal project management hamstrung by bozo engineers.
- carlisle_ 4y ago
  > and the autonomy of "rockstars" is of dubious value. I agree, but with your example, I wouldn’t call somebody committing massive amounts of tech debt a “rock star”. I used the term fairly facetiously anyway, because I think we all know the 10x engineer is a myth.
tgv 4y ago
Such is the nature of organisations. E.g., X is the boss of a group, the group becomes a department, X hires people to manage the groups in the department, and now all these people have to be informed as well, and of course they have an opinion, too. And they are rarely good managers. Then X leaves and politics kick in because everyone covets the position, and then someone's simple task becomes the focus of someone who wants to place your manager in a bad light. And it never stops, because there's no incentive to make it stop.
rco8786 4y ago
> I t’s nice to see the simple truth called out. It’s not as though it’s a secret or anything. It’s a common point of discussion. The simple matter is that big co’s naturally have more inputs into the same types of decisions and thus need more people involved.
lifeplusplus 4y ago
In my past job, I volunteered and pushed to get the whole project, then I asked to be exempted from all scrum stuff, then got really close to PM and Designer, launched the whole thing without a single bug in 3 months and with more features than planned, and had 2 more months left. The reason there were no bugs was because any question I had, I slacked messaged PM, and got replied in less than a minute. She was on the project full time too, and was technical so was able to test out things and apis, document correct relevant data like console log errors, browser version, json response, curl ... etc. My takeaway was similar to yours but in more concrete terms: - have experts available in team which can be consulted asap - give whole projects - start with minimal project - create small informal groups, POC for each area: sr eng for legacy code, designer to get artifacts, PM to clarify tickets and address new bugs, main dev to do the whole thing - have team informally occasionally input on tech decisions.
deleted 4y ago
[deleted]
sanderjd 4y ago
Yeah this is exactly it. But I think it's a good thing. It's a tradeoff between productivity and risk. It is productive but risky for "rockstars" to make big changes with very little consensus-seeking. Big changes are double edged, they have outsize impact, but it may be either positive or negative. So organizations rationally hedge that. The trick is to strike a good balance, giving up as little productivity as possible for the greatest reduction in risk. It's hard! Sometimes the right answer is just "empower one or a few people to do whatever they think best without ever seeking any buy in from anyone else", but not often. And "never let anyone do anything without a big slow sprawling committee giving permission" is essentially never the right answer. But there is lots of space in between these extremes!
lupire 4y ago
Your 10x rockstar is my cowboy coder 0.1xing the team.
- carlisle_ 4y ago
  The use of the term was supposed to be illustrative and mostly facetious, hence the quotes.

azemetre 4y ago

I feel this in my soul, I'm not even allowed to update internal documentation in our repo without linking it to a JIRA ticket.

mr-ron 4y ago
I mean, thats pretty normal for any stage tech organization. The question is, who gets the right to create a jira ticket? Maybe you can do it, or just one other person. Thats not a big limitation at all to moving quick. Edit because this is causing a stir: Engineers within teams should have the right to create tickets themselves. Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds. Updating documentation may require a pull request. Controls (SOC compliance) may require that work is tracked to tickets. The core questions I have is, who can create the tickets, and how detailed do they need to be?
- notyourwork 4y ago
  What is normal about this? Engineers should be empowered with ownership. Adding. friction or barriers to enabling engineers to make what they own better is backwards and counter productive at best. At worst, it discourages proactive willingness to make an improvement.
  - mr-ron 4y ago
    What is normal about this that Ive seen is work and tickets is often written into controls that are required for things like SOC compliance. And documentation often requires a pull request. And again read what I said, that engineers can and could be empowered to make these tickets, which can be minimal at best. Done right, its not a limitation at all, and instead adds accountability.
    - eropple 4y ago
      > Done right, its not a limitation at all Context switches are limiters, IME. Smash somebody's stack and you've made them useless for half an hour.
      - mr-ron 4y ago
        This is why tickets can be used to protect the engineering team. You dont want people ad-hoc adding scope, or interrupting work for engineers. You want engineers to have focus time, on a clear actionable item, that is set up for success, and will add value. Allowing engineers to work on whatever they want, or change scope on what they want, without saying 'why', can end up creating a lot of wasted work.
        eropple 4y ago
        Tickets can, theoretically, be used to protect a development team. I agree with you there. But they usually aren't, and most folks are living in the land of what-is, not what-can-be.
        mr-ron 4y ago
        Yes I agree and thats why Scrum / Agile gets a bad rap around here.
    - knightofmars 4y ago
      "...things like SOC compliance." This is an important point. If you work in a regulated industry or work with software used in a regulated industry you need a "paper trail". Having to document and follow a process is often frustrating to people who work or have worked in industries that don't require it. That said, a poorly implemented process in a regulated industry is even worse. As you're overloading teams with busy work and likely still failing to meet the requirements of the regulations you're following. Regulated software is not a place to "move fast and break things" that's what prototypes that never see the light of production are for. Build it without regulation to figure out how to do it and then build it again following the documentation process. It may sound odd but having a second chance to correct errors of assumption from the first time around is quite valuable, buying information when done right is a great tool.
- whynotmaybe 4y ago
  You find it normal that you need a Jira ticket to update documentation? If while reading a document, you find a mistake, instead of changing it, the normal reflex is to create a Jira ticket?
  - mr-ron 4y ago
    It depends on the documentation. Is it within a repo? Does it require a pull request? Is it a quick edit, or is this a multi hour effort that is redoing the scope?
  - timmytokyo 4y ago
    I find this whole back-and-forth fascinating, because it mirrors my experiences in the workplace. There are some people who really like process around everything an engineer does, and some people who really don't like it. They're almost two distinct personality types, and it's virtually impossible to get them to agree because it's like asking someone to change their personality. I happen to be one of the types who dislikes heavy process-oriented project management, and reading mr-ron's responses is admittedly making my blood boil. But I bet he reads some of the responses to his remarks and probably has similar reactions. Some people thrive with heavy process, and some people wither. Some people thrive with light-weight process, and some people wither. I don't know how to structure an organization to support both types of people in it, but it's not an easy problem to solve. That's why there are so many project management methodologies, with new ones popping up every few years and then inevitably disappearing in favor of something new and better.
    - mr-ron 4y ago
      Im not sure why you are describing my example of PRs needing tickets to be 'heavy process'. Especially since Im pushing for engineers being able to create quick ad-hoc tickets within 30 seconds.
      - timmytokyo 4y ago
        It feels heavy to me, because you're asking for a process gate to be put in front of something that is so trivial. It feels utterly unnecessary and demotivating. If I see a minor problem in the documentation and decide to correct it, now I have to go through an extra step of creating a JIRA ticket describing the minor problem I'm trying to solve, doing the correction, updating the JIRA ticket status, and possibly monitoring the ticket for future issues. It's. all. so. bureaucratic. And sadly it will probably lead me to thinking the fix is not worth my time. Instead of trying to convince everyone that they should feel the way you do, maybe try to understand why others feel the way they do.
- azemetre 4y ago
  I disagree with it moving quickly, all it does is encourage me to not update documentation and not actively improve the code in other ways due to inane bureaucracy. And surprised surprise, no on else on the team wants to document anything either; people get burnt out because they have no autonomy and just leave. All is good tho! We followed the process and that's the only thing that matters. I wonder what the corporate equivalent to "I was just following orders" is?
  - mr-ron 4y ago
    If an engineer can create a ticket and work on it, thats not reducing autonomy. Thats adding accountability. If documentation requires a pull request / merge to update, often you have set controls that require a jira ticket. Its super common to not allow engineers to make solo commits without a pull request. If an engineer sees the creation of a jira ticket as a limitation, or if they are not empowered to create their own tickets, then Id agree its a problem.
    - carlisle_ 4y ago
      Is creating the ticket really adding value to the engineering process? In your example you already have the engineer making a PR (presumably peer reviewed) and a commit, what’s the ticket really needed for?
      - mr-ron 4y ago
        It can add value if done right. Just as you typically want to make a design doc / rfc before working on a project, you often want to describe what you are doing before you do it. This can protect the engineer / team against scope creep, as well as determine the context of why work was done when you may need to understand more context (in the case of a bug for example). Also it increases accountability and transparency. It is common that teams want to know what other engineers are working on and why.
        carlisle_ 4y ago
- RayFrankenstein 4y ago
  Cute Agilist gaslighting about not needing a ticket because that’s “asking for permission” and it’s supposed to be implicitly bundled into feature work.
- ianbutler 4y ago
  Is it? I've never needed a ticket to make off the cuff improvements. A PR and a review from other engs to make sure they agree, certainly, but a ticket for that seems like a certain degree of dev micromanagement/big brother/power trip for highly paid and skilled professionals.
  - Rapzid 4y ago
    At my previous gig we reduced the friction for doc contributions to just a PR but with no review requirement; if the contributor felt the need for feedback or review they would seek it, otherwise just merge the changes.
- sanderjd 4y ago
  That's a stupid compliance requirement, unless documentation changes aren't themselves versioned (which they should be). You don't need to track the exact same thing in two separate places.
- lupire 4y ago
  If it's so important to have a ticket, the patch submission pipeline should create one automatically.
- Too 4y ago
  ”Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds” This type of placeholder-documentation is literally the WORST type of tracking you can have. And a sign that everybody in your company forgot the reason why this type of traceability was implemented in the first place. If I review a PR that links to a Jira ticket that says absolutely nothing except “update documentation”. What’s the whole point?! What’s worse is when people see a link to a Jira as an excuse to write bad commit messages. I would much rather read a commit message detailing out the background and rationale of the change, rather than a nonsense commit message linking to another nonsense kpi-chasing Jira ticket. PRs are code reviewed anyway so it’s not like you have a bonanza of unknown changes being pushed left and right. Code reviews not only catches coding bugs but also accountability within the team, eg “why are you refactoring something that works, when our backlog has 100 other more important things to do.”

duxup 4y ago

“Jim is so productive!” -by design Jim is the only one allowed to be productive- :P

nickjj 4y ago

This is really it. There's a world of a difference in what you can do if you have free reign to make most technical decisions with full autonomy (self guided R&D, picking stuff, spiking it out, doing it for real, etc.), perhaps only reporting back weekly outcomes to a CTO and also asking their advice as needed to align on big picture goals while nothing is ever blocked. vs. Most decisions needs to go through someone else, which then turns into an adhoc request for another department which then has to ticket it out and implement things on their schedule. They could be a great team and do everything in the best way you can realistically hope for but before you know it, things that were literally 1 or 2 hours of dev time end up taking 3-4 weeks simply because they have other things going on too. You keep repeating this pattern and it's how something ends up taking 6 months instead of 2 weeks. It's also one of the most frustrating things to be blocked. It forces you to context switch between many things to keep yourself busy. You spend all of your time reacting to eventually getting unblocked in an uncontrolled way instead of just sitting down and cranking it out. That means you might have to jump back into something you worked on 2 weeks ago and re-get all of that context back in your head. I know in an Agile sense every team should be self sustained and can own their work from beginning to end but from an infrastructure perspective you may run into scenarios where you need resources created by another team because in a bigger org it's company policy. The blockers could be a combo of waiting on that other team or waiting until multiple people sign off on moving forward with XYZ tech.

altacc 4y ago

One of the reasons enterprise organisations are so slow to adapt and release new products is the number of people needed to make a decision. I've seen large companies try to implement agile and it generally fails because they can't shift to quick & effective decision making processes. Greenfield projects that get developed quickly due to independence and have great promise for the future get the hug of death as soon as management decides to bring the project into the same decision making as the rest of the org.

salmonfalls 4y ago
This is the exact case that I have been in the last two years or so. As a greenfield project being one of the first in the newly implemented Agile work. Everything was amazing in the beginnig with quick decision making. However as soon as we 'went live' and were forced into the established change control workflow development grinded to a halt. We now implement features at a snails pace compared to before.

jeffbee 4y ago

I don't think it's about largeness, and the autonomy of "rockstars" is of dubious value. Google is the largest company where I've worked, and also the most productive. For code that an IC owns, they only need the sign-off of literally anyone else in the company to land changes, and all that is expected is those changes are generally consistent with team goals. For code an IC does not own, they only need the approval of one owner. Pretty straight-forward. A medium-sized company where I worked had a "rockstar" who was really just an early employee with a high title and no idea what he was doing, so every week he committed a thousand lines of brand-new unreviewed tech debt. Much of the rest of the company was unwittingly dedicated to overcoming his tech debt. Said company currently trades at about 1/3rd below its IPO valuation. The experience of these two companies led me to the belief that hiring practices and review culture are more important than project management culture. You can get a lot done with good talent, code and design review, and vaguely disorganized project leadership, and you can run in place achieving nothing with formal project management hamstrung by bozo engineers.

carlisle_ 4y ago
> and the autonomy of "rockstars" is of dubious value. I agree, but with your example, I wouldn’t call somebody committing massive amounts of tech debt a “rock star”. I used the term fairly facetiously anyway, because I think we all know the 10x engineer is a myth.

tgv 4y ago

Such is the nature of organisations. E.g., X is the boss of a group, the group becomes a department, X hires people to manage the groups in the department, and now all these people have to be informed as well, and of course they have an opinion, too. And they are rarely good managers. Then X leaves and politics kick in because everyone covets the position, and then someone's simple task becomes the focus of someone who wants to place your manager in a bad light. And it never stops, because there's no incentive to make it stop.

rco8786 4y ago

> I t’s nice to see the simple truth called out. It’s not as though it’s a secret or anything. It’s a common point of discussion. The simple matter is that big co’s naturally have more inputs into the same types of decisions and thus need more people involved.

lifeplusplus 4y ago

In my past job, I volunteered and pushed to get the whole project, then I asked to be exempted from all scrum stuff, then got really close to PM and Designer, launched the whole thing without a single bug in 3 months and with more features than planned, and had 2 more months left. The reason there were no bugs was because any question I had, I slacked messaged PM, and got replied in less than a minute. She was on the project full time too, and was technical so was able to test out things and apis, document correct relevant data like console log errors, browser version, json response, curl ... etc. My takeaway was similar to yours but in more concrete terms: - have experts available in team which can be consulted asap - give whole projects - start with minimal project - create small informal groups, POC for each area: sr eng for legacy code, designer to get artifacts, PM to clarify tickets and address new bugs, main dev to do the whole thing - have team informally occasionally input on tech decisions.

deleted 4y ago

[deleted]

sanderjd 4y ago

Yeah this is exactly it. But I think it's a good thing. It's a tradeoff between productivity and risk. It is productive but risky for "rockstars" to make big changes with very little consensus-seeking. Big changes are double edged, they have outsize impact, but it may be either positive or negative. So organizations rationally hedge that. The trick is to strike a good balance, giving up as little productivity as possible for the greatest reduction in risk. It's hard! Sometimes the right answer is just "empower one or a few people to do whatever they think best without ever seeking any buy in from anyone else", but not often. And "never let anyone do anything without a big slow sprawling committee giving permission" is essentially never the right answer. But there is lots of space in between these extremes!

lupire 4y ago

Your 10x rockstar is my cowboy coder 0.1xing the team.

carlisle_ 4y ago
The use of the term was supposed to be illustrative and mostly facetious, hence the quotes.