4 ms·

I manage a team that do what could broadly be described as data science, here is one thing I feel unsure about and I'd like others' opinion on: How much should

by ppod 8y ago

I manage a team that do what could broadly be described as data science, here is one thing I feel unsure about and I'd like others' opinion on: How much should I tell my team about what's going on above me? If my manager tells me about a customer meeting where they request a demo with certain broad requirements by a certain deadline. Should I go into the details of the overall business goal of the client and the exact deadline for the final demo? Or should I just delegate specific subtasks and keep the information structure within my team somewhat modular/encapsualted?

ansy 8y ago
IMO the manager’s job is never to subtask. That’s micromanagement. If you set a clear context for the team they will be best able to deliver the results you want. I’d go so far to say they can’t deliver the results you want without clear context. You may have recently been a successful individual contributor at your company. So it may seem like you know more than your employees about how to do the work. But even in this scenario you need to let go and realize your job is completely different now. You have had a tech lobotomy and are now a manger. A different species with no expectations of expertise.
iaresee 8y ago
I have, over the years, gravitated towards telling everyone in my teams as much as I possibly can at all times. I use top-down information sharing like your scenarios as a chance to connect my teams (which tend to be infrastructure and futher from the core business) to the business and their needs. Any system of information sharing that requires me to remember what and with whom I shared specific bits of compartmentalized information is ultimately doomed to fail. You'll forget who knows what and eventually screw up and then you look like a manipulative middle-manager for withholding information. Unless there's a clear reason not to share (layoffs, acquisitions, etc.), I share.
- ro_sharp 8y ago
  Amen. Work without context is demoralising and can lead to micro decisions that don't align with the macro context of the business you're in.
  - mk89 8y ago
    But if you don't share context you can always blame it on the fact that there was a misunderstanding or that you had so much to do, that you couldn't blablabla. And who is gonna challenge a manager and say that it's his job to prevent misunderstandings by sharing information? The blame game is a great asset when you need to hide incompetence and you are afraid of judgement.
    - Aeolun 8y ago
      Nobody will be able to officialy blame you, but everyone will hate you privately. If you thrive in such an environment, more power to you.
mistrial9 8y ago
this is part of your personal style IMO; like sales, there is not one single answer.. work with your strengths, and incorporate that into your team. One thing to add to that is -- burnout, cognitive overload, and the "attention economy" are real.. you are playing a team position, so your part may be to reduce those things, not increase them, for others
balls187 8y ago
My experience is that many people want to know you will answer any question they ask transparently transparently, but prefer less mettings, and don't need or want you to go into too much detail. I've always erred on the side of over sharing emphasizing the link the work the team is being asked to do with the business goals/company objectives. My internal metric was to always ensure that my leaders and direct reports all heard company news from me, before they heard it from the rumor mill.
JamesBarney 8y ago
>How much should I tell my team about what's going on above me? I think everything you reasonable can. It will allow your developers to decide how to spend their time most effectively. Ex. You tell a developer to build out a certain demo screen. Even given the same specs there is a huge difference between "this screen will be shown to the other companies CEO and could be the cornerstone of a multi-million dollar deal" and "yeah we promised to deliver this screen in the deml, but now we dont think it's important. We're pretty much only building it because we promised.". Not to mention there is going to be lots of new information that your subordinate will learn over the course of solving a problem. And if he knows everything you know he'll know what information is new and which you already knew. But if he doesn't know what you know or assume it can lead to all types of messes. "I thought you knew this was going to be a 3 week change, and would break backwards compatibility"
maxxxxx 8y ago
From my experience the best managers are very open and tell people who want to know pretty much everything. But in general I would recommend to treat people individually. Some people just want to get their tasks and then do them whereas others are curious about the bigger picture. Most good managers have the people skills to recognize what people want and need.
ska 8y ago
You are hitting on one of the difficult things to balance. One of your roles is to act as an information filter in both directions - but this is more often done too conservatively rather than too liberally. My advice would be: - if the information is providing context on current work, or information that will affect the teams tasks/deadlines/etc. share it as soon as you can - if the information is of the "might happen in the future" variety don't share it until it's concrete. Vague concerns that aren't actionable don't help anyone, and will stress some people out. - it's trickier with things that are less clear cut (e.g. this other team/division is having a real problem but nobody knows what to do about it yet.). In this case I would lean toward sharing the positive things and holding on the negative ones while they are still uncertain. - it's also very dependent on the person. Some people want to know a lot more details to be comfortable than others. One size fits all probably won't work that well. Does the team feel comfortable about approaching you for more detail? Finally a question - how are you "managing up" for this team? To use your example, if your manager tells you about a customer meeting with a deliverable and date that will involve your team, how are you making sure the team has meaningful input on scoping that deliverable?
Aeolun 8y ago
In general, more knowledge is better. They can do with the knowledge as they see fit. There’s absolutely people that won’t give a flying fuck and just continue working as they always have, but you’ll also find people that take some initiative based on the information you have provided them.
underwater 8y ago
You should work to understand all the noise and data that is being directed at the team and turn into something useful for individual team members. If you merely pass information through then you will be overloading or confusing people, because often extracting the signal from the noise is a full time job (your job!). You can't expect someone to do this effectively as well as their own role. The information you should share is strategic direction, priorities, and background information about things that might affect the team. Then you connect your team members to the people they need access to do their jobs; if you're trying to act as a go-between you're just adding latency and noise to the process. In your example your team member needs to know how important the project relative to their other work, what your expectations are around timing or effort, and then to be connected to a stakeholder who can fill them in on the details.

