Dealing with insubordination
softwareteamlead.com
softwareteamlead.com
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.
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.
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.
That’s a valid point. The article is not without flaws. Thanks for your reply!
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.
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.
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 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.
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.
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 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 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.
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.
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.
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.
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.
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?
Good developers produce something. (and I'm condemning myself there)
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".
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.
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.
So if this is his way of working, maybe by now it's actually necessary for his teams...
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.
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?
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.
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.
> 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?
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.
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?
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.
How does just doing someone’s work for them indicate any kind of effective leadership? What lesson or mentoring does that provide?
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.
> 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.
Once you're telling people what to do in terms of single lines of code, that's not delegation anymore, there is no trust.
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.
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!
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.)
>>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.
So log your protest and the command in the commit message too.
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.
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.
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?
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.
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.
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.
Haven't sit on very many task breakdown meetings, have you?
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.
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.
Okay...
Does this guy have any articles on software bootcamp where drill sergeants scream at you to break you?
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.
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.
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.
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.
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 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.
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.
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.
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 variable is a proxy for a deeper issue which the author is purposefully withholding.
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.
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.
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.
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."
> 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.
Remember, they aren't making widgets, they are engineering software; it's a high knowledge, high skill task.
>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.
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.
> 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?