19 ms·

I don't know that I fully agree with this. I think in even well functioning teams you need at least one person who is empowered to make the call. In the cases o

by zaphar 10y ago

I don't know that I fully agree with this. I think in even well functioning teams you need at least one person who is empowered to make the call. In the cases of a disagreement deadlock you need someone to break the deadlock. Whether that person is a called a Tech Lead or something else you still need them and they need authority and freedom to make the call. Maybe his Mediator can be that person but if you give the Mediator the power to break these deadlocks then you need to ensure that he has enough practical experience to make sane choices. And if you have a Mediator with the authority to break a deadlock and the experience to do so with mostly correct decisions you have what most people call a Tech Lead.

posabsolute 10y ago
What I don't like about this kind of articles is the one-sided way they explain things. I would have like he investigate how the tech lead role could also be improved. I think you voiced the deadlock issue pretty well.
new_hackers 10y ago
To quote George W. Bush: "I'm the Decider" and a "decider" is definitely needed.
mnsc 10y ago
For me the person taking the mediator role doesn't need to have "enough practical experience". The role of mediator could be someone not invested in on side of the deadlock that takes it upon them to lay out the pros and cons so that the people assuming the architect role discuss from the same premises. A mediator could also identify if there are outside demands that are uncertain that causes the deadlock. Then someone in the role as concierge could reach out and clear the uncertainty which would allow the team to unite on a sane technical choice going forward (in small increments).
- zaphar 10y ago
  The risk you take on when the mediator role doesn't have practical experience is that no consensus will be reached. Or worse if that mediator is empowered to break a deadlock he'll do so badly because he doesn't have enough context to make a good decision and not enough time to come up to speed in order to make a good decision.
  - mnsc 10y ago
    My point is that the mediator shouldn't make the decision that is not in the role. If the deadlock is concerning i.e. two competing architectural decisions the mediator should help the different people with architect roles engaged in the debate to decide how to move forward. Trusting that a single Tech Lead always will have the right context to authoritatively decide the best way forward seems naive to me. Where is this magical person?
    - zaphar 10y ago
      The same place you find two people who can by consensus arrive at the best decision moving forward. The point of breaking a deadlock isn't that you choose the best choice but that you are able to make a choice which is strictly better than making no choice.
    - gohrt 10y ago
      Trusting that a pair of engineers will always come to an agreement to authoritatively decide the best way forward seems naive to me. Where are these magical people?
voidpointer 10y ago
One doesn't become a leader by just being called the lead. Some people have personal traits that make them assume a leader role more often then others. In my experience, a team that is constantly looking for one person to call all the shots isn't very much empowered. If everyone can take responsibility to own up for the calls to make, you end up with a far more engaged team. It requires a certain maturity but a motivated team should be able to grow into such a mode over a couple of weeks or month. Experts will emerge on certain topics and the team will often look to them to weight in on certain topics. That will all come pretty naturally once a team has passed its initial formation phase.
- jerf 10y ago
  "In the cases of a disagreement deadlock you need someone to break the deadlock." != "a team that is constantly looking for one person to call all the shots".
  - crdoconnor 10y ago
    "In the cases of a disagreement deadlock you need someone to break the deadlock." 97% of the time consensus driven decision making means no deadlock and the other 3% of the time you can put decisions to a vote. I've seen more value destroyed by a team lead inappropriately setting the wrong agenda than I have by team members not knowing when to shut up. If anything I've found that there's often too much consensus (people who just go with the flow rather than voicing an opinion).
    - tetrep 10y ago
      > 97% of the time consensus driven decision making means no deadlock and the other 3% of the time you can put decisions to a vote. That's now how deadlocks work. You can't just vote your way out of them, if you could, you wouldn't be in a deadlock to begin with. You'd just be at the point where a decision needs to be made. > If anything I've found that there's often too much consensus (people who just go with the flow rather than voicing an opinion). That's a separate problem. A healthy and functional team needs to be able to trust one another's opinions and provide an environment where everyone feels comfortable speaking their minds. If you don't have those the value of intrateam communication is comically low.
