Conflict in Functional Teams
-
jim.riedemann (10/13/2016)
That's too bad to hear, Rod. I think it comes down to what kind of conflict the team uses - are they debating to find the best answer, or are they arguing to get things "their way".Exactly. The first is healthy. The second is toxic.
-
jim.riedemann (10/13/2016)
That's too bad to hear, Rod. I think it comes down to what kind of conflict the team uses - are they debating to find the best answer, or are they arguing to get things "their way".Unfortunately, it's the latter in the couple of cases I'm having at work. The problem is that the folks doing that are managers that just stop the conversation and tell us "like it is". Fortunately, the environment isn't toxic if you let them have their way... but that's not the right way.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Intro to Tally Tables and Functions -
Jeff Moden (10/17/2016)
jim.riedemann (10/13/2016)
That's too bad to hear, Rod. I think it comes down to what kind of conflict the team uses - are they debating to find the best answer, or are they arguing to get things "their way".Unfortunately, it's the latter in the couple of cases I'm having at work. The problem is that the folks doing that are managers that just stop the conversation and tell us "like it is". Fortunately, the environment isn't toxic if you let them have their way... but that's not the right way.
Without the ability to actually listen and the willingness to compromise, conflict on the tam just tears it apart.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again? -
Heated debates are healthy.
Cold arguments are not.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
-
Shamefully, in the past I think that I have on occasion pushed a decision. Always wrong.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
-
"Conflict" is one of those words that can be misconstrued so easily.
Technically a disagreement is a conflict but it's using a strong word where a quieter word will do.
In the five dysfunctions of teams the dysfunctions were
1. Avoiding the issue
2. Not being open and honest about the issues
3. Not challenging poor performance of team members
4. Not supporting a position you all signed up to
5. Not putting the team first
If you can't reach a compromise then it means that you feel so strongly about an issue that you are unable to give ground. To break the log jam a manager may have to step in and make the call. If the call is against your preferred position then you have to decide whether the situation is so intolerable that you should look for another position. If you force yourself to live with an intolerable position you'll end up with sepsis of the soul and a nervous breakdown.
I used to worry that I would have to justify decisions made by more senior people for which I was allegedly accountable but had no power to influence. Every day was a living hell and I eventually cracked.
Now I realise that some ideas may be bad but they are fashionable and no-one wants to hear that their inflatable dart boards have some serious drawbacks. Sometimes you just have to let people find things out for themselves.
I know that the obsession with schema on read creates huge problems for the many consumers of data in favour of the few writers of data. I know that schema on read is useful in specific scenarios, not for everything. Schema on read solutions are currently on the Gartner hype cycle. If could make myself ill worrying about it but instead I'm waiting for the "trough of despond" phase in the cycle.
-
David.Poole (10/22/2016)
5. Not putting the team first.Actually, I slightly disagree with this. I feel conflict happens a lot because people are putting the team first over the business. We all work for the business, we don't work for ourselves. Countless times, I've seen people put their own careers and their teams first over doing what's right for the business. This is bad.
Unfortunately, when you talk about topics like that, many understand that as you as a employee are not important to the business. That you have to give everything to the business to where it burns you out. That's not the meaning here. It just means we always have to be thinking about the business TOO. At some point, you will have to make decisions that are hard for you and your team too, but it's the right decision for the business.
For example, I've ran into issues where certain technologies were not considered because it could mean not using a technology favored by majority of the team. This leads team members to have concerns of their value on the team, concerns with new challenges and even concerns with the future of role with the business. When we treat all problems as nails and certain technologies as the hammer that can fix all, we sometimes lose sight of what's best for the business because we are only thinking about ourselves or the teams value. (i.e.: instead of using SQL Server to fix this problem, let's use this X solution instead!)
-
Sorry... removed double post...
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Intro to Tally Tables and Functions -
xsevensinzx (10/23/2016)
David.Poole (10/22/2016)
5. Not putting the team first.Actually, I slightly disagree with this. I feel conflict happens a lot because people are putting the team first over the business. We all work for the business, we don't work for ourselves. Countless times, I've seen people put their own careers and their teams first over doing what's right for the business. This is bad.
Unfortunately, when you talk about topics like that, many understand that as you as a employee are not important to the business. That you have to give everything to the business to where it burns you out. That's not the meaning here. It just means we always have to be thinking about the business TOO. At some point, you will have to make decisions that are hard for you and your team too, but it's the right decision for the business.
For example, I've ran into issues where certain technologies were not considered because it could mean not using a technology favored by majority of the team. This leads team members to have concerns of their value on the team, concerns with new challenges and even concerns with the future of role with the business. When we treat all problems as nails and certain technologies as the hammer that can fix all, we sometimes lose sight of what's best for the business because we are only thinking about ourselves or the teams value. (i.e.: instead of using SQL Server to fix this problem, let's use this X solution instead!)
I agree. A lot of people thik there is no "I" in "TEAM" when, in fact, good teams are filled with people that have individual ideas and frequently have untapped skills to offer. The following graphic is one of my favorites...
One of the things that I have the least respect for are managers that play the "god" card just because they have some personal belief. For example, I've run into managers that refuse to let anyone even experiment with T-SQL solutions for many different things just because of the tired, old, and seriously incorrect mantra of "Just because you can do something in T-SQL, doesn't mean you should." Talk about poisoning a team.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Intro to Tally Tables and Functions -
xsevensinzx (10/23/2016)
David.Poole (10/22/2016)
5. Not putting the team first.Actually, I slightly disagree with this. I feel conflict happens a lot because people are putting the team first over the business. We all work for the business, we don't work for ourselves. Countless times, I've seen people put their own careers and their teams first over doing what's right for the business. This is bad.
Unfortunately, when you talk about topics like that, many understand that as you as a employee are not important to the business. That you have to give everything to the business to where it burns you out. That's not the meaning here. It just means we always have to be thinking about the business TOO. At some point, you will have to make decisions that are hard for you and your team too, but it's the right decision for the business.
For example, I've ran into issues where certain technologies were not considered because it could mean not using a technology favored by majority of the team. This leads team members to have concerns of their value on the team, concerns with new challenges and even concerns with the future of role with the business. When we treat all problems as nails and certain technologies as the hammer that can fix all, we sometimes lose sight of what's best for the business because we are only thinking about ourselves or the teams value. (i.e.: instead of using SQL Server to fix this problem, let's use this X solution instead!)
There is no I and there is no Y in the team. there is only Treat Everyone As Myself
😎
-
Eirikur Eiriksson (10/23/2016)
xsevensinzx (10/23/2016)
David.Poole (10/22/2016)
5. Not putting the team first.Actually, I slightly disagree with this. I feel conflict happens a lot because people are putting the team first over the business. We all work for the business, we don't work for ourselves. Countless times, I've seen people put their own careers and their teams first over doing what's right for the business. This is bad.
Unfortunately, when you talk about topics like that, many understand that as you as a employee are not important to the business. That you have to give everything to the business to where it burns you out. That's not the meaning here. It just means we always have to be thinking about the business TOO. At some point, you will have to make decisions that are hard for you and your team too, but it's the right decision for the business.
For example, I've ran into issues where certain technologies were not considered because it could mean not using a technology favored by majority of the team. This leads team members to have concerns of their value on the team, concerns with new challenges and even concerns with the future of role with the business. When we treat all problems as nails and certain technologies as the hammer that can fix all, we sometimes lose sight of what's best for the business because we are only thinking about ourselves or the teams value. (i.e.: instead of using SQL Server to fix this problem, let's use this X solution instead!)
There is no I and there is no Y in the team. there is only Treat Everyone As Myself
😎
Sounds communistic. The team needs to treat people well and needs to understand that the "Y"s that occur are the basis of innovation.
Even you practice innovation. Asking "Y" led you to a better post-2012 solution for DelimitedSplit8K that allowed it to run twice as fast. Would you like to be on a team that suppressed such individual thought and innovation?
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Intro to Tally Tables and Functions -
The "team" is a fractal. Yes it means those in charge of the product but it also means that product is part of a wider team.
In terms of managers playing the "God" card sometimes they have to. There isn't a clear consensus or even a majority view as to a course of action.
A course of action has to take place within an allotted time scale therefore a decision has to be made. The best you can hope to do is consider the facts you have available, weigh up the pros and cons and make the decision. Often the worst decision is no decision.
There are always people who are wise after the event or who said "I knew all along that it wouldn't work". There are also those who inject a climate of fear around decision making. Frankly I'd like to tell them all to get lost. They weren't in the hot seat and show no enthusiasm for stepping up to it. If they actually did "know all along" then they either kept it to themselves or didn't present their case in a compelling form. They probably had one piece of the puzzle and didn't have visibility of the other myriad issues that played a part in the decision process. It's an easy life for someone to sit back and criticise without actually sticking there own neck out.
As managers we make the best decisions we can based on the information we have available to us attempting to balance a wide range of concerns that often extend beyond IT. Do we get it wrong? You bet! I'd be amazed if anyone gets it right more than 65% of the time, but we also have to accept the risk and responsibility of those decisions.
-
David.Poole (10/23/2016)
The "team" is a fractal. Yes it means those in charge of the product but it also means that product is part of a wider team.In terms of managers playing the "God" card sometimes they have to. There isn't a clear consensus or even a majority view as to a course of action.
A course of action has to take place within an allotted time scale therefore a decision has to be made. The best you can hope to do is consider the facts you have available, weigh up the pros and cons and make the decision. Often the worst decision is no decision.
There are always people who are wise after the event or who said "I knew all along that it wouldn't work". There are also those who inject a climate of fear around decision making. Frankly I'd like to tell them all to get lost. They weren't in the hot seat and show no enthusiasm for stepping up to it. If they actually did "know all along" then they either kept it to themselves or didn't present their case in a compelling form. They probably had one piece of the puzzle and didn't have visibility of the other myriad issues that played a part in the decision process. It's an easy life for someone to sit back and criticise without actually sticking there own neck out.
[font="Arial Black"]As managers we make the best decisions we can based on the information we have available [/font]to us attempting to balance a wide range of concerns that often extend beyond IT. Do we get it wrong? You bet! I'd be amazed if anyone gets it right more than 65% of the time, but we also have to accept the risk and responsibility of those decisions.
That's the problem with a lot of managers. While I agree that there are, in fact, deadlines to hit and product to ship, just flat out saying "No" with no other reason other than "I don't believe that SQL Server should be used in that manner" is astigmatic at best and may actually be causing the company to not be as good as it can be. And, no... this isn't hind sight speaking here. This idiocy is going on right now. I've proven a much better way to do things and yet the manager refuses to use the methods based on the idiotic mantra that I previously mentioned.
If you want to see how fast a horse can run, sometimes you have to stop pulling back on the reins. 😉
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Intro to Tally Tables and Functions -
Jeff, I feel your pain. I wish I could buy you a pint and share some war stories.
I've been having thoughts about schema-on-read systems. See what you think.
The writing of data incurs financial cost. An app writes data once.
It is the reading of data has the potential to generate revenue.
As data can be read many times having data in a format that can be read efficiently maximizes the opportunities to generate revenue.
Because data can be read many times without being consumed its potential for generating ROI is limited only by the imagination.
All data professionals know that a poorly defined data model lacking in constraints will result in bad data and poor referential integrity. Protestations that "the app will handle DRI" are optimistic.
Schema-on-read solutions makes it really easy for an app to write data at extreme velocities because there is no schema enforcement of any kind other that what the app supports. Few use cases require the extreme data ingestion speeds that schema-on-read systems allow. Overuse of schema-on-read systems sacrifices data quality, data integrity and data usability in favour of an illusory advantage given to the once only write activity. They represent a save once, pay many times scenario.
-
It's always difficult, but I also take a single decision style with my team as well. This can sometimes lead to the GOD complex others have experienced with certain leaders of teams.
I personally take that approach because I want to ensure that if my team fails, it's not because of them, but because of myself. I took all fo their great ideas and it was my decision to choose the direction we did. It's my responsibility to bear when we are not successful, not theirs in the long run.
I also do this to shield them from the politics of the bigger organization. I'm trying to be Captain America and shield them from all the nonesense that they don't need in their work. Let me deal with it, focus on the direction we set forth and thrive.
However, the trick is, and what most fail at is the successes. When we fail, I have to stand up. When we succeed and win, I have to sit down and let the team shine. I take absolutely no credit for the decisions I make. The team ultimately suggested them, I just got lucky and helped select the right ones based on that teamwork and they came through. The only credit I'm allowed to take is building and cultivating the team and that's it.
Likewise, I have to be clear on what I do. Being unclear and being motivated by ego or selfishness is what you speak of the most Jeff. That type of stuff doesn't just kill teams, it kills organizations because as I said before, it's not about the business, it's about that single persons own ambitions or self worth or something else that is not part of the business objectives that leads to success.
Viewing 15 posts - 16 through 30 (of 31 total)
You must be logged in to reply to this topic. Login to reply