Creating Smart Team Members
S.M.A.R.T. might be one of the most over-used acronyms or descriptors in the US. Goals, criteria, objectives; they can all be smart. TVs can be smart. Toasters can even be smart. Smart is unabashedly associated with things to make them sound improved. Everyone agrees that smart is better than not smart. In the context of team members, smart is sometimes considered a trait one is born with or not. I don’t put much stock in what you’re born with. Talent gives you a head start, but tenacity wins any race that matters every single time.
On teams that I have any influence over, especially in a leadership role, I’ve used five criteria to analyze any failure of a team member to make sure that I’ve not set them up for failure in some way that could have been avoided (and can be in the future). Fortunately, with only a little effort, we can again use the ever-present S.M.A.R.T. acronym to help improve retainability and organization of thought. In order to accomplish anything, a team member will need:
- Skills/Training
- Motivation
- Authority/Access
- Resources/Tools
- Time
That’s likely not profound to you, but taking that perspective in the face of a team member’s failure and figuring out how you might have failed to provide what they needed in one of those categories can have a very crystallizing effect on how best to move forward.
Skills and Training
Did I make sure the team member had the skills and training necessary to achieve the goal?
Duh, right? Well, in the past I’ve made two critical mistakes in this area. On the one hand, I’ve assumed that making training material available is the same as training someone. Secondly, I’ve assumed that if something works to train one individual, it should work to train all individuals. Rookie mistakes, but easy ones to make. We all have a model of the world in our heads with certain gaps. It’s easy to assume that A) people are willing to put work in to fill those gaps and B) that they are the same gaps that need to be filled in a given setting.
Let’s say our goal is to nail a nail into a 2x4. Our team member is not going be able to accomplish our goal without the necessary understanding of what a nail is, what a hammer is, how you hold both of them, how to swing, so on and so forth. It’s so easy to make assumptions in this area about what a person should and shouldn’t know and how motivated they might be to dig through material to fill in the specific gaps of knowledge they have in this area. So, there’s this balancing act here. If you undertrain, you communicate that you should know everything I’m not telling you and I’ll be disappointed if I find that’s not the case. If you over train, you communicate that you think your team member is an idiot that doesn’t know even the basic things they should.
The first crucial element here is creating an environment in which it’s ok to admit you don’t know something, even if it seems like everyone else does. Identifying mentors is a no-brainer, but what about making sure those mentors don’t make other people feel like idiots when they have questions or don’t get it quickly. Humble and Expert don’t usually go together, but if you’ve got one or two of them, leverage them heavily.
The second crucial element is making comprehensive material available that is heavy on things you can’t possibly know without being told. These are the things you totally take for granted two months after being on the team. Seriously, create a freakin’ wiki. Some repository of shared team knowledge and make the team sit through a review of it monthly (which should force you to keep it concise). Make it a party. Better yet, make it a drinking game. For every out-of-date entry someone finds, everyone else has to take a drink. That’s a bad idea, don’t do that.
Questions to ask could include:
- Is there information that you can only find out by asking specific team members?
- Is there one or two people that always have to be around or else X can’t happen?
- Are there people on the team that are experts in the tools you’re using that are willing to humbly help others?
- Do you praise people who admit they haven’t caught up yet to what you’re saying?
Motivation
Did I provide a meaningful and lasting motivation to the team member?
Man, this is tough. If I wasn’t constrained to making these spell SMART, I’d use SARTM instead so the hardest one could be last, but alas, that’s not an option.
Motivation means so many different things to different people. Motivation has also changed as industries have changed, but here’s one thing most people seem to agree on. Money does not equal motivation. In fact, in some cases, more money actually decreased the capability to execute. Open source is a good example of people being highly motivated in a money free environment. Money will get someone out of bed every day to show up, but it’s not enough to meaningfully and lastingly get the best out of your team members. Daniel Pink explains this perfectly. Things like autonomy, mastery of a craft, being a part of something bigger than yourself, those are the things that meaningfully motivate people for the long haul. That nail isn’t going to get nailed in if the person holding the hammer doesn’t want to hammer. Worse yet, maybe they’ll find a way of making it look hammered in without putting the effort into hammering, which could be far more dangerous.
What you measure is a strong communication of what you value. If you’re not measuring anything on the team, well, then that’s another discussion. Start doing so, ideally something that is actually of value to someone who is important to the team. Then, put that measurement in front of the team’s face almost unavoidably. On the door to the office or back room. On the fridge maybe. Somewhere that it can be seen without being sought. If it’s digital, all the better. Then, give the team member a concrete way that they can move the measured metrics by contributing to the team each day (yes, day). Sounds so simple, but this one discipline of team leadership can turn a cancer-ridden team of grumbling compliers into a team of laser-focused motivated partners.
Questions here are things like:
- How can I help this person be the master of their own fate?
- How can I get out of the way of this person achieving their goals?
- How can I help this person become an industry expert?
- How can I make sure this person is using the latest tools that have made things so much easier?
- How can I connect this person’s activities concretely to the goal of the group?
Authority and Access
Was my team member empowered to make decisions they needed to in order to avoid failure?
You can’t hammer in a nail you can’t get to, amiright!? There’s so much material out there on the value of empowering your team members to make decisions in real time. Nordstrom’s is a famous and excellent example of employees being empowered to make the decision they believe to be right on the spot. If you ever hear a Nordstrom’s employee say, “Uh, I’m sorry but our policy won’t let us do that”, you’re talking to an employee that doesn’t have a future there.
This is tough because it requires you to trust your team members. It also requires you to actually give them the power to have a negative impact on your goal. Can you imagine? It’s so easy to feel like everything must be under your control in order to make sure it all goes according to plan. No latitude, no mistakes. In an attempt to reduce all risk, we can sometimes reduce all momentum. A car not moving is highly unlikely to get in an accident. True, you also won’t get anywhere, but at least we’re safe!
Granted, trust is going to be based on the capability and intent of your team members long term, but do you give them the benefit of the doubt up front? Do they have access to all the hammers and all the nails or do you make them sign out a hammer and assign them a specific nail? If they lose that nail, do you make them fill out forms explaining what happened before they get a new one? I know, you happen to be in the one situation in which you have no choice, but maybe challenge that constraint a bit and see if it’s malleable.
When access and authority issues come up, squash them FAST. Put something in place to make sure that kind of access or authority issue won’t come up again. Create a culture of true empowerment where being proactive is rewarded regardless of the outcome. Yea, you screwed up, but you tried. You just paid someone to learn a valuable lesson. Consider it an investment in future success.
Some questions to ponder:
- Do I express an environment of trust as much as I’m capable of in our team’s context?
- Do my team members have the freedom to make decisions without consulting someone else?
- Do my team members have to come to someone to get something they need?
- Do I punish team members for being proactive when the results are negative?
Resources and Tools
Was there a material or tool I didn’t provide that could have enabled success?
Someone on your team (hopefully) has their finger on the pulse of the toolsets out there that enable more attractive effort to value ratios. If not, you have a mixed blessing. On the one hand, no one’s going to be whining about not getting to use the latest tools for their job. On the other hand, you could be missing massive gains in productivity. How tragic to not know there’s now this thing called a nail gun.
Keeping up with tooling and resources is hard. Especially with how fast things are moving these days, by the time everyone is up to date and the environment is steady and ready for rock solid work, it’s time to upgrade all your tools. Annoying. Well, yet again a nice balance brings us value while either extreme is going to keep your team member’s contributions mediocre.
People who are passionate about knowing the latest toolsets out there are going to tend to want to switch too frequently. This robs you of the stability and investment in streamlining processes that you should be getting from established tooling. Not a problem too many teams have I’d wager. On the other hand, waiting until the world agrees on what the best tooling is before making the switch, or waiting for the next release which is bound to be better than this one, or worse yet, sticking with this one because it works and if it ain’t broke… ah, a great justification for stagnation. Finding that right balance of updating or changing toolsets as your industry or problem space evolve is beauty.
Some interesting questions might be:
- Are we using old tools for fear of destroying our repeatable process?
- Are people frustrated that they use better tools in their own time than they do on your team?
- Are tools and resources left unused because of mismanagement on your team?
Time
Did my team member have a reasonable amount of time to accomplish the goal?
Man, it’s so easy to establish timeframes based on nonsense. Or in a vacuum. Once a timeframe is established it takes on a life of its own. It somehow becomes etched in stone once it’s on a PowerPoint or passed around in a few e-mails. All of the sudden, it’s the Date By Which It Must Be Done. Why? Because it is.
In any team effort, there is that which is seen, and that which supports what is seen. In building, the frame of the house is the unseen while the beautiful roof, brickwork, and interior are seen. When team members are put in a situation where they don’t have the time they feel is necessary to do a good job, it’s the unseen that suffers. In house construction, this would be catastrophic and we have many processes in place to make sure that never happens, but in other industries, the cost of sacrificing quality in the unseen is less measurable and usually less fatal. So, it’s not so bad. Until it becomes bad. And when it does, it usually becomes really bad.
Give your team members real input into the time it’s going to take them to contribute meaningfully. I can’t enumerate the positive aspects of doing so. Buy in, empowerment, accountability, the list goes on and on. Let your team members contribute to the time frame they are going to be held accountable to. Don’t make excuses. You’re investing in long term failure with the currency of short term success to do otherwise. We’ll do it right later is the most prolific and insidious lie to be consistently believed. Fight for this principle against all who would try to dictate scope, timeframe, and resources without team member input.
Some questions that might bring clarity:
- Am I dictating the time-frame a job must be done in without being a subject matter expert?
- Do I constantly question the reasonableness of team member’s estimations?
- Do I find myself apologizing to my team members because they can’t do their job well?
Conclusion
Well, we did it. We spelled SMART. I have found that I can usually categorize a team member’s failure (or my own) into an issue with Skill/Training, Motivation, Authority/Access, Resources/Tools, or Time (or multiple of the above). It takes discipline to approach failure as a partnership in identifying what was lacking in one of these areas, and humility to take ownership of trying to provide it, but time and time again I’ve found it fruitful. Eventually, you might find that a team member can no longer point to a way in which you’ve failed to provide in each of these areas, and at that point it’s time for them to move on. You’ll both agree that they’re on the wrong team. But until then, this might be a helpful toolset to allow for a discussion based on a common lexicon that let’s you take your team members to the next level.