bryanlarsen 10y ago
A well functioning team makes all decisions by consensus, so there are no deadlocks. There are certainly disagreements, but they are hashed out in a timely fashion in well functioning teams. That doesn't mean necessarily that everybody completely agrees with everything, but it does mean that members recognize when to defer rather than stall. If you have deadlocks, it's not a well functioning team.
- vidarh 10y ago
  Great. But we live in reality where lots of teams are not well functioning some or all of the time, and we still need to get things done even when we don't have the time, resources or influence to fix the team composition then and there. EDIT: I'd also argue that in most well functioning team few decisions needs to be taken by the team, because the team members know their role well enough and trusts the others to do the same that everyone is empowered to take decisions. Unfortunately again, we live in the real world where decision making is often needed exactly because a lot of the time there are team members we can't let run rampant and make their own decisions. Or have too much influence.
  - crdoconnor 10y ago
    >Great. But we live in reality where lots of teams are not well functioning some or all of the time Managers abusing their power causes way more dysfunction than a lack of authority ever does. >Unfortunately again, we live in the real world where decision making is often needed exactly because a lot of the time there are team members we can't let run rampant and make their own decisions. That isn't what managing by consensus means. In the real world bad eggs don't "run rampant", they are reined in by peer pressure, and poor developers very often recognize that they are poor developers (except when they are designated as leaders, in which case they usually do 'run rampant').
    - vidarh 10y ago
      > In the real world bad eggs don't "run rampant", they are reined in by peer pressure, and poor developers very often recognize that they are poor developers I wish I lived in your world, but clearly we live in very different worlds.
brandall10 10y ago
I don't agree with it either. Case in point - I've been in a situation as detailed toward the end of the article where all the devs on the team were feature leads, except we still had a designated overall lead. Just 4 devs on the team, all of us were very sr (principal or sr. principal devs). But the overall number of stakeholders in the product were probably well over 30 people, so it was still a big coordination effort. It was for a fairly large legacy enterprise healthcare product ($200M per annum revenue). Each big feature had its own core team with other stakeholders in the company -- usually these meetings would be with a half dozen other people. The main core team for the overall product had about 20 members. Each feature had its own requirements/design documents (usually 30+ pages each). The main requirements/design docs would sorta be like a high-level index linking to these sub documents. It was a waterfall process of course, and once the designs were mostly there the entire team would work on all the features together. The team lead would assign what people would be working on at any given time, but beyond that the feature leads would break down and delegate the overall work based on who was working on their feature. Typically each feature would be worked on by 2 people at a time and sometimes 3. The team lead wasn't actually the strongest dev, he just had the best 'leadership skills'. He was the one our manager trusted most and generally spoke to about overall project health and deadlines. He was the one who cleared pathways with other teams/resources (ie. ensured QA was on target to line up an availability window, how many engineers they could provide, etc). I don't see any points in the article that really argue against having a designated lead, and I think it's always a weird idea that a team lead (note I don't say 'tech' lead) is seen as anything but a manager who still codes. It's not an architect, the strongest dev, etc. It's a person with a best management/leadership skills with perhaps a solid high-level grasp of the domain. In a small team/product yes it can just be just the strongest dev, naturally rising up. But in these situations I've seen usually the key is there are not too many overall stakeholders... say a team of 2-3 devs with less than 10 people involved overall.
- mighty_warrior 10y ago
  I agree with you. As a "tech lead" myself, I find my biggest jobs are fostering communication between team members and clearing roadblocks. Those roadblocks could be making a design decision, clearing up requirements, getting support from external teams, etc. When every team member is responsible for clearing their own obstacles you find a lot less work gets done and often times the same problem gets solved multiple times by multiple team members.
crdoconnor 10y ago
I don't know that I fully agree with you. I've seen some "deadlock breaking" where necessary discussions were cut short by, like, 5 or 10 minutes and the resulting "compromise" architectural decisions ended up being disastrous. I've also seen team leads set agendas and drive discussion in such a way as to bury important issues that would otherwise come out while wasting time on minutiae. In contrast I've never really seen one of these fabled technical arguments over tabs vs. spaces that lasted 4 hours and wasted everybody's time. If nothing else, sheer boredom prevents discussions from going on longer than they have to.
- jdmichal 10y ago
  A "decider" is not supposed to be a "compromiser". That's just design-by-committee with a benevolent dictator.
  - crdoconnor 10y ago
    That's typically what you get when you have a team lead who doesn't have a full view into everything that is going on (which is the norm).
Jemaclus 10y ago
Agree with this. A few days after I started, the engineering manager (the guy who hired me) quit. After that, it was kind of a clusterfuck because the CEO refused to make any real decisions because he was afraid of upsetting any of the engineers. As a result, very few decisions got made, and any deadlocks resulted in hours of frustrating and anger on both sides. I tried to put my foot down on one of the projects that I owned and essentially said, "You put me in charge of this project, and this is how I want to do it," but the "committee" overrode my decisions and the CEO didn't back me up. A terrible way to run a team. I left a few months later. So yes, I agree. Even if you don't have a manager, there must be a decision maker that has the authority and freedom to make those decisions, even if they don't directly manage the others.
- sagivo 10y ago
  Exactly same experience I had in my previous company. And main reason why it's previous...

