Am I right to consider workload when new good ideas are suggested by my team?

Question

Sometimes people in my team (including a Mr. Know-It-All, as he is often leading the revolutionary charge) come up with some really good ideas or valid criticism.

If they require very little time and I think they will add value without affecting the rest, I say go ahead and do that, great job!

However, putting them into action would require drastic changes to the daily work plan or weekly schedule, and sometimes may stir conflict with upper management strategy.

My immediate concern as soon as they enthusiastically advertise their plans is that with our current workload (which is borderline with burned out!), considering or even suggesting those ideas to upper management sometimes carries the risk of stretching the team and force us to work until late night just to evaluate whether we should try out that idea.

We are usually expected to work a little bit late if we need to meet our daily objectives, but formulating new ones means being exhausted and stressed the next day.

What would you do in a situation like this?

Am I right to dismiss or postpone ideas based on workload schedule priorities?

Addition by OP:

REPLY/EDIT: Thank you for all the elaborate responses! I noticed that many of the answers are focused on project delivery and software development. I am not sure if it makes a big difference, but we are something like business developers and our daily objectives are measured mainly in financial metrics (though some of the ways to develop revenue are longer term plans, however with daily milestones).

Generally, my individual team members have a certain degree of autonomy in terms of "How" to achieve something, but not "What". For example, our objective for a day may be to generate X leads in market sector A. Everyone is working hard until late in the afternoon Mr. Know-It-All spots some potential clients in sector B. He is driven about getting them. Of course it would be rewarding to get those as well, but if we wanted those clients right now, everyone on the team would need to focus on it to make sure the process is well coordinated (Or Mr. Know-It-All gets to stay until midnight!).

There are times in which upper management might be happy that we got more sales through sector B, but often they don't take into consideration that this may cost some peoples' sleep time..

Answer 1

Sometimes people in my team (including a Mr. Know-It-All, as he is often leading the revolutionary charge) come up with some really good ideas or valid criticism.

This is a good thing, right? :)

If they require very little time and I think they will add value without affecting the rest, I say go ahead and do that, great job!

However, putting them into action would require drastic changes to the daily work plan or weekly schedule, and sometimes may stir conflict with upper management strategy.

Don't do that. As Tim Peters said:

Now is better than never. Although never is often better than right now.

The "go ahead and do that" should only be a valid answer if their current task/agreed deliverable cannot be completed until the new proposal is implemented.

Normally, when you get ideas for changes, they should be placed into a feature list. This list should be split in a way that makes sense to you / your customer / your team and that provides insight into your planning process (e.g. "must have, nice to have, propose to customer, nice but no thanks" or "for this week, for this month, for next release, not in scope").

My immediate concern as soon as they enthusiastically advertise their plans is that with our current workload (which is borderline with burned out!),

That's an alarm signal right there: "borderline with burned out" means that your team will get burned out sooner or later (it's just a matter of time) and with schedules like that, you will have scheduling problems when people go on holiday. On top of that, you never use them at their potential or full capacity (because a bit of their daily effort and focus always goes on handling stress and pressure and compromising due to that).

Usually we plan tasks for 6 work hours per day. This means 8 hours+ in office, but the daily task list is shorter. In practice, the two extra hours are glue tasks (mental context switches, exchanging information outside meetings, seeking through documentation, reviewing code before commits, reporting progress, and all that stuff).

considering or even suggesting those ideas to upper management sometimes carries the risk of stretching the team and force us to work until late night just to evaluate whether we should try out that idea.

Two things here: First, set time aside for planing (after hours is not time for planing, it is time for going home). I have ~two hours with my manager every week just to talk about how my week went (what took longer than expected, blocking issues, prioritization and what to do different next time are all part of that). I also have one day every three weeks that is for splitting my work into tasks, prioritization and so on.

Second, proposing tasks to management should be done with a cost analysis (instead of saying "we can also do the teleport feature" you should say "we could also do the teleport feature with an estimated effort of two man-weeks; if we squeeze it in the schedule, we must either postpone full delivery by two weeks or descope something else worth at least two weeks of effort").

We are usually expected to work a little bit late if we need to meet our daily objectives, but formulating new ones means being exhausted and stressed the next day.

Sounds like you need to redefine your daily objectives to me. Formulating new ones should be done on company time. Expecting developers to work for 8 hours on development tasks exclusively is unrealistic (just like expecting someone to put in 24 hours of work because they have a 24 hours day is unrealistic).

Am I right to dismiss or postpone ideas based on workload schedule priorities?

Don't dismiss them. Place them in a list (see above). That list should always be kept up to date and revised periodically (the opposite of dismissed :) ). Some items will be scoped in, other can be used to avoid pointless discussion (having a section in your meeting minutes saying "teleport feature: we will not develop the teleport feature in this release because the effort involved is unrealistic" will minimize developers reopening the discussion about implementing it every week).

Answer 2

Am I right to dismiss or postpone ideas based on workload schedule priorities?

Of course.

Ideas are great. But as the Manager, you must consider all aspects of ideas - the viability, the potential upside, the potential downside, the cost, the timing, the political impacts.

