How to Set Your Team Up for Success

Have you ever been part of a successful team and a failing team? I have, and I’m guessing you certainly have, too. Have you ever led a successful team and a failing team? I also have. You may also have, too. But perhaps most importantly, have you ever stopped and pondered the differences between those teams, and what drove the better ones towards success?

Well, we could talk about all sorts of teamwork and leadership stuff right now. But instead, I’d like to focus on what I’ve personally observed to be the core ingredients when you’re setting up a team or a person or a project for success.

Wait – What if you’re not a leader or you’re not setting up any teams? What if you’re just part of the team, or you’re the entire team of one? Then you should still keep an eye out for these ingredients and work closely with your leader to ensure that he or she puts them in place so that you can be successful together. Engage in the dialogue to maximize your opportunity for collective success.

Core Ingredients to Enable Team Success

So here are my core ingredients for setting your team up for success:

1. Plan
2. Requirements / Goals
3. Time / Schedule
4. Budget
5. People
6. Knowledge / Experience
7. Tools / Equipment

What’s interesting is that these ingredients apply in varying degrees regardless of the type of team. It could be a sports team. Or a project team at work or on the volunteer organization you’re part of. Perhaps it’s a team of one, just trying to get some work done for the boss.

What’s also interesting is that #2, 3 and 4 form the classic quality (or scope) / schedule / cost triangle of project management. This is otherwise known as “good, fast, cheap: pick two.” There are almost always trade-offs to make in this department.

These trade-offs are necessary because in the real world you will never (or almost never) get all of these ingredients in the perfect mix. But you can still be successful even if some are absent or lacking, although that makes it harder. When most are absent or lacking, though, that’s what I call failing to set your team or yourself up for success. In those cases, you need to rethink your priorities and adjust your expectations.

At first glance, this list seems pretty obvious and self-explanatory. But as is often the case, it’s still important to reflect on the ideas to ensure that you can implement them as needed. So let’s go through and check out each of these ingredients more closely now.

Plan

The plan forms the cornerstone of what you do. I am personally a planner by nature. But plans themselves are not the panacea. I’m sure you’ve heard of these two popular(?) sayings:

Men plan and gods laugh

and

Plans are absolutely necessary but ultimately useless

What does that all mean? Well, it actually ties in with the owl analogy from my talk back in October. You need enough of a plan to know where you’re going, and it needs enough detail to map out the short-term steps, and enough flexibility (read: deliberate lack of detail) to roll with the inevitable punches and surprises that will come up along the way.

So create your plan, but also document it and communicate it to the team. Discern and then include the appropriate mix of high-level direction, detailed instructions and systems, and allowable (contained) chaos and uncertainty. Then revisit it on a regular basis to adjust and adapt as necessary.

One big advantage of creating a plan, no matter how good of a job you do, is that it forces you to at least think through the rest of the ingredients on the list. Even if you get it wrong, at least you’ll have a record so you can improve next time around.

Requirements / Goals

Unless you’re deep into the field of Systems Engineering*, requirements are pretty much the same thing as needs. Or goals, or success criteria. Or “what are we trying to actually do here?” Also known as the “there” in the “here to there” challenge stated in your plan.

*I am actually deep into the field of Systems Engineering**, and could talk your ear off about requirements decomposition and bidirectional traceability and the difference between verification and validation. But I’ll spare you. Unless you’re also a Systems Engineer and want to chat!

**Note I said Systems Engineering, not computer systems. Many people get that confused, so read up on it if that’s you too.

In other words, how on earth can you decide what you’re going to focus on and work on if you don’t have at least a somewhat clear indication of what you’re trying to accomplish? The neat thing about requirements is that you can think of them from all sorts of different perspectives.

Let’s take an obvious sports analogy: Your requirement as a baseball team is to win the game by scoring as many runs as you can and by stopping the other team from scoring runs. But your main requirement as a left fielder in the 3rd inning is to catch the ball and get it into the infield as quickly as possible.

So, your team needs clear goals and targets. And then depending on the maturity and experience of your team, along with the complexity of the task(s) at hand, those goals and targets may need to be further broken down into bite-size chunks.