by zaphar 10y ago

posabsolute 10y ago

What I don't like about this kind of articles is the one-sided way they explain things. I would have like he investigate how the tech lead role could also be improved. I think you voiced the deadlock issue pretty well.

new_hackers 10y ago

To quote George W. Bush: "I'm the Decider" and a "decider" is definitely needed.

mnsc 10y ago

For me the person taking the mediator role doesn't need to have "enough practical experience". The role of mediator could be someone not invested in on side of the deadlock that takes it upon them to lay out the pros and cons so that the people assuming the architect role discuss from the same premises. A mediator could also identify if there are outside demands that are uncertain that causes the deadlock. Then someone in the role as concierge could reach out and clear the uncertainty which would allow the team to unite on a sane technical choice going forward (in small increments).

zaphar 10y ago
The risk you take on when the mediator role doesn't have practical experience is that no consensus will be reached. Or worse if that mediator is empowered to break a deadlock he'll do so badly because he doesn't have enough context to make a good decision and not enough time to come up to speed in order to make a good decision.
- mnsc 10y ago
  My point is that the mediator shouldn't make the decision that is not in the role. If the deadlock is concerning i.e. two competing architectural decisions the mediator should help the different people with architect roles engaged in the debate to decide how to move forward. Trusting that a single Tech Lead always will have the right context to authoritatively decide the best way forward seems naive to me. Where is this magical person?
  - zaphar 10y ago
    The same place you find two people who can by consensus arrive at the best decision moving forward. The point of breaking a deadlock isn't that you choose the best choice but that you are able to make a choice which is strictly better than making no choice.
  - gohrt 10y ago
    Trusting that a pair of engineers will always come to an agreement to authoritatively decide the best way forward seems naive to me. Where are these magical people?

voidpointer 10y ago

One doesn't become a leader by just being called the lead. Some people have personal traits that make them assume a leader role more often then others. In my experience, a team that is constantly looking for one person to call all the shots isn't very much empowered. If everyone can take responsibility to own up for the calls to make, you end up with a far more engaged team. It requires a certain maturity but a motivated team should be able to grow into such a mode over a couple of weeks or month. Experts will emerge on certain topics and the team will often look to them to weight in on certain topics. That will all come pretty naturally once a team has passed its initial formation phase.

jerf 10y ago
"In the cases of a disagreement deadlock you need someone to break the deadlock." != "a team that is constantly looking for one person to call all the shots".
- crdoconnor 10y ago
  "In the cases of a disagreement deadlock you need someone to break the deadlock." 97% of the time consensus driven decision making means no deadlock and the other 3% of the time you can put decisions to a vote. I've seen more value destroyed by a team lead inappropriately setting the wrong agenda than I have by team members not knowing when to shut up. If anything I've found that there's often too much consensus (people who just go with the flow rather than voicing an opinion).
  - tetrep 10y ago
    > 97% of the time consensus driven decision making means no deadlock and the other 3% of the time you can put decisions to a vote. That's now how deadlocks work. You can't just vote your way out of them, if you could, you wouldn't be in a deadlock to begin with. You'd just be at the point where a decision needs to be made. > If anything I've found that there's often too much consensus (people who just go with the flow rather than voicing an opinion). That's a separate problem. A healthy and functional team needs to be able to trust one another's opinions and provide an environment where everyone feels comfortable speaking their minds. If you don't have those the value of intrateam communication is comically low.

bryanlarsen 10y ago

A well functioning team makes all decisions by consensus, so there are no deadlocks. There are certainly disagreements, but they are hashed out in a timely fashion in well functioning teams. That doesn't mean necessarily that everybody completely agrees with everything, but it does mean that members recognize when to defer rather than stall. If you have deadlocks, it's not a well functioning team.