Some ideas will have terrific potential, be simple to implement, and will sail through upper management approval.

Others have little potential, are overly burdensome to implement, and have no chance of gaining management agreement.

And most will be somewhere in the vast middle.

As the Manager, it's your role to carefully filter through these ideas, implement the easy high-payback ideas, reject the burdensome, low-or-no-payback ideas, and weigh the remainder - all while considering the rest of the work your team has on it's plate.

Try to find some quick wins as a way to help your team feel good about themselves, and encourage more idea generation. Thank and reward the team for a great idea.

And even when you decide that you might need to reject an idea, find a way to thank the team for coming up with a good idea - even if it may not be practical or realistic to implement it. An idea can still be good even if "now is not the right time and here is not the right place" - if you see what I mean.

And you will find some ideas that will be very difficult to implement, but still have enough potential and upside that the are worth a struggle. These can be the really big wins.

It's wonderful to generate ideas. "Unlimited vacation policy", "Let's all have offices rather than cubicles", "Lets double our team size and stop working overtime". And ideas are fun to generate. But the real key, and the real difficulty, is in the implementation.

Answer 3

Am I right to dismiss or postpone ideas based on workload schedule priorities?

Be careful with dismissing ideas immediately, otherwise the team will very quickly learn that there is no point in coming with new ideas. And you don't want that to happen.

Postpone; Of course. But I would suggest consider adding it to your plan instead. If you are working agile, you should have a retrospective at the end of every sprint. Then suggestions for improvement should be brought up. Make sure you add those to the planning of the next sprint, but you must also take the workload into consideration and make sure you move something less prioritized to a different sprint.

If you are working more traditionally you could still apply the same principle. The important part being to add the improvement suggestions to the plan in a controlled manner.

We are usually expected to work a little bit late if we need to meet our daily objectives

This sounds very worrying. If you are expected to work extra all the time then something is wrong. The expectations of the team from upper management seems to be wrong, or your team are doing things outside their scope. You should start looking into this, because the way you describe it its not feasible in the long run.

Answer 4

It is your job as a manager to consider the schedule and the current deliverables when evaluating new ideas. And yes much of the time, you have to say "Not right now." Your company expects you to produce the product they asked for in the timeframe promised. It doesn't expect you to produce the product they asked for with extra bells and whistles especially if that makes the delivery late. It doesn't expect you to say, "Well we had this working but we decided this other idea was better at the last minute, so we redid it and missed the deadline."

Now developers love to do fun tasks and stretch their imagination, but you can't risk the project over that. You can however do a better job of planning to allow for ideas to be implemented.

First, the time for new ideas is at design time. Don't skimp on designing in order to get right to building and you will have fewer good ideas come up when you are 85% done and it is too late to implement them. So in your planning allow more time for design. The development will take less time if you talk out the various ideas in the design phase and really have a firm commitment to what you want to do and know the pros and cons. Design can include a bit of prototyping. It can even include two people prototying their different ideas on how to do the same task.

You need to explain to your team that design is the right time for ideas unless something is a showstopper. Ideas for future features can be brought up at anytime but will be put on a list for a future release. New features will need approval of the client or the management team. The people paying for the development always need to have the final say on new features.

It also sounds as if your team is a bit out of control, they should not have new plans in the middle of a realease. They need to be educated on the way projects need to work to satify the eventual client not their desire to play with new things. They sound pretty unprofessional to me and you need to educate them on how to be professional. Professionals know there is a time and place for new ideas and at the end of cycle is not it. I'm all for new ideas and I think that the devs should come up with a lot of good solid solutions or you shouldn't be keeping them on. But the time for such things is at the beginning of the cycle. Once you are committed to a path, you can't switch unless it becomes clear the chosen path will not work.

Another management technique you can use is to allow some time in the schedule for people to work on their own and come up with new things or refactor code to use better techniques. If you give everyone 4 hours a week to work on what they want, that can go along way towards making people happy.

However, you can't do that until you refocus your own scheduling and stop committing to deadlines that can't be met without overtime. It also may or may not be possible depending on how the funding for development is done. You can't do this without senior management buy in. If your work is 100% funded by clients on direct project work, this is a lovely pipe dream, but not going to happen. If you work in a shop where you are producing products for later sales but not for specific clients, it might be possible. If you are in a shop where your only clients are internal, it also might be possible. It isn't an easy sell either, so you really need to practice your salesmanship and play the office politics game to be able to get this sold. (You are a manager now, so you need to learn how to effectively use office politics or you will not be a successful manager.)

Refactoring is great too (and can probably be used to implement some of these great ideas that come up too late for the release) and if you can plan the occasional refactoring release that could be a good time to do that. But you can't effectively refactor without a solid test suite. You don't want to break something that currently works by refactoring. So if you'd like to plan for some time for refactoring, you have to get the testing piece in place first. Again you are going to have to sell management on this idea as they are paying for it. There is a lot of detail around the web and in books on why refactoring is good thing, so you need to do your research before you propose this to higher levels of management.