by ppod 8y ago

ansy 8y ago

IMO the manager’s job is never to subtask. That’s micromanagement. If you set a clear context for the team they will be best able to deliver the results you want. I’d go so far to say they can’t deliver the results you want without clear context. You may have recently been a successful individual contributor at your company. So it may seem like you know more than your employees about how to do the work. But even in this scenario you need to let go and realize your job is completely different now. You have had a tech lobotomy and are now a manger. A different species with no expectations of expertise.

iaresee 8y ago

I have, over the years, gravitated towards telling everyone in my teams as much as I possibly can at all times. I use top-down information sharing like your scenarios as a chance to connect my teams (which tend to be infrastructure and futher from the core business) to the business and their needs. Any system of information sharing that requires me to remember what and with whom I shared specific bits of compartmentalized information is ultimately doomed to fail. You'll forget who knows what and eventually screw up and then you look like a manipulative middle-manager for withholding information. Unless there's a clear reason not to share (layoffs, acquisitions, etc.), I share.

ro_sharp 8y ago
Amen. Work without context is demoralising and can lead to micro decisions that don't align with the macro context of the business you're in.
- mk89 8y ago
  But if you don't share context you can always blame it on the fact that there was a misunderstanding or that you had so much to do, that you couldn't blablabla. And who is gonna challenge a manager and say that it's his job to prevent misunderstandings by sharing information? The blame game is a great asset when you need to hide incompetence and you are afraid of judgement.
  - Aeolun 8y ago
    Nobody will be able to officialy blame you, but everyone will hate you privately. If you thrive in such an environment, more power to you.

mistrial9 8y ago

this is part of your personal style IMO; like sales, there is not one single answer.. work with your strengths, and incorporate that into your team. One thing to add to that is -- burnout, cognitive overload, and the "attention economy" are real.. you are playing a team position, so your part may be to reduce those things, not increase them, for others

balls187 8y ago

My experience is that many people want to know you will answer any question they ask transparently transparently, but prefer less mettings, and don't need or want you to go into too much detail. I've always erred on the side of over sharing emphasizing the link the work the team is being asked to do with the business goals/company objectives. My internal metric was to always ensure that my leaders and direct reports all heard company news from me, before they heard it from the rumor mill.

JamesBarney 8y ago

>How much should I tell my team about what's going on above me? I think everything you reasonable can. It will allow your developers to decide how to spend their time most effectively. Ex. You tell a developer to build out a certain demo screen. Even given the same specs there is a huge difference between "this screen will be shown to the other companies CEO and could be the cornerstone of a multi-million dollar deal" and "yeah we promised to deliver this screen in the deml, but now we dont think it's important. We're pretty much only building it because we promised.". Not to mention there is going to be lots of new information that your subordinate will learn over the course of solving a problem. And if he knows everything you know he'll know what information is new and which you already knew. But if he doesn't know what you know or assume it can lead to all types of messes. "I thought you knew this was going to be a 3 week change, and would break backwards compatibility"

maxxxxx 8y ago

From my experience the best managers are very open and tell people who want to know pretty much everything. But in general I would recommend to treat people individually. Some people just want to get their tasks and then do them whereas others are curious about the bigger picture. Most good managers have the people skills to recognize what people want and need.

ska 8y ago

You are hitting on one of the difficult things to balance. One of your roles is to act as an information filter in both directions - but this is more often done too conservatively rather than too liberally. My advice would be: - if the information is providing context on current work, or information that will affect the teams tasks/deadlines/etc. share it as soon as you can - if the information is of the "might happen in the future" variety don't share it until it's concrete. Vague concerns that aren't actionable don't help anyone, and will stress some people out. - it's trickier with things that are less clear cut (e.g. this other team/division is having a real problem but nobody knows what to do about it yet.). In this case I would lean toward sharing the positive things and holding on the negative ones while they are still uncertain. - it's also very dependent on the person. Some people want to know a lot more details to be comfortable than others. One size fits all probably won't work that well. Does the team feel comfortable about approaching you for more detail? Finally a question - how are you "managing up" for this team? To use your example, if your manager tells you about a customer meeting with a deliverable and date that will involve your team, how are you making sure the team has meaningful input on scoping that deliverable?

Aeolun 8y ago

In general, more knowledge is better. They can do with the knowledge as they see fit. There’s absolutely people that won’t give a flying fuck and just continue working as they always have, but you’ll also find people that take some initiative based on the information you have provided them.

underwater 8y ago

You should work to understand all the noise and data that is being directed at the team and turn into something useful for individual team members. If you merely pass information through then you will be overloading or confusing people, because often extracting the signal from the noise is a full time job (your job!). You can't expect someone to do this effectively as well as their own role. The information you should share is strategic direction, priorities, and background information about things that might affect the team. Then you connect your team members to the people they need access to do their jobs; if you're trying to act as a go-between you're just adding latency and noise to the process. In your example your team member needs to know how important the project relative to their other work, what your expectations are around timing or effort, and then to be connected to a stakeholder who can fill them in on the details.