As your business grows you will, at some point, be faced with the decision to make a change from managing just yourself to managing a team. If that scares you stop the growth curve and be happy with running a solo business.

For those that choose to move to a team structure, you no longer just have to manage your own effectiveness (productivity) but you have to manage the effectiveness of your team as well. That introduces a whole bunch of new variables totally outside of your control, like the health of an employee or the expectations of their spouse/partner.

In talking with business owners, here are some of the things I see that can hinder the effectiveness of a team.

Unclear Priorities

Sure, the owner or project manager knows the priorities for a project as communicated by the client, but were those priorities actually communicated to the developers/designers?

Often they aren’t. The PM just posts a list of tasks in the project management system of choice and figures that would be enough for the team to see the vision.

It’s not enough at all — and the only one to blame for the lack of shared vision is the individual who talked to the client and won the project. So when your team is trying to decide between option A (which will take longer and cost more but is good for the users) or option B (which is faster and costs less but won’t be as great for the users) the decision isn’t based on guidelines for the project.

Is the project focus on getting to market fast or on having that user experience apple as polished as possible? Either option is totally valid.

This type of fork isn’t unique to ‘big’ decisions either. It happens in every little thing, all day, and each decision that deviates from the project focus pulls the project further away from an end result the client will be happy with.

To combat this I always write up a project plan which we continually refer back to as we make decisions. Making this document available to all team players and referring to it regularly is a key way to make sure that each decision is in line with the project goals.

Weekly Recaps

I’m a big advocate of a weekly review and when you have a team there should also be a weekly review with the team.

This weekly review should consist of a look back at the tasks that have been completed and compare those with the tasks that were scheduled to be completed in a week. If people are getting stuck find out why. Maybe you have someone weak on JavaScript assigned to a heavy JS project simply because they were available when the project started.

If so, take the time to assign someone strong in JS at least for a bit to help keep the project moving forward.

The goal here is not to find out where people are sucking and then get angry at them for not accomplishing the goals for the week. The point is to continually get a better handle on how much work can actually be done in a week and assign people based on their areas of strength.

Way too often projects end up in scramble mode because regular project recaps weren’t done, so no one noticed things were headed off the rails. Everyone simply assumed that everything was ‘good’ yet a 30-minute meeting once a week would have told them that clearly things were not good.

What do you need from me this week?

Tying in closely with the weekly review is how you end each week. For a long time I left it up to my coaching clients to reach out to me with any issues they had during the week or to ask me to follow up with them on a specific day if they needed it.

Nobody did, but that wasn’t because they weren’t having problems, it was because they didn’t want to bug me. They knew I was busy just like they are and didn’t want to ‘burden’ me.

In reality, the fact is that they were paying me to be available for interruptions.

Now I end each coaching call with “What do you need from me in the next week?” and guess what — all of them have something they need from me in the next week, every week.

Usually it’s just a simple follow-up on a task part way through the week to hold them accountable, sometimes it’s a bit more, but changing how I framed this made a whole world of difference in how they viewed my availability during the week.

[Tweet “Set the expectation that your team will need something from you each week”]

Take this to your team. If you’re managing a small number of people ask each of them what they need. If you have many teams under you, ask the team leads what they need this week to be successful.

Expect the team leads to ask each member of the team what is needed to make them successful. People have these needs, but are often too scared of looking dumb to ask for help.

When you set the expectation that they’ll need something from you they feel free to actually ask for it without fearing they’ll be seen as needy or dumb.

Solving next year’s problems

I’ve got a problem common to most developers, which is seeing where we could have problems with the system we’re trying to build.

I recently had to build a search/email subscribe system. It’s theoretically possible that we could have millions of people subscribed to get email updates based on different search criteria and we could have millions of new submissions that need to be emailed a day.

In reality, it’s unlikely that would happen on day one, or probably even day 1,000, because of the price of the service and the market for it. It’s highly profitable but a small market.

[Tweet “Stop solving theoretical future problems”]

So why on earth am I trying to solve every possible problem that could come up in the project?

As you dig into a project set clear boundaries around the types of problems you’re planning on solving. Don’t solve theoretical future problems of scale. By the time the problem actually materializes, techniques may have changed and 90% of the problem may have been solved for you.

On a past project, I killed three days trying to solve a future problem before someone stopped me and asked me if the problem was real — and if not, why was I solving it?

During your weekly team recaps make sure you’re solving problems that are actually happening now, not theoretical future problems.

Controlling the whole process

Many managers/team leads have had bad experiences with projects not going well and missing deadlines, resulting in unhappy clients.

These managers often bear the brunt of that exchange leaving the developers/designers with little knowledge of the ugly details. The developers/designers only knew the client wasn’t happy.

It feels terrible to have an uncomfortable conversation with an unhappy client who clearly has reason to be mad, so to combat this the managers start getting more controlling. Not just checking in and making sure that things are on track, but daily or hourly checks on what’s going on. Copious status reports and forms, all in the interest of avoiding another conversation with another unhappy client.

These managers start micromanaging and making every decision for people, which only produces a team that can’t do anything if the manager isn’t watching. This just fuels the vicious cycle of not getting stuff done well without the manager being there. Oh and don’t forget the cost to team/company morale when treating adults like children.

[Tweet “Don’t micromanage your team. Train them to be awesome”]

To be clear, the individuals are capable, but have been taught that they shouldn’t be doing things without involving the manager, who then feels like he always has to be involved.

Typically this is a problem when you fail to do the things I’ve already talked about in this post. You never set a clear vision, or follow up weekly and asked your team what they needed.

The job of a good manager is to help the people in their care become their best selves.

Don’t micromanage your team. Train them to be awesome. Ask them what they need. Get weekly status reports and make sure things are on track. Adjust team allocation as needed.

Then let them work out the details because your team should be awesome.

photo credit: stavos52093 cc