Dealing with insubordination(softwareteamlead.com)
softwareteamlead.com
Dealing with insubordination
https://www.softwareteamlead.com/getting-on-board-dealing-with-insubordination/
115 comments
How do we/the developer know it was “a hack”, and also “a bad idea”? The word hack isn’t used in the article.
The lead should have .. well, led .. by having a business logic reason for the inclusion of the variable. If they did and the developer still refused, then they’re in insubordination territory.
Anything else is an open conversation where humility is required on all sides.
The lead should have .. well, led .. by having a business logic reason for the inclusion of the variable. If they did and the developer still refused, then they’re in insubordination territory.
Anything else is an open conversation where humility is required on all sides.
>How do we/the developer know it was “a hack”, and also “a bad idea”? The word hack isn’t used in the article.
Well we don't for sure, but based on that paragraph I quoted, it sounded like it, especially since the author immediately mentioned ripping it out if it proved to be a bad idea in a later sprint (which doesn't happen as often as you would like in software shops with deadlines.)
>The lead should have .. well, led .. by having a business logic reason for the inclusion of the variable. If they did and the developer still refused, then they’re in insubordination territory.
I would be comfortable with that scenario.
Well we don't for sure, but based on that paragraph I quoted, it sounded like it, especially since the author immediately mentioned ripping it out if it proved to be a bad idea in a later sprint (which doesn't happen as often as you would like in software shops with deadlines.)
>The lead should have .. well, led .. by having a business logic reason for the inclusion of the variable. If they did and the developer still refused, then they’re in insubordination territory.
I would be comfortable with that scenario.
> Well we don't for sure, but based on that paragraph I quoted, it sounded like it, especially since the author immediately mentioned ripping it out if it proved to be a bad idea in a later sprint (which doesn't happen as often as you would like in software shops with deadlines.)
That’s a valid point. The article is not without flaws. Thanks for your reply!
That’s a valid point. The article is not without flaws. Thanks for your reply!
Or here's an even better solution: ask the developers for a solution, and then ask them how long it will take and why.
Then go to your supervisor (or stakeholder or whoever) and tell them your engineers said it's going to take this long because of technical reason X, Y, and Z.
Then go to your supervisor (or stakeholder or whoever) and tell them your engineers said it's going to take this long because of technical reason X, Y, and Z.
> All the lead wanted was a single private variable placed in the class and the amount of effort it took to get that accomplished was a multiple day discussion.
Sounds like the kind of environment I used to work in. Team lead would specify the exact changes he wanted to see in the code, sometimes literally attaching marked-up screenshots in JIRA.
I would typically not argue, but I left to consult independently partly due to this experience. Knowing the diff to achieve the desired effect is literally what my job is about; if you have the solution, why not go ahead and commit the changes yourself? It gave an impression that my purpose was primarily to be… a teammate, justifying that guy’s title as a team lead.
That said, I was getting paid for that work still—an hourly rate that would be generous for a glorified typist. I struggle to come up with a logical explanation of why it left such an unpleasant residue.
Sounds like the kind of environment I used to work in. Team lead would specify the exact changes he wanted to see in the code, sometimes literally attaching marked-up screenshots in JIRA.
I would typically not argue, but I left to consult independently partly due to this experience. Knowing the diff to achieve the desired effect is literally what my job is about; if you have the solution, why not go ahead and commit the changes yourself? It gave an impression that my purpose was primarily to be… a teammate, justifying that guy’s title as a team lead.
That said, I was getting paid for that work still—an hourly rate that would be generous for a glorified typist. I struggle to come up with a logical explanation of why it left such an unpleasant residue.
Probably because developers are first and foremost designers and problem solvers. Code is just a medium.
It's like an author taking a job and it ends up being as a typist. She's probably capable, but she'll be miserable, because that's not what she does.
It's like an author taking a job and it ends up being as a typist. She's probably capable, but she'll be miserable, because that's not what she does.
I've been a team lead and never had the "authority" to tell someone exactly how to write their code. I also would consider "convince me" a very appropriate response. If I fail to convince, I don't get what I want. That team member isn't insubordinate in my eyes, they are going places.
Same here. On my last team, I took it as a point of pride that the developers had no hesitation to protest my suggestions for implementation and even flat out override them. We were also the only group in the larger team who met our objectives on time without working long hours. I don't see those as unrelated.
It's a good thing when your developers come up with better solutions than you, and even better when they aren't afraid to choose them over yours.
When the manager is the most well-informed person on the team about implementation, that's when you should worry.
It's a good thing when your developers come up with better solutions than you, and even better when they aren't afraid to choose them over yours.
When the manager is the most well-informed person on the team about implementation, that's when you should worry.
> Pretty simple. Going all micromanaging dictator who forces shit hacks won't be good for your department short or medium term.
The same could be said about questioning minor requests from someone who has more experience than you do and who has a greater responsibility to deliver on deadlines. Wasting hours of time over a single line is a great way to make people dislike you for being so inflexible, especially if it’s holding up the work of others on your team.
The same could be said about questioning minor requests from someone who has more experience than you do and who has a greater responsibility to deliver on deadlines. Wasting hours of time over a single line is a great way to make people dislike you for being so inflexible, especially if it’s holding up the work of others on your team.
"questioning minor requests from someone who has more experience than you do"
I firmly believe that all authority should be questioned in the corporate environment. A good manager should have the wisdom to acknowledge that he can fail to see things that the developer did.
If you go by what Clubber proposed then:
* If the manager is right, the developer will notice the value of accepting the technical input of the manager and develop a keener sense of timing within the development process.
* If the manager is wrong, the developer will understand that he shouldn't just accept orders handed down to him and remain mindful of the impact of the changes he makes to the code because his opinion will be respected by the rest of the team.
Now the author mentioned that in his organization "There are processes in place to get things like this removed" so the issue might be more that the developer either doesn't know that the project exists or that it works. Only if it's the later and the manager is sure that refactoring is regularly performed the developer is wrong for his the insubordination.
I firmly believe that all authority should be questioned in the corporate environment. A good manager should have the wisdom to acknowledge that he can fail to see things that the developer did.
If you go by what Clubber proposed then:
* If the manager is right, the developer will notice the value of accepting the technical input of the manager and develop a keener sense of timing within the development process.
* If the manager is wrong, the developer will understand that he shouldn't just accept orders handed down to him and remain mindful of the impact of the changes he makes to the code because his opinion will be respected by the rest of the team.
Now the author mentioned that in his organization "There are processes in place to get things like this removed" so the issue might be more that the developer either doesn't know that the project exists or that it works. Only if it's the later and the manager is sure that refactoring is regularly performed the developer is wrong for his the insubordination.
I don’t disagree with you. I’ve certainly been known to push back and question things I didn’t like or agree with. I also agree with a few other comments that we’re missing a lot of context, so I’ve had to fill in with my own experience which is that A) Managing someone who questions every single decision is exhausting and leads to tension and the team being a lot less effective and B) Hacks made due to a time shortage can always be inserted into the next sprint to be resolved if it’s something important.
I do think there’s a time and place to question authority, and maybe this could have been used as a better opportunity for mentoring, but I still think being rigid isn’t great for the team.
I do think there’s a time and place to question authority, and maybe this could have been used as a better opportunity for mentoring, but I still think being rigid isn’t great for the team.
If it's bad code, it's bad code. Good developers don't like to write bad code. Any experienced, good developer has most likely worked on a shit codebase and understands 1. that it didn't happen all at once, but trickled in and 2. it's debilitating to the organization. If you force good developers to write bad code, you probably won't have good developers much longer.
If I knew more about the circumstances, I could make a better judgement, but to me it sounds like the lead wanted the developer to put in shit code and he didn't want to. The thing about shit code is it costs 2x, 10x, 100x of technical debt later. Remember the article is written from someone biased towards the lead.
If I knew more about the circumstances, I could make a better judgement, but to me it sounds like the lead wanted the developer to put in shit code and he didn't want to. The thing about shit code is it costs 2x, 10x, 100x of technical debt later. Remember the article is written from someone biased towards the lead.
Senior developers know that wasting two days fighting would be better spent elsewhere. This is an example of a midlevel programmer who can program but doesn't understand the big picture. Probably the type of person to follow one way of doing somethig and freakout on anyone who suggests something different. This developer doesn't get it... they need a few more years of seasoning.
The lead is in charge of making those decisions. Having a working feature in time for the sales demo is more important than some code purity.
They do not understand the difference between getting paid to do a task vs creating a personal hobby project.
The lead is in charge of making those decisions. Having a working feature in time for the sales demo is more important than some code purity.
They do not understand the difference between getting paid to do a task vs creating a personal hobby project.
>Senior developers know that wasting two days fighting would be better spent elsewhere.
I disagree. Sometimes, yes, but most of the time, no. Two days fighting can save years of maintenance costs (and I'm assuming productive fighting, not fighting for the sake of it). Ever developed on a not-well-thought out database model? No foreign keys? No consistent naming? Dates as varchar? You're stuck with it. It not only causes more defects in existing code, it makes enhancements harder and more prone to defects.
But it's hard to speak up on such things. It much easier, mentally, to just say screw it and write the bad code, especially if someone is non-confrontational by nature.
I disagree. Sometimes, yes, but most of the time, no. Two days fighting can save years of maintenance costs (and I'm assuming productive fighting, not fighting for the sake of it). Ever developed on a not-well-thought out database model? No foreign keys? No consistent naming? Dates as varchar? You're stuck with it. It not only causes more defects in existing code, it makes enhancements harder and more prone to defects.
But it's hard to speak up on such things. It much easier, mentally, to just say screw it and write the bad code, especially if someone is non-confrontational by nature.
You are not stuck with those things. Converting dates or adding references or changing the customer model or even migrating to a different type of database are things you would normally do when you start scaling anyways.
The code doesn't have to be perfect aligned to some doctrine.
If you feel the need to fight back over a single private member variable delay some important release the reasoning must be better than one day in the future it, it will make development slightly harder. Refactoring is a good practice.
The code doesn't have to be perfect aligned to some doctrine.
If you feel the need to fight back over a single private member variable delay some important release the reasoning must be better than one day in the future it, it will make development slightly harder. Refactoring is a good practice.
>are things you would normally do when you start scaling anyways.
It is (sometimes but rarely fundamentally different refactoring) but when a crappy schema has been built on for years, it is exponentially more difficult to refactor, especially a live system with multiple clients and uses. The best (and cheapest) medicine for that is to not inject crappy design in the first place. Sometimes you have to, but it should really taste bad.
>The code doesn't have to be perfect aligned to some doctrine.
If the doctrine is not putting crappy / hacky code in the code base if you can at all help it, I think that's a fairly standard doctrine.
>If you feel the need to fight back over a single private member variable delay some important release
I'm not sure if the article said the discussion would delay a release or that the release was important. All those absolutely do come into play though. If they were in play, you'd think the dev lead would have enough respect for his team to point that out.
It is (sometimes but rarely fundamentally different refactoring) but when a crappy schema has been built on for years, it is exponentially more difficult to refactor, especially a live system with multiple clients and uses. The best (and cheapest) medicine for that is to not inject crappy design in the first place. Sometimes you have to, but it should really taste bad.
>The code doesn't have to be perfect aligned to some doctrine.
If the doctrine is not putting crappy / hacky code in the code base if you can at all help it, I think that's a fairly standard doctrine.
>If you feel the need to fight back over a single private member variable delay some important release
I'm not sure if the article said the discussion would delay a release or that the release was important. All those absolutely do come into play though. If they were in play, you'd think the dev lead would have enough respect for his team to point that out.
> If it's bad code, it's bad code. Good developers don't like to write bad code. Any experienced, good developer has most likely worked on a shit codebase and understands 1. that it didn't happen all at once, but trickled in and 2. it's debilitating to the organization.
I’ve been on both sides, here, so I totally get the desire to write good code (and in my current role I’m working on best practices and good patterns with my team). That being said, good developers also realize that sometimes “hacks” are necessary to get something done, especially when deadlines are looming.
Who among us hasn’t written something awful to get something finished or meet a deadline?
I’ve been on both sides, here, so I totally get the desire to write good code (and in my current role I’m working on best practices and good patterns with my team). That being said, good developers also realize that sometimes “hacks” are necessary to get something done, especially when deadlines are looming.
Who among us hasn’t written something awful to get something finished or meet a deadline?
I completely agree with you and because of that, I think it would warrant some sort of discussion, which wasn't allowed here. That's my main issue.
>Good developers don't like to write bad code.
Good developers produce something. (and I'm condemning myself there)
Good developers produce something. (and I'm condemning myself there)
[deleted]
That shouldn't be necessary: he should already have included what he was trying to accomplish and why, so that if you knew the code better (likely if you worked on it) you can catch issues before they happen.
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".
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".
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.
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.
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.
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.
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]
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...
So if this is his way of working, maybe by now it's actually necessary for his teams...
>> 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.
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.
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?
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?
I've had a fair share of this crap myself being the team lead at the time. I didn't go yelling at the dev for not understanding that my contract said team lead and the CTO failed to communicate that role or giving me the opportunity to communicate it. I spoke with the CTO and asked him to clarify the roles and gave him a clear choice. He decided against clear communication and I decided to take more money elsewhere.
The problem is oftentimes not the individual being insubordinate. Oftentimes the issue is that Roles and Responsibilities are not clearly defined.
This is especially an issue when one of previous colleagues on the same level is promoted to the higher ranking position. It's an even more common issue in big corp and govt. institutions.
> Implicit tasks are not always common sense.
There is no such thing as implicit tasks. There are implicit tasks, when you sit in your garage and found a company and one guy is a marketing wiz and the other a rockstar dev. You might even have a well working symbiosis then. Everything beyond that needs to(at least some extent) be defined.
The problem is oftentimes not the individual being insubordinate. Oftentimes the issue is that Roles and Responsibilities are not clearly defined.
This is especially an issue when one of previous colleagues on the same level is promoted to the higher ranking position. It's an even more common issue in big corp and govt. institutions.
> Implicit tasks are not always common sense.
There is no such thing as implicit tasks. There are implicit tasks, when you sit in your garage and found a company and one guy is a marketing wiz and the other a rockstar dev. You might even have a well working symbiosis then. Everything beyond that needs to(at least some extent) be defined.
>The problem is oftentimes not the individual being insubordinate. Oftentimes the issue is that Roles and Responsibilities are not clearly defined.
This is entirely possible too. I just had an experience where I unwittingly cut the technical lead of my team out of an important conversation simply because I didn't realize he would care. I wanted to limit the scope of the conversation because of time constraints.
I told him to his face in a meeting that I was trying to limit the scope of the conversation. He was not very happy about that.
Needless to say, once I realized what a butthead I had been, I apologized profusely, explained that I had misunderstood the situation, and promised not to let that ever happen again. It ended up being fine after that, but boy did I feel dumb.
Point is, don't just assume that new hires will automatically infer what everyone's role is.
This is entirely possible too. I just had an experience where I unwittingly cut the technical lead of my team out of an important conversation simply because I didn't realize he would care. I wanted to limit the scope of the conversation because of time constraints.
I told him to his face in a meeting that I was trying to limit the scope of the conversation. He was not very happy about that.
Needless to say, once I realized what a butthead I had been, I apologized profusely, explained that I had misunderstood the situation, and promised not to let that ever happen again. It ended up being fine after that, but boy did I feel dumb.
Point is, don't just assume that new hires will automatically infer what everyone's role is.
> Lead: This is not a choice. I am telling you to do this.
> Teammate: You need to convince me.
I think the teammate's at least half right on this one. Nobody does anything without wanting to do it. If you want somebody to do something, you do need to convince them. If they'll do it just because you say they have to, they're still probably harbouring some resentment about it, which won't work out well in the long term anyway.
At least this guy was big enough to stand up for what he believed in.
> Just write the less than 80 characters line to add the variable and move on.
If it's so easy, why didn't the lead just do it himself instead of making a problem out of it?
> Teammate: You need to convince me.
I think the teammate's at least half right on this one. Nobody does anything without wanting to do it. If you want somebody to do something, you do need to convince them. If they'll do it just because you say they have to, they're still probably harbouring some resentment about it, which won't work out well in the long term anyway.
At least this guy was big enough to stand up for what he believed in.
> Just write the less than 80 characters line to add the variable and move on.
If it's so easy, why didn't the lead just do it himself instead of making a problem out of it?
>> If it's so easy, why didn't the lead just do it himself instead of making a problem out of it?
I was thinking the exact same thing. It's old school thinking that the leader should be respected just because there are the leader. Back then the most aggressive person would get to be the leader...
You can't make someone else do something just for the sake of reminding them who's the boss - That's sick and it's psychologically damaging to the other person.
If the leader cannot convince team members to do things then that person should not be a leader. There is always a way to make someone do what you want them to do but if you're the kind of leader who never yields and never compromises then others will behave the same towards you and they will probably be right.
I was thinking the exact same thing. It's old school thinking that the leader should be respected just because there are the leader. Back then the most aggressive person would get to be the leader...
You can't make someone else do something just for the sake of reminding them who's the boss - That's sick and it's psychologically damaging to the other person.
If the leader cannot convince team members to do things then that person should not be a leader. There is always a way to make someone do what you want them to do but if you're the kind of leader who never yields and never compromises then others will behave the same towards you and they will probably be right.
> If you want somebody to do something, you do need to convince them. If they'll do it just because you say they have to, they're still probably harbouring some resentment about it, which won't work out well in the long term anyway.
Pushing back on such a small thing feels so rigid and short-sighted. You can always change the code in another sprint, but if your resistance over a single line change is holding up everyone else’s reviews/pull requests and deliverables it’s pretty selfish to be so inflexible. Sometimes you just need to trust that you’re being asked to do something by someone with more experience (technical or otherwise) for a good reason and let it go, especially if it’s something relatively minor.
> If it’s so easy, why didn’t the lead just do it himself instead of making a problem out of it?
Because that’s not his job? Do you think he should set a precedent of just doing the teammate’s work every time he pushes back? If that’s the case, why have the teammate around in the first place?
Pushing back on such a small thing feels so rigid and short-sighted. You can always change the code in another sprint, but if your resistance over a single line change is holding up everyone else’s reviews/pull requests and deliverables it’s pretty selfish to be so inflexible. Sometimes you just need to trust that you’re being asked to do something by someone with more experience (technical or otherwise) for a good reason and let it go, especially if it’s something relatively minor.
> If it’s so easy, why didn’t the lead just do it himself instead of making a problem out of it?
Because that’s not his job? Do you think he should set a precedent of just doing the teammate’s work every time he pushes back? If that’s the case, why have the teammate around in the first place?
> Do you think he should set a precedent of just doing the teammate’s work every time he pushes back?
When the lead start to think in terms of precedents, it is a red sign, you'd better find another job. When maintaining authority becomes more important to the lead than the work done, it means that hierarchy psychological mechanisms took over his rational thinking, and it is really bad.
When the lead start to think in terms of precedents, it is a red sign, you'd better find another job. When maintaining authority becomes more important to the lead than the work done, it means that hierarchy psychological mechanisms took over his rational thinking, and it is really bad.
For me it’s not so much about maintaining authority as it is about not letting the people who you’re trying to lead walk all over you anytime they disagree or push back.
How does just doing someone’s work for them indicate any kind of effective leadership? What lesson or mentoring does that provide?
How does just doing someone’s work for them indicate any kind of effective leadership? What lesson or mentoring does that provide?
> For me it’s not so much about maintaining authority as it is about not letting the people who you’re trying to lead walk all over you anytime they disagree or push back.
How not letting the people to walk over you is not maintaining authority? It is pure hierarchy game. "Who is more dominant male here?" Even if you are Buddha and can control your mind perfectly, separating lower instincts from rationality, then dude you are speaking to is not Buddha (most probably), and he would interpret situation as pure hierarchy game.
> How does just doing someone’s work for them indicate any kind of effective leadership?
When we see disobedient teammate we already know that leadership is ineffective. The only question remains: can the leadership become effective in the future.
> What lesson or mentoring does that provide?
It is generally good idea to reach several goals by one move. But not every time. If you cannot simultaneously reach work goals and education ones, then you can split goals and reach them in more then one move.
There is not much sense in trying to push while conflict is at its peak. Emotions get over mind on both sides. Possibly time is pressing and it is not the good idea to start discussion right now.
Later the lead can find time to speak about incident, with all its aftermaths, including him doing work for other (It gives the lead real power on conversations, like "Unprecedented! Due to your stubborness I has to do your job. Should I take your salary also?"). It should be time when the cause of conflict is in the past, when there are plenty of time to talk the past conflict through, when emotions not the present reality but tool in hands of the lead. And one more: when no one around except disobedient team member and the lead to exclude influence of social group effects on both.
At that moment the lead can calmly and purposefully explore his disobedient teammate motives and let teammate to understand the lead. Ether they will find mutual understanding, or not. In the latter case the lead would have all the reasons to fire employee who does not understand what team work is. In the former case conflict would be solved once and for ever, and there would be no need to repeat it again and again, which is real threat to authority of the team leader.
In contrast pushing conflict at its peak just to settle authority of the lead is not constructive. Disobedient teammate will learn nothing except his leader is a authoritarian headstrong dominant male, even if it is not so. The only consequence will be increased chance of successive conflicts with this teammate. It is simplier to fire him right now, than to wait for sequel.
Alternatively he will learn that his opinion is not needed, and will become silent obedient and non-creative worker. A kind of dump machine to type on keyboard. But if this is the goal of the lead, he'd better find another employee. Breaking human by force can be loud and unpleasant for the whole team.
There are no possible happy endings if the lead values authority above all and does not use his creativity to work with people.
How not letting the people to walk over you is not maintaining authority? It is pure hierarchy game. "Who is more dominant male here?" Even if you are Buddha and can control your mind perfectly, separating lower instincts from rationality, then dude you are speaking to is not Buddha (most probably), and he would interpret situation as pure hierarchy game.
> How does just doing someone’s work for them indicate any kind of effective leadership?
When we see disobedient teammate we already know that leadership is ineffective. The only question remains: can the leadership become effective in the future.
> What lesson or mentoring does that provide?
It is generally good idea to reach several goals by one move. But not every time. If you cannot simultaneously reach work goals and education ones, then you can split goals and reach them in more then one move.
There is not much sense in trying to push while conflict is at its peak. Emotions get over mind on both sides. Possibly time is pressing and it is not the good idea to start discussion right now.
Later the lead can find time to speak about incident, with all its aftermaths, including him doing work for other (It gives the lead real power on conversations, like "Unprecedented! Due to your stubborness I has to do your job. Should I take your salary also?"). It should be time when the cause of conflict is in the past, when there are plenty of time to talk the past conflict through, when emotions not the present reality but tool in hands of the lead. And one more: when no one around except disobedient team member and the lead to exclude influence of social group effects on both.
At that moment the lead can calmly and purposefully explore his disobedient teammate motives and let teammate to understand the lead. Ether they will find mutual understanding, or not. In the latter case the lead would have all the reasons to fire employee who does not understand what team work is. In the former case conflict would be solved once and for ever, and there would be no need to repeat it again and again, which is real threat to authority of the team leader.
In contrast pushing conflict at its peak just to settle authority of the lead is not constructive. Disobedient teammate will learn nothing except his leader is a authoritarian headstrong dominant male, even if it is not so. The only consequence will be increased chance of successive conflicts with this teammate. It is simplier to fire him right now, than to wait for sequel.
Alternatively he will learn that his opinion is not needed, and will become silent obedient and non-creative worker. A kind of dump machine to type on keyboard. But if this is the goal of the lead, he'd better find another employee. Breaking human by force can be loud and unpleasant for the whole team.
There are no possible happy endings if the lead values authority above all and does not use his creativity to work with people.
I disagree. Team leads are chosen for a reason and when they clearly ask for a task, it needs to be done without the wasted effort of having to convince them.
> If it's so easy, why didn't the lead just do it himself instead of making a problem out of it?
It's called delegation. If there are 15 easy tasks, a team lead can delegate them out using his or her judgement and have them completed quicker than doing it themselves. If each of those easy tasks has to go through a "convincing phase" it's no longer worth it.
> If it's so easy, why didn't the lead just do it himself instead of making a problem out of it?
It's called delegation. If there are 15 easy tasks, a team lead can delegate them out using his or her judgement and have them completed quicker than doing it themselves. If each of those easy tasks has to go through a "convincing phase" it's no longer worth it.
But delegation involves handing over some subset of your responsibility to someone and trusting them to do it. That includes letting them decide what the best way to get it done is.
Once you're telling people what to do in terms of single lines of code, that's not delegation anymore, there is no trust.
Once you're telling people what to do in terms of single lines of code, that's not delegation anymore, there is no trust.
A lead that squanders an opportunity to mentor isn't much of a lead.
I didn't say that one shouldn't mentor or receive feedback. I actually think if you disagree with the team lead you should let them know and then let them make the decision.
If they hear your opinion and still go a different way, that's fine - roll with it. It shouldn't require every individual on the team to be convinced, that's a massive waste of time.
If they hear your opinion and still go a different way, that's fine - roll with it. It shouldn't require every individual on the team to be convinced, that's a massive waste of time.
Telling others what to do is not delegation. Delegation means to give others the freedom to make their own decisions.
Convincing a colleague of why a particular direction is a good thing to do is never a waste of time.
> If they'll do it just because you say they have to, they're still probably harbouring some resentment about it, which won't work out well in the long term anyway.
Right, because in that case, you've convinced them they have to do it or they'll be fired. Either way they'll be convinced of something!
Right, because in that case, you've convinced them they have to do it or they'll be fired. Either way they'll be convinced of something!
The TL is ultimately responsible for delivering the product. With the accountability comes the right to not have to go through hours long discussions to convince an engineer.
if i could convince people to do things, i would be selling amway, not leading a software team.
> If it's so easy, why didn't the lead just do it himself instead of making a problem out of it?
Interestingly, I had a similarly simplistic solution in the other direction: if the schedule is so tight, why is this person who adds time needed? Take them off the team and, if there isn't anything else for them to do, let them go. They're insubordinate, and egalitarian as I am, this person is obviously not a good fit for a tight schedule.
(I expect if the team lead added it the other person might well try to remove it.)
Interestingly, I had a similarly simplistic solution in the other direction: if the schedule is so tight, why is this person who adds time needed? Take them off the team and, if there isn't anything else for them to do, let them go. They're insubordinate, and egalitarian as I am, this person is obviously not a good fit for a tight schedule.
(I expect if the team lead added it the other person might well try to remove it.)
There's a lot wrong with this situation. Without knowing the person involved it's hard to say if they have an attitude problem, but it sounds like the team lead does.
>>Who is right? No one is right, but the lead has the authority to expect tasks to be accomplished when asked and has the responsibility of delivering the release on time.
There is something wrong when one has to defer to their authority to get things done. In this case it's even stated that there is no correct answer, so why does the lead need to have it their way?
There's also the small problem of what was asked. It's hard for me to believe that adding a private variable is actually implementing a product feature. This smells badly of telling someone HOW to do their job rather than WHAT you want.
And finally there is context. Sometimes when it comes to time pressure a phrase comes to mind "a lack of planning on your part does not constitute an emergency on my part." It would obviously be stupid to say that, but in some cases it's the right attitude to have. It's not at all clear from this piece what the overall context is, what the actual feature is, or which person is being unreasonable.
I'm actually leaning toward the author as the problem. This need to blog about a petty dispute over a variable declaration suggests that maybe the person not obeying orders could be pushing back against a larger problem.
TL;DR there's really not enough here to tell who the problem is, or if there is really much of a problem at all.
>>Who is right? No one is right, but the lead has the authority to expect tasks to be accomplished when asked and has the responsibility of delivering the release on time.
There is something wrong when one has to defer to their authority to get things done. In this case it's even stated that there is no correct answer, so why does the lead need to have it their way?
There's also the small problem of what was asked. It's hard for me to believe that adding a private variable is actually implementing a product feature. This smells badly of telling someone HOW to do their job rather than WHAT you want.
And finally there is context. Sometimes when it comes to time pressure a phrase comes to mind "a lack of planning on your part does not constitute an emergency on my part." It would obviously be stupid to say that, but in some cases it's the right attitude to have. It's not at all clear from this piece what the overall context is, what the actual feature is, or which person is being unreasonable.
I'm actually leaning toward the author as the problem. This need to blog about a petty dispute over a variable declaration suggests that maybe the person not obeying orders could be pushing back against a larger problem.
TL;DR there's really not enough here to tell who the problem is, or if there is really much of a problem at all.
[deleted]
This is weird. Author wants me to agree, that I have to unconditionally submit to someone because of their title. No ifs or buts, just do as you're told. I worked with people who loved to manage like this and in every single case when they asked for a wrong thing it was later developer's fault that he did something (it's his name on the commit after all). On the flip side every competent, cooperative manager I've worked with had no issue with people not wanting to do something. But yeah, YMMV. Perhaps in some bizarre world "I command you to do X" is the civilized way to talk to other people.
> I worked with people who loved to manage like this and in every single case when they asked for a wrong thing it was later developer's fault that he did something (it's his name on the commit after all).
So log your protest and the command in the commit message too.
So log your protest and the command in the commit message too.
Telling people "I demand that you do it" or even "do it, or else" is a symptom of a greater problem with said person. I don't see how waging battles with this type of lead in commit messages is going to help me.
> I don't see how waging battles with this type of lead in commit messages is going to help me.
What a weird way to phrase it. The problem as stated is that the developer gets the blame because his name is on the commit message. If you document that you were specifically instructed to implement this commit, then that solves the problem.
What a weird way to phrase it. The problem as stated is that the developer gets the blame because his name is on the commit message. If you document that you were specifically instructed to implement this commit, then that solves the problem.
Something about using the word 'insubordination' and linking to a dictionary definition that defines it as "not submitting to authority" and [being] "disobedient" really rubs me the wrong way.
Authority etc. are implied of course, in a team structure where there is a lead (and others are not), but if you told me to "obey your authority" in so many words, I would have a problem complying very easily.
Authority etc. are implied of course, in a team structure where there is a lead (and others are not), but if you told me to "obey your authority" in so many words, I would have a problem complying very easily.
I would say right now, good developers have more of an authority parity with business than any type of employee has ever had, based on scarcity and necessity. Hope it lasts.
Exactly. It is like that quote from game of thrones: If you have to tell the world you are the king, you aren't.
[deleted]
Wasn't entirely sure if this was a sincere post, or some sort of unfunny burlesque of some kind. Assuming it's sincere, then the author of this blog post couldn't be more wrong about how to manage a software team. If a manager-type started going full-on micromanagement on me ("add a private var to this class now! rawr!"), bandies about the term 'insubordiation', and generally believes they're entitled to my unthinking obedience, then congrats: you've successfully convinced me to start floating my resume so I can get the hell out of that shitshow. I'm an educated, experienced software engineer with multiple degrees and life's too short to put up with that bullshit.
Well said.
The whole situation sounds ridiculous and the advice given is just awful.
A "team lead" should not be informing developers on the implementation details of their ticket. The developer had every right to protest.
> If the individual is not a fit, then move him to another team that might have a different control style.
This is so backwards I don't even know where to begin. It sounds like the advice is to break up a team just to show the developers "who's boss." I would never want to work for this person. They put their own ego and control freak issues over the stability and productivity of the team.
Also, it's a super weaselly move that instead of just going to the developer in person and raising your concerns with him like a reasonable human, they used their corporate clout to bypass the issue and move him to another team. Is that acting like a leader?
A "team lead" should not be informing developers on the implementation details of their ticket. The developer had every right to protest.
> If the individual is not a fit, then move him to another team that might have a different control style.
This is so backwards I don't even know where to begin. It sounds like the advice is to break up a team just to show the developers "who's boss." I would never want to work for this person. They put their own ego and control freak issues over the stability and productivity of the team.
Also, it's a super weaselly move that instead of just going to the developer in person and raising your concerns with him like a reasonable human, they used their corporate clout to bypass the issue and move him to another team. Is that acting like a leader?
> Lead: This is not a choice. I am telling you to do this.
> Teammate: You need to convince me.
I've reached the point in a discussion with a subordinate where I've had to say "this is not a choice" multiple times in my 30-year management career. Only twice has the person absolutely refused and only one of those times was this part of the reason the person ended up being fired.
I'm amazed at how many times these kinds of ultimatums come down to some strange, abstract principle: "I won't pollute my code with a global setting, instead you're going to delay the release a couple of weeks while I re-write the code and we re-QA everything." No, that's not what is happening.
At some point, it is my job to make the call. If you think it is your job to make the call, you should find a job where it is your job to make the call.
I assuming, of course, your lead is not asking you to do something immoral or illegal. Since I've been on the other end of that before.
I've reached the point in a discussion with a subordinate where I've had to say "this is not a choice" multiple times in my 30-year management career. Only twice has the person absolutely refused and only one of those times was this part of the reason the person ended up being fired.
I'm amazed at how many times these kinds of ultimatums come down to some strange, abstract principle: "I won't pollute my code with a global setting, instead you're going to delay the release a couple of weeks while I re-write the code and we re-QA everything." No, that's not what is happening.
At some point, it is my job to make the call. If you think it is your job to make the call, you should find a job where it is your job to make the call.
I assuming, of course, your lead is not asking you to do something immoral or illegal. Since I've been on the other end of that before.
When you have a team member being abrasive and insubordinate, sometimes that's just their personality.
But sometimes it's not. Is there something about your culture that isn't allowing them to make any of their own decisions, and they grasp for and fight to the death to defend every little piece of autonomy they can get?
Disregarding whether the disagreeable team member is right or not - it's entirely possible that when this happens, it is a symptom of bad management, and not the fault of the employee.
But sometimes it's not. Is there something about your culture that isn't allowing them to make any of their own decisions, and they grasp for and fight to the death to defend every little piece of autonomy they can get?
Disregarding whether the disagreeable team member is right or not - it's entirely possible that when this happens, it is a symptom of bad management, and not the fault of the employee.
A team is not a fiefdom. Using "authority" to handle conflicts likely won't lead to good results. Different people need different guidance, and overall management seems poor at dealing with people.
Also: "[implementing] a private variable in a class" is not a "task". A diff should be a single idea (i.e. have a purpose on its own). Adding unused code with no purpose just makes it likely that code will stay dead forever. In codebases I work in, an unused variable would be a lint error and that code could never ship.
> If you are iterating and being “agile”, then you can remove it later realizing your mistake, and if you code it right, then it will not be intertwined into code so deep that is causes a delay.
It seems like the author hasn't worked with a large code base before. With a constant pressure to ship, dead code can sit around in your repo for a long while--and often good engineering initiatives aren't incentivized as much as they should.
Also: "[implementing] a private variable in a class" is not a "task". A diff should be a single idea (i.e. have a purpose on its own). Adding unused code with no purpose just makes it likely that code will stay dead forever. In codebases I work in, an unused variable would be a lint error and that code could never ship.
> If you are iterating and being “agile”, then you can remove it later realizing your mistake, and if you code it right, then it will not be intertwined into code so deep that is causes a delay.
It seems like the author hasn't worked with a large code base before. With a constant pressure to ship, dead code can sit around in your repo for a long while--and often good engineering initiatives aren't incentivized as much as they should.
> Also: "[implementing] a private variable in a class" is not a "task".
Haven't sit on very many task breakdown meetings, have you?
Haven't sit on very many task breakdown meetings, have you?
> This is the short version of how the conversation, but suffice it to say that the teammate decided he was in control and wanted the team lead to convince why he should implement a private variable in a class.
The teammate decided they're an adult. And looking at the "military" tag I'm not convinced the blog post author is.
> He isn’t a bad worker, but the relationship between the leadership style and his work style are clashing
The relationship are clashing? At this point, I'm really only interested in the view point of the person who so far didn't even get to speak, because the person talking about them I heard enough from.
The teammate decided they're an adult. And looking at the "military" tag I'm not convinced the blog post author is.
> He isn’t a bad worker, but the relationship between the leadership style and his work style are clashing
The relationship are clashing? At this point, I'm really only interested in the view point of the person who so far didn't even get to speak, because the person talking about them I heard enough from.
If the change is really so minor then it sounds like the employee is reacting against micromanagement.
What kind of agency are you expected to have if minor things like private variables are considered insubordination to authority? And then why would anyone want to continue working under a regime like that?
The manager, presumably being more senior, should have the maturity to know when to choose their battles.
I typically only intervene when I can see major architectural hurdles coming up, but I often see my colleagues fighting these stupid battles as managers and it's infuriating.
What kind of agency are you expected to have if minor things like private variables are considered insubordination to authority? And then why would anyone want to continue working under a regime like that?
The manager, presumably being more senior, should have the maturity to know when to choose their battles.
I typically only intervene when I can see major architectural hurdles coming up, but I often see my colleagues fighting these stupid battles as managers and it's infuriating.
Views and insights on leading a software team through experience in military leadership and on the job experience with enterprise level software products
Okay...
Does this guy have any articles on software bootcamp where drill sergeants scream at you to break you?
Okay...
Does this guy have any articles on software bootcamp where drill sergeants scream at you to break you?
Many people in this comment thread are assuming that a team lead has more experience, or he is more talented then the devs.
I am sorry folks, but this is not how it works. In many companies the earlier you arrive, the better chance you have to become the team lead.
Also nepotism is absolutely widespread in the IT industry. People just simply assign tasks to people who they TRUST. And no-one can tell me that trust can be quantified, because it cannot be.
Having said that I am not arguing that these things would be inherently wrong, it all depends how the team lead handles it's responsibility. If he has talent, he will make the team collaborate and get everyone involved.
If he is just a random guy assigned to a team for whatever reason and he is an anti-talent then he will try to micromanage the shit out of everything and everyone and will simply induce stress, burn-out and discontent.
Also it's a completely different point, but many people are assuming a "chain of command", "subordination" and mindless self-abasement. But the thing is that the dev only has to do as much as commanded by his contract/by the law. If the contract is unclear, then well, the onus is on the employer to make a better contract. So there are many unknowns in this story. But in any case, implying or expecting something without communicating it towards the dev is just simply unethical, unprofessional and lame.
Some other commenters also pointed out that if roles and responsibilities are not clearly defined, then that's gonna cause problems. I fully agree with this. And it's happening more often that not that companies hire people using a generic form which basically outlines the companies rights in detail but it doesn't say a single word about the employee's supervisors, expected skills and tasks or his responsibilities.
And as I argued in another comment below, transparency solves many of the problems which are raising from the failures I mentioned here. It just happens to be more popular to be exclusive, restrictive, restraining and secretive in management circles which is the exact opposite of being professional in my book.
I am sorry folks, but this is not how it works. In many companies the earlier you arrive, the better chance you have to become the team lead.
Also nepotism is absolutely widespread in the IT industry. People just simply assign tasks to people who they TRUST. And no-one can tell me that trust can be quantified, because it cannot be.
Having said that I am not arguing that these things would be inherently wrong, it all depends how the team lead handles it's responsibility. If he has talent, he will make the team collaborate and get everyone involved.
If he is just a random guy assigned to a team for whatever reason and he is an anti-talent then he will try to micromanage the shit out of everything and everyone and will simply induce stress, burn-out and discontent.
Also it's a completely different point, but many people are assuming a "chain of command", "subordination" and mindless self-abasement. But the thing is that the dev only has to do as much as commanded by his contract/by the law. If the contract is unclear, then well, the onus is on the employer to make a better contract. So there are many unknowns in this story. But in any case, implying or expecting something without communicating it towards the dev is just simply unethical, unprofessional and lame.
Some other commenters also pointed out that if roles and responsibilities are not clearly defined, then that's gonna cause problems. I fully agree with this. And it's happening more often that not that companies hire people using a generic form which basically outlines the companies rights in detail but it doesn't say a single word about the employee's supervisors, expected skills and tasks or his responsibilities.
And as I argued in another comment below, transparency solves many of the problems which are raising from the failures I mentioned here. It just happens to be more popular to be exclusive, restrictive, restraining and secretive in management circles which is the exact opposite of being professional in my book.
This is the first time I've encountered the term "BLUF". Turns out, it's the equivalent of TLDR - "Bottom Line Up Front".
This sounds like a missed opportunity to coach rather than fix.
What if the lead had discussed the business objective and problem and then asked the developers to come up with a time bounded solution?
My guess: one of two things would have happened - the team would have arrived at a better solution or they would have found the same need for the original proposal. Either way everyone comes away feeling empowered and productive.
What if the lead had discussed the business objective and problem and then asked the developers to come up with a time bounded solution?
My guess: one of two things would have happened - the team would have arrived at a better solution or they would have found the same need for the original proposal. Either way everyone comes away feeling empowered and productive.
Sounds like you should try really hard to:
1) Not hire someone that is going to argue about every single decision
2) Fire them if you get to the case of 1.
I have worked with quite a few "arguers" in my day. They all made good points. I am sure they were often right. But when it was 1v5 on the team for a particular decision, and our scrum master was making us having meetings for hours to resolve a stylistic difference that only 1 person agreed with.. blah. I cannot think of a better way to kill morale of an otherwise good team.
Sure in an ideal world, the team would work together and make decisions. If it's not working and one guy is sticking out over and over.. it's time to cut your losses. I have never seen a construction crew where one bricklayer would refuse to lay bricks a certain way, because he read a blog that another way is better. Sometimes you just need to put your head down and do the task, not make an argument about it.
1) Not hire someone that is going to argue about every single decision
2) Fire them if you get to the case of 1.
I have worked with quite a few "arguers" in my day. They all made good points. I am sure they were often right. But when it was 1v5 on the team for a particular decision, and our scrum master was making us having meetings for hours to resolve a stylistic difference that only 1 person agreed with.. blah. I cannot think of a better way to kill morale of an otherwise good team.
Sure in an ideal world, the team would work together and make decisions. If it's not working and one guy is sticking out over and over.. it's time to cut your losses. I have never seen a construction crew where one bricklayer would refuse to lay bricks a certain way, because he read a blog that another way is better. Sometimes you just need to put your head down and do the task, not make an argument about it.
> scrum master
Your development process is based on micro management...
> hours to resolve a stylistic difference
so it's not surprising that there are debates about the one thing the devs have control over.
Your development process is based on micro management...
> hours to resolve a stylistic difference
so it's not surprising that there are debates about the one thing the devs have control over.
Ya right, which is why I don't think in my own company I could ever see hiring a scrum master. I get the point in theory, and I have met a bunch of really great guys... but the process is just too much for my taste.
In the military, leaders are taught to explain their guidance to subordinates whenever possible. But sometimes, a Soldier needs to just be quiet and roll out. Yes, this does require a Soldier to trust his leadership. It also requires them to be a professional. It is not your job as a subordinate to mentor/develop your supervisor. It is that team lead's supervisor. If I were treated this way, that subordinate would lose some of his paycheck or be forced to work many extra hours performing menial tasks.
Far more importantly, I would have lost respect for that individual. It's one thing to ask for clarification (which is awesome), it's another to convey blatant disrespect and unprofessionalism. No matter the circumstance or poor leadership, you do not demean yourself like that.
Far more importantly, I would have lost respect for that individual. It's one thing to ask for clarification (which is awesome), it's another to convey blatant disrespect and unprofessionalism. No matter the circumstance or poor leadership, you do not demean yourself like that.
The US military has boot camp to psychologically break its trainees down and build them back up closer to ideal (not to mention the inherent impressionability of youth). Furthermore, it leverages painfully binding enlistment terms and the UCMJ hammer. Civilians who work for the US military aren't beholden to any of this, and they also have the unique difficulty of culling incompatibly after a civilian in competitive service has gotten past a brief probationary period, let alone if a union is involved; observe the author suggests removing the individual from the team (i.e. not firing) and approaching the lead's supervisor as a last resort...this is not coincidence.
The categorical feel good smoke blowing that brass are so aptly known for leaves a lingering odor that can be smelled from a mile away by competent individuals. Comparatively speaking, military leadership is a cake walk, and even the uninspirational get a PCS reset every few years.
Already under-compensated, civilians with STEM backgrounds tend not to play the insignificant cog game, and surely not when a team lead barks I this, that, or the other.
The categorical feel good smoke blowing that brass are so aptly known for leaves a lingering odor that can be smelled from a mile away by competent individuals. Comparatively speaking, military leadership is a cake walk, and even the uninspirational get a PCS reset every few years.
Already under-compensated, civilians with STEM backgrounds tend not to play the insignificant cog game, and surely not when a team lead barks I this, that, or the other.
People here seem to fundamentally misunderstand authority.
They seem to think it is something that you "use", rather than something that you have - specifically, the property of morally obligating someone to do something.
Hence the silly statements like: "I believe all authority should be questioned" - which is, of course, absurd.
Questioning authority simply means there is no - and cannot be any - authority.
Which is different from questioning someone's authority - whether that someone really has or has not the authority on a specific concrete situation.
They seem to think it is something that you "use", rather than something that you have - specifically, the property of morally obligating someone to do something.
Hence the silly statements like: "I believe all authority should be questioned" - which is, of course, absurd.
Questioning authority simply means there is no - and cannot be any - authority.
Which is different from questioning someone's authority - whether that someone really has or has not the authority on a specific concrete situation.
This isn't the military.
Thank you for the in-depth analysis buddy. It's a great how you addressed the underlying point of the comment.
Lol you sound like a shit boss/manager.
perhaps this is why some people think it's "just fine" to undercut someone's authority while giving no mind to their responsibility.
Really depends on how exactly was it said.
Option one: team member says "I think this is a bad decision". Should lead to a productive discussion, decision in the end taken by team leader. A person who cares about quality of a product and can argue for his point of view is a valuable team member.
Option two: team member says "I won't do it no matter what do you say because I don't respect your authority as a lead". Get it in writing, get paperwork done on termination due to insubordination (or whatever it's called in your country), so that every potential employer sees the red flag next time. A person who doesn't accept his role in a team and doesn't respect contract he signed (which usually specify chain of command) shouldn't work in the industry.
Option one: team member says "I think this is a bad decision". Should lead to a productive discussion, decision in the end taken by team leader. A person who cares about quality of a product and can argue for his point of view is a valuable team member.
Option two: team member says "I won't do it no matter what do you say because I don't respect your authority as a lead". Get it in writing, get paperwork done on termination due to insubordination (or whatever it's called in your country), so that every potential employer sees the red flag next time. A person who doesn't accept his role in a team and doesn't respect contract he signed (which usually specify chain of command) shouldn't work in the industry.
So, every bad team lead results in permanent blackballing of everybody they piss off? That's a dystopian nightmare.
If a team leader pisses you off and you think that they are inherently incompetent, you can tell it to his boss, and if it doesn't work, ask for a transfer to another team or resign. Telling him "I don't recognize your authority" is a really bad way to react to such a situation.
People are human. These humans deserve better than draconian blackballing because it offends somebody.
Just telling that I worked in a few different countries and none of my contracts have ever specified anything like the "chain of command". Maybe it's common in the US, I don't know, but in those countries where I worked this was not the case.
Worked in Russia and Israel, both had exactly this. But isn't something like this implied anyway? I would be surprised.
Something tells me the other side of the story (told by the dev) would sound very different.
> Lead: I need you to implement “X”.
> Teammate: No.
> Lead: This is not a choice. I am telling you to do this.
> Teammate: You need to convince me.
There will be times, even as a junior team member when you strongly disagree with a decision. I have always felt that there is a virtually unlimited supply of people out there who can implement what they're told to implement, but that if I wanted to justify the salary I wanted it was my obligation to share my expertise by pushing back against what I saw as bad architectural decisions.
Early in my career, this didn't work out so well for me :)
I think I've figured it out by this point. There is a balance to be struck between "you're the boss" and "I don't think this is the right path" - and that balance differs from person to person. There are some key factors that remain constant:
1. It's not personal. I'm careful not to imply that something is wrong with the person who made the decision, merely that I disagree with the decision. If it feels like egos are getting involved - including my own! - I drop it
2. Organizational structure exists for a reason. I'm very explicit in acknowledging that I will perform the task as given to the best of my abilities if that's what is asked of me.
3. Keep it private. Challenging your team lead in a meeting with a half-dozen other developers is a Bad Idea.
Basically, I don't think it's too much to ask that your leadership treat your professional opinions with respect. If you are working in an environment where the above seems impossible to you... you should change your environment.
There will be times, even as a junior team member when you strongly disagree with a decision. I have always felt that there is a virtually unlimited supply of people out there who can implement what they're told to implement, but that if I wanted to justify the salary I wanted it was my obligation to share my expertise by pushing back against what I saw as bad architectural decisions.
Early in my career, this didn't work out so well for me :)
I think I've figured it out by this point. There is a balance to be struck between "you're the boss" and "I don't think this is the right path" - and that balance differs from person to person. There are some key factors that remain constant:
1. It's not personal. I'm careful not to imply that something is wrong with the person who made the decision, merely that I disagree with the decision. If it feels like egos are getting involved - including my own! - I drop it
2. Organizational structure exists for a reason. I'm very explicit in acknowledging that I will perform the task as given to the best of my abilities if that's what is asked of me.
3. Keep it private. Challenging your team lead in a meeting with a half-dozen other developers is a Bad Idea.
Basically, I don't think it's too much to ask that your leadership treat your professional opinions with respect. If you are working in an environment where the above seems impossible to you... you should change your environment.
The author is giving us zero contextual information. That is a red flag in and of itself.
The variable is a proxy for a deeper issue which the author is purposefully withholding.
The variable is a proxy for a deeper issue which the author is purposefully withholding.
Key question: how are you going to handle things when you know you're right but the team/lead votes the other way?
Some folks, once they know what is right, will never do anything but that. Avoid these people. Some folks are so apathetic they agree to anything. Avoid these people too.
There's an old phrase "Strong opinions, lightly held". Have good and powerful reasons for the viewpoints you own. Defend them -- at length if necessary -- and passionately argue the merits of your view.
But at the same time, get a grip. Your job as a professional is to both have strong opinions about quality and to be able to dance to whatever song is playing. At some point, sure, the environment could be so bad that you should take a walk instead of staying and putting up with it. That's one of the values they hired you for. But whether or not to have a private variable is not that point.
ADD: I think this is just as important, more important, actually for leads and managers as it is for workers. We model the behavior we want to see. If you're hard-headed and have a take-no-prisoners attitude, or if you're apathetic and jaded? Your reports see that. They copy it.
Some folks, once they know what is right, will never do anything but that. Avoid these people. Some folks are so apathetic they agree to anything. Avoid these people too.
There's an old phrase "Strong opinions, lightly held". Have good and powerful reasons for the viewpoints you own. Defend them -- at length if necessary -- and passionately argue the merits of your view.
But at the same time, get a grip. Your job as a professional is to both have strong opinions about quality and to be able to dance to whatever song is playing. At some point, sure, the environment could be so bad that you should take a walk instead of staying and putting up with it. That's one of the values they hired you for. But whether or not to have a private variable is not that point.
ADD: I think this is just as important, more important, actually for leads and managers as it is for workers. We model the behavior we want to see. If you're hard-headed and have a take-no-prisoners attitude, or if you're apathetic and jaded? Your reports see that. They copy it.
> Your job as a professional is to both have strong opinions about quality and to be able to dance to whatever song is playing.
Yeah, this is really key. I have some very strong opinions about quality processes in software development. My employer and my team lead are paying for my expertise and advice, and I give it to them. But at the end of the day, if they want to pursue what I believe is an unwise course, I have a decision: follow, or resign. A professional doesn't spend his time sniping & griping: he knuckles down and produces — or he leaves.
We can't all be special snowflakes.
Yeah, this is really key. I have some very strong opinions about quality processes in software development. My employer and my team lead are paying for my expertise and advice, and I give it to them. But at the end of the day, if they want to pursue what I believe is an unwise course, I have a decision: follow, or resign. A professional doesn't spend his time sniping & griping: he knuckles down and produces — or he leaves.
We can't all be special snowflakes.
As the author of the post. Just a couple comments...
1) I am referencing a team lead not myself. 2) I still agree that no one was right or wrong in this situation, and it had the right intentions to stir up discussion to see what people thought about it. 3) If you have reference to other posts that I have put on my site than you will see that as a leader you have to surround yourself with people who are better in certain or all verticals than you.
Check out this post (https://www.softwareteamlead.com/lead-by-example-characteris...) on the characteristics I strive to exemplify.
1) I am referencing a team lead not myself. 2) I still agree that no one was right or wrong in this situation, and it had the right intentions to stir up discussion to see what people thought about it. 3) If you have reference to other posts that I have put on my site than you will see that as a leader you have to surround yourself with people who are better in certain or all verticals than you.
Check out this post (https://www.softwareteamlead.com/lead-by-example-characteris...) on the characteristics I strive to exemplify.
[deleted]
I am reminded of this: http://edw519.posthaven.com/it-takes-6-days-to-change-1-line...
But I also have the thought that in the military, the person issuing orders is also responsible for things if they go wrong. If his orders are bad, he takes the fall for them. I wonder if that is the case here. Or is it a case of "Do as you are told, and then take the fall when it breaks our system."
If so, you have deeper problems than one guy saying "Nope. No can do."
But I also have the thought that in the military, the person issuing orders is also responsible for things if they go wrong. If his orders are bad, he takes the fall for them. I wonder if that is the case here. Or is it a case of "Do as you are told, and then take the fall when it breaks our system."
If so, you have deeper problems than one guy saying "Nope. No can do."
From the article:
> He isn’t a bad worker, but the relationship between the leadership style and his work style are clashing.
If refusing to take orders doesn't make you a bad worker, then what does?
I've carried out orders that I didn't agree with many times. Disagreeing with your boss respectfully is a bit of an art, especially when the person who is likely to suffer from a bad decision is yourself. But at the end of the day, this is why we call it work instead of play.
One strategy that seems to work is: be diligent, get things done well and on time, and gain the trust and respect of your team and managers. People will listen to you more when they stop suspecting you of shirking work or just being argumentative. Instead of arguments, you can have conversations and sometimes you might even prevail.
> He isn’t a bad worker, but the relationship between the leadership style and his work style are clashing.
If refusing to take orders doesn't make you a bad worker, then what does?
I've carried out orders that I didn't agree with many times. Disagreeing with your boss respectfully is a bit of an art, especially when the person who is likely to suffer from a bad decision is yourself. But at the end of the day, this is why we call it work instead of play.
One strategy that seems to work is: be diligent, get things done well and on time, and gain the trust and respect of your team and managers. People will listen to you more when they stop suspecting you of shirking work or just being argumentative. Instead of arguments, you can have conversations and sometimes you might even prevail.
It depends if you want "yes" men, or people to disagree with you. It might sting sometimes, but people who are willing to argue with you are much more beneficial to the organization for the most part. (I accept that some people just like to argue for the sake of personal satisfaction, I'm assuming this isn't the case here).
Remember, they aren't making widgets, they are engineering software; it's a high knowledge, high skill task.
Remember, they aren't making widgets, they are engineering software; it's a high knowledge, high skill task.
>It might sting sometimes, but people who are willing to argue with you are much more beneficial to the organization for the most part.
>The thing about shit code is it costs 2x, 10x, 100x of technical debt later.
I'm on board with all those things, but bear in mind the insubordinate guy is alleged to just think it's 'bloat', not that he thought it would undermine the whole architecture of the code (and it's easy to imagine 1 additional class variable not doing so). Bloat is often a problem of autists.
>The thing about shit code is it costs 2x, 10x, 100x of technical debt later.
I'm on board with all those things, but bear in mind the insubordinate guy is alleged to just think it's 'bloat', not that he thought it would undermine the whole architecture of the code (and it's easy to imagine 1 additional class variable not doing so). Bloat is often a problem of autists.
Yes, that's a good point. The facts are scarce and it's hard to tell what's going on, so I can only make assumptions. I'm making assumptions based on my experience. If I bother to speak up about something, I think it's worth talking up about. Could it be the guy was just being a prick? Absolutely.
> It depends if you want "yes" men, or people to disagree with you.
having an opinion and outright insubordination are two entirely different things. the former is fine, while the latter is toxic and destructive.
> Remember, they aren't making widgets, they are engineering software; it's a high knowledge, high skill task.
honestly, this mostly applies to areas that have advanced requirements. a lot of programming is not particularly "high knowledge, high skill", from business process stuff to web development.
having an opinion and outright insubordination are two entirely different things. the former is fine, while the latter is toxic and destructive.
> Remember, they aren't making widgets, they are engineering software; it's a high knowledge, high skill task.
honestly, this mostly applies to areas that have advanced requirements. a lot of programming is not particularly "high knowledge, high skill", from business process stuff to web development.
I had a chairman of a company scream that if we did all not do exactly as he said, he would consider it insubordination. I found another job, then sent him a private message to go fack himself.
> Lead: This is not a choice. I am telling you to do this.
> Teammate: You need to convince me.
Lead: If you don't do it, you will be fired and replaced with someone who will. Convinced yet?
> Teammate: You need to convince me.
Lead: If you don't do it, you will be fired and replaced with someone who will. Convinced yet?
When you have to threaten someone on your team, you've reached rock-bottom as a manager; all you're really accomplishing is convincing your team to leave for greener pastures.
I would be convinced, if I was leads boss, to consider firing him. If you can only run a team by steam rolling people, then I can hire much cheaper people to steam roll.
i would be convinced, if i was the lead's boss' boss, to consider firing him. if they refuse to support those upon whom they place responsibility, it's unlikely you can trust and rely on their support of you.
Based on this explanation the lead wanted a quick hack put into the code and the developer didn't want to write it (probably because it was a bad idea).
So here's how you solve that. Get the developer to find a solution to whatever the problem the hack was solving. Give him a deadline. "If you feel this strongly about it, find a solution by tomorrow morning, or we need to put this hack in for this push."
Pretty simple. Going all micromanaging dictator who forces shit hacks won't be good for your department short or medium term.