Time / Schedule

You need to schedule yourself and the team an appropriate amount of time to accomplish the job. Now, “appropriate” is different according to everybody in every situation, and will also differ based on the maturity and experience of your team. But you should know at least at a high level what the difference in time is between a realistic schedule and a “success-oriented” schedule in your specific case.

If you’ve never heard the term “success-oriented” schedule, let me educate you: It should really be called a “failure-oriented” schedule. It’s the schedule created under the assumption that nothing will go wrong. It therefore has no opportunity for recovery. No buffer. No contingency. And it therefore provides a correspondingly rock-solid guarantee that your team will fall “behind schedule”, which will result in rushing and errors.

If you want to march ahead at risk of blowing through your schedule, at least do so deliberately and with full knowledge of what an appropriate schedule would be in your particular situation. Don’t be fooled into thinking an impossible schedule is merely just a “challenge”. But at the same time, don’t be so generous with your schedule that your team starts to slack off or get distracted.

Budget

Every team and project has a budget. It might be explicitly stated in terms of dollars or pounds or bitcoins or gold coins or cows or donkeys. Or it might be implicitly given by the number of hours you are afforded to get the job done. Regardless, budget is like schedule. You need to find the balance between too much and too little for your specific situation.

But beware: If you cut too much, there won’t be anything left to actually do a proper job, as Dilbert so eloquently shows us here.

People

This category could go in a million different directions and have a million different sub-categories. But what I am specifically referring to in this case is simply getting the right amount of the right type of people for the job.

You don’t want too many cooks in the kitchen, but nor do you want a leaderless herd of cats. So think about the organizational structure your project or team needs, and what type of people with what characteristics would work best.

Pay attention people’s attitudes and aptitudes, and then build the most appropriate team. You’ll need a mix of doers and leaders, those with initiative to figure it out, and perhaps those who love to be given a simple or repetitive task.

One of my favourite models is this quadrant below, that I first talked about in my hypocrisy article. Stay in the top half, and then try and get a good balance left-to-right.

Knowledge / Experience

Knowledge and experience are tightly coupled with the “people” category, but they’re important enough to warrant their own little section here.

You see, not only do you need the right people with the right attitude, but you need to make sure that they know how to do the job. Or at least that they can quickly figure it out. So make sure that you have some folks with solid experience. And then train or teach the rest.

Side note: Some folks view training as an expense and some view it as an investment. I’m in the latter camp. Don’t be afraid to be constantly learning, but make sure that you are also constantly applying what you’re learning. Otherwise training will start to become just an expense. Perhaps the folks in the first camp are just jaded from poor experiences and poor returns on training investment? Let’s work together to prove them wrong.

Tools / Equipment

You’ve planned it out; found and trained up the right people; given them time and money and goals. But if you don’t also give them the tools and equipment that they need, they likely won’t be able to perform.

For example, this could be mean ultrafast computers. (Or just simply internet-connected computers, like we needed special permission for about 20 years ago.) Or special software. In some cases, they will need machines and robots, or better IT support systems. Or maybe you just need to reorganize and redistribute your existing tools. For example, one of the things we did when we turned the pool around was to clean up our online network drive so that we could easily use it and keep appropriate documentation for the next group.

In Summary

So that’s the framework. I know I used the word “appropriate” a lot. That’s because you need to understand what you’re trying to accomplish, and how all of these core ingredients come together in your particular situation. And you’ll probably get “appropriate” wrong, or be unable to get it right due to other constraints, but you’ll learn and do better next time.

None of this is rocket science. I had a recent coaching session on this topic with an undergraduate engineering student, and he was able to nail most of these points with just a little guidance. As I mentioned above, the key is to stop and think about it, and write it down. Be deliberate about your choices and the risks, consequences and rewards that will ensue. Because if you don’t at least think through these elements and try to make headway, you’re likely just setting your team up for failure. Not success.

Your Turn Now!

Do you agree or disagree with my list? What would you like to add? Do you have any experiences that you’d like to share?