vidarh 10y ago
Great. But we live in reality where lots of teams are not well functioning some or all of the time, and we still need to get things done even when we don't have the time, resources or influence to fix the team composition then and there. EDIT: I'd also argue that in most well functioning team few decisions needs to be taken by the team, because the team members know their role well enough and trusts the others to do the same that everyone is empowered to take decisions. Unfortunately again, we live in the real world where decision making is often needed exactly because a lot of the time there are team members we can't let run rampant and make their own decisions. Or have too much influence.
- crdoconnor 10y ago
  >Great. But we live in reality where lots of teams are not well functioning some or all of the time Managers abusing their power causes way more dysfunction than a lack of authority ever does. >Unfortunately again, we live in the real world where decision making is often needed exactly because a lot of the time there are team members we can't let run rampant and make their own decisions. That isn't what managing by consensus means. In the real world bad eggs don't "run rampant", they are reined in by peer pressure, and poor developers very often recognize that they are poor developers (except when they are designated as leaders, in which case they usually do 'run rampant').
  - vidarh 10y ago
    > In the real world bad eggs don't "run rampant", they are reined in by peer pressure, and poor developers very often recognize that they are poor developers I wish I lived in your world, but clearly we live in very different worlds.

brandall10 10y ago

I don't agree with it either. Case in point - I've been in a situation as detailed toward the end of the article where all the devs on the team were feature leads, except we still had a designated overall lead. Just 4 devs on the team, all of us were very sr (principal or sr. principal devs). But the overall number of stakeholders in the product were probably well over 30 people, so it was still a big coordination effort. It was for a fairly large legacy enterprise healthcare product ($200M per annum revenue). Each big feature had its own core team with other stakeholders in the company -- usually these meetings would be with a half dozen other people. The main core team for the overall product had about 20 members. Each feature had its own requirements/design documents (usually 30+ pages each). The main requirements/design docs would sorta be like a high-level index linking to these sub documents. It was a waterfall process of course, and once the designs were mostly there the entire team would work on all the features together. The team lead would assign what people would be working on at any given time, but beyond that the feature leads would break down and delegate the overall work based on who was working on their feature. Typically each feature would be worked on by 2 people at a time and sometimes 3. The team lead wasn't actually the strongest dev, he just had the best 'leadership skills'. He was the one our manager trusted most and generally spoke to about overall project health and deadlines. He was the one who cleared pathways with other teams/resources (ie. ensured QA was on target to line up an availability window, how many engineers they could provide, etc). I don't see any points in the article that really argue against having a designated lead, and I think it's always a weird idea that a team lead (note I don't say 'tech' lead) is seen as anything but a manager who still codes. It's not an architect, the strongest dev, etc. It's a person with a best management/leadership skills with perhaps a solid high-level grasp of the domain. In a small team/product yes it can just be just the strongest dev, naturally rising up. But in these situations I've seen usually the key is there are not too many overall stakeholders... say a team of 2-3 devs with less than 10 people involved overall.

mighty_warrior 10y ago
I agree with you. As a "tech lead" myself, I find my biggest jobs are fostering communication between team members and clearing roadblocks. Those roadblocks could be making a design decision, clearing up requirements, getting support from external teams, etc. When every team member is responsible for clearing their own obstacles you find a lot less work gets done and often times the same problem gets solved multiple times by multiple team members.

crdoconnor 10y ago

I don't know that I fully agree with you. I've seen some "deadlock breaking" where necessary discussions were cut short by, like, 5 or 10 minutes and the resulting "compromise" architectural decisions ended up being disastrous. I've also seen team leads set agendas and drive discussion in such a way as to bury important issues that would otherwise come out while wasting time on minutiae. In contrast I've never really seen one of these fabled technical arguments over tabs vs. spaces that lasted 4 hours and wasted everybody's time. If nothing else, sheer boredom prevents discussions from going on longer than they have to.

jdmichal 10y ago
A "decider" is not supposed to be a "compromiser". That's just design-by-committee with a benevolent dictator.
- crdoconnor 10y ago
  That's typically what you get when you have a team lead who doesn't have a full view into everything that is going on (which is the norm).

Jemaclus 10y ago

Agree with this. A few days after I started, the engineering manager (the guy who hired me) quit. After that, it was kind of a clusterfuck because the CEO refused to make any real decisions because he was afraid of upsetting any of the engineers. As a result, very few decisions got made, and any deadlocks resulted in hours of frustrating and anger on both sides. I tried to put my foot down on one of the projects that I owned and essentially said, "You put me in charge of this project, and this is how I want to do it," but the "committee" overrode my decisions and the CEO didn't back me up. A terrible way to run a team. I left a few months later. So yes, I agree. Even if you don't have a manager, there must be a decision maker that has the authority and freedom to make those decisions, even if they don't directly manage the others.

sagivo 10y ago
Exactly same experience I had in my previous company. And main reason why it's previous...