Answer 5

Balancing things here is the challenge before you. On the one hand, there is something to be said for how much time should the team have to develop new ideas, experiment with new technologies and find new ways to do things. On the other hand there is what has to be done to keep the company going and ensuring that people can be paid and upper management is happy.

Taking the workload into account is fine though I'd argue be careful of what you tell the team as while you may postpone now, if months later the team asks for an update only to get a, "Huh? You want an update on what was that?" you run a real risk of losing credibility with the team in terms of taking what they bring seriously. Dismissing ideas as, "We don't have time for this, ever," is also not likely to go over well, so be aware of how you want to handle the fact that the team may have a great idea if they want to bring in some new process that would help move things forward in terms of improving quality or productivity,e.g. bringing in continuous integration or doing code reviews.

Answer 6

Part of me swears you are talking about me with the Mr. Know-It-All.

Sometimes people in my team (including a Mr. Know-It-All, as he is often leading the revolutionary charge) come up with some really good ideas or valid criticism.

If they require very little time and I think they will add value without affecting the rest, I say go ahead and do that, great job!

This is great, but how is it impacting or improving the business should be the first questions. How will it ultimately make you, and your team, better? If it doesn't, don't waste your time. If it makes you better in the long term, go ahead.

However, putting them into action would require drastic changes to the daily work plan or weekly schedule, and sometimes may stir conflict with upper management strategy.

I would avoid situations like this. The employees need to know that getting the work done is the #1 priority and #2 is making it easier, better, more fun to get the work done. If they can accomplish their tasks, on time, and do these other things than great. If not, the tasks are the first priority.

My immediate concern as soon as they enthusiastically advertise their plans is that with our current workload (which is borderline with burned out!), considering or even suggesting those ideas to upper management sometimes carries the risk of stretching the team and force us to work until late night just to evaluate whether we should try out that idea.

These plans should not be discussed until a small scale test and a proof of concept has been created. I am constantly building new better ways to perform my daily tasks and those of my peers. 99% of the time no one has a clue of what I am working on until AFTER I have at the very least a small working sample that will demonstrate the idea. Also, I do all of this work for these POCs in my personal or spare time. Again, work comes first.

We are usually expected to work a little bit late if we need to meet our daily objectives, but formulating new ones means being exhausted and stressed the next day.

What would you do in a situation like this?

Explain to your team that you thoroughly appreciate the fact that they are working hard and working even harder to make everyone's life easier. That you love the fact that they are all team players. But you worry that they are over working themselves and by going to senior management with such plans creating too large of a workload.

If someone wants to create proof of concepts to demonstrate in their spare time, they have your blessing. But that your main concern is for them and that they have enough time to enjoy their life as well as their work.

Essentially, don't say "Hey, stop this". Say 'Hey, I am on your team and worried about you. All the stuff you're doing is amazing but let's put some emphasis on having a nice life-work balance.

Am I right to dismiss or postpone ideas based on workload schedule priorities?

This depends on the ideas. If they are something that will drastically increase productivity, impact your current scheduled tasks in an extremely positive manner or overall make your team better, no. Otherwise, yes.

It seems you are trying to look out for the best of your team members. Have a meeting with them and explain that to them. If they want to work a ridiculously crazy amount, tell them they are free to do so but to keep your plans private and prevent it from being a requirement until they are nearly completed.

Answer 7

For example, our objective for a day may be to generate X leads in market sector A. Everyone is working hard until late in the afternoon Mr. Know-It-All spots some potential clients in sector B.

I recently had someone that was consistently branching off from their assigned tasks. The areas they were going into were legitimate areas to cover; however, like you, we have goals and need everyone staying on target with what we are actually doing.

A minor example: this person began reworking some of our marketing material then presented that to me for consideration. The quality of the material doesn't matter. What matters is that the tasks assigned to this person weren't being completed.

This person's direct manager and I both spoke to them on several occasions about staying focused. They would say ok, and within a couple days the problem would start again.

The final straw was when this person chose to bring solutions to imagined "problems" directly to me, instead of the manager, about things that, again, were completely outside of their area of responsibility. First off, there is a clear "chain of command" with our organization it exists because we are small and everyone is incredibly busy. More importantly though this person caused delays in other areas because their assigned tasks were ignored. So I took the only path left available to me and I terminated them.

================================

Here's the thing; when I hire someone for a position I need them to stay focused. If it's a developer and I ask them to put together a website with a contact us form, then I expect that task to be accomplished. If they have ideas on how best to make that happen then go for it. However, if they decide to go off and build an ecommerce platform (perhaps they thought we needed one?) instead of working on the assigned task then one of two things needs to happen. Either a stern talking to about completing their tasks or simply replace them with someone that will actually work on their assigned tasks.

I don't mind, and actually encourage, out of the box thinking. I even like someone helping out in other areas... as long as I know what's going on before hand and approve of it.

the tldr; version: if Mr. Know-It-All consistently ignores the actual tasks and does whatever they want then it's probably time for Mr. Know-It-All to find another place to work before your team becomes completely unmanageable.