3 ms·

The company I work for is Dutch (very egalitarian, consensus-based work culture), hires only people with academic degrees (love to argue), has a very flat organ

The company I work for is Dutch (very egalitarian, consensus-based work culture), hires only people with academic degrees (love to argue), has a very flat organisation (very little hierarchical power to make anyone do anything) and on top of everything else, it's a consultancy with a software development branch at heart, and the programmers are told the same thing as the consultants -- be visible, have an opinion, make it known, and so on. So this is completely typical for every single ticket and the team lead is powerless. What works is: let the team know the planning, make the whole team feel responsible for making the planning, ask this programmer to make this ticket happen, let him come to the same conclusion as you regarding the planning (argue), and then have him figure out how to solve it in half a day. He'll probably also add the private variable, or come up with a similar way. Alternatively, add the damn private variable yourself, if it's only a single line. Trying to force people to do things on a level of detail that is well within the area they want to decide themselves doesn't work. "Team lead" isn't "team boss".

fogetti 9y ago
I agree with everything you said. To summarize: the single most important thing that works is transparency. When the lead makes his decision making/planning and generic thought process transparent then he doesn't end up in an embarrassing situation when he has to argue about even the smallest technical detail. If the solutions the team lead is proposing isn't different in effect from what the dev is proposing, then why is he arguing in the first place?
le-mark 9y ago
Subtitle of the blog explains a lot: Views and insights on leading a software team through experience in military leadership and on the job experience with enterprise level software products. I've seen many, many prior military people utterly fail in the civilian work force because, guess what? You can't just bark orders and expect to get anything done. You can't belittle, berate, and batter civilians with words the way leaders are encouraged in the military. Front leaning rest postion, Move! Five zero, knock em out. Good luck being able to type at keyboard after 50 pushups.
- zeveb 9y ago
  I've seen many, many projects in the civilian workforce fail because, guess what? Not everyone gets to be CEO and CTO. Sometimes leaders are wrong, and sometimes those who should lead are tyrants, but sometimes folks need to get in line and follow. Different situations are different.
  - Scarblac 9y ago
    I've argued that in our company, at least there should be someone on a team who gets the official power to be tiebreaker, to just make a decision when some discussion of whether to walk around the park clockwise or widdershins today just keeps going on on and on... But that's just not how it works here.
    - deleted 9y ago
      [deleted]
- Scarblac 9y ago
  Of course the main reason the military needs that is because on the battlefield, people in your team keep dying and you need to stay effective with new inexperienced team members all the time. Anything more sophisticated than "follow orders or else" just fails. So if this is his way of working, maybe by now it's actually necessary for his teams...
- Toast_25 9y ago
  >> Good luck being able to type at keyboard after 50 pushups. While it does slow me down a tad, I can type fine. Not military, but AFAIK the type of leadership depends on the branch. Extreme Ownership is a book written by a navy seal with some pretty solid advice on leadership.

fogetti 9y ago

I agree with everything you said. To summarize: the single most important thing that works is transparency. When the lead makes his decision making/planning and generic thought process transparent then he doesn't end up in an embarrassing situation when he has to argue about even the smallest technical detail. If the solutions the team lead is proposing isn't different in effect from what the dev is proposing, then why is he arguing in the first place?

le-mark 9y ago

Subtitle of the blog explains a lot: Views and insights on leading a software team through experience in military leadership and on the job experience with enterprise level software products. I've seen many, many prior military people utterly fail in the civilian work force because, guess what? You can't just bark orders and expect to get anything done. You can't belittle, berate, and batter civilians with words the way leaders are encouraged in the military. Front leaning rest postion, Move! Five zero, knock em out. Good luck being able to type at keyboard after 50 pushups.

zeveb 9y ago
I've seen many, many projects in the civilian workforce fail because, guess what? Not everyone gets to be CEO and CTO. Sometimes leaders are wrong, and sometimes those who should lead are tyrants, but sometimes folks need to get in line and follow. Different situations are different.
- Scarblac 9y ago
  I've argued that in our company, at least there should be someone on a team who gets the official power to be tiebreaker, to just make a decision when some discussion of whether to walk around the park clockwise or widdershins today just keeps going on on and on... But that's just not how it works here.
  - deleted 9y ago
    [deleted]
Scarblac 9y ago
Of course the main reason the military needs that is because on the battlefield, people in your team keep dying and you need to stay effective with new inexperienced team members all the time. Anything more sophisticated than "follow orders or else" just fails. So if this is his way of working, maybe by now it's actually necessary for his teams...
Toast_25 9y ago
>> Good luck being able to type at keyboard after 50 pushups. While it does slow me down a tad, I can type fine. Not military, but AFAIK the type of leadership depends on the branch. Extreme Ownership is a book written by a navy seal with some pretty solid advice on leadership.