This past week my company afforded us the opportunity to take a strengths assessment test, CliftonStrengths.
I've always been skeptical of these types of assessments as they have always felt like horoscopes. The responses are generic, and could be applied to any individual. However, CliftonStrengths had potential. Our leadership team had taken the same assessment earlier, and gave it positive reviews.
After taking the assessment myself, I can't say I really disagree with the results. The top themes, the individual remarks, and most of what was presented really hit home.
But what does it really mean?
The first important callout is that I feel CliftonStrengths is a poor name for the information that is being given.
Each of the 34 boxes, which represent a ranking from most talented to least talented, are really themes. A theme being something that you naturally do best. It does not necessarily mean that you are a poor performer for themes that are ranked lower, it just signifies it may not be natural to you, and requires an effort to succeed in that theme.
Put another way, a top performing salesperson could have Woo listed as number 34, even though that is what they do every minute, of every day, and excel in their role. At an individual level, each interaction takes a lot of effort for them to win individuals over, but they do it well. However, it's not natural to them.
That said it should probably be called TalentsFinder, but I digress. The results themselves are the fun part. Below are the first five themes that the assessment felt I was most talented at.
In your view, we are all in the same boat, and we need this boat to get where we are going. It is a good boat. There is no need to rock it just to show that you can.
This theme could not ring more true for me. Results are only possible when we resolve our differences, and we need to stop wasting time rehashing old disagreements.
The way forward is through compromise. Compromise leads to agreements, and agreements allow us to build on common ground. This allows us to focus on what is practical and promote adoption.
It takes many individuals to keep a company going, and not all of us share the same points of view. Not all of us do things the exact same way, but we should all have the same common goal. We should not try to impose implementation details, procedures, and processes onto others as long as the end goal is reached.
Being cognizant of how other teams operate and respecting their authority over their domain will lead to adoption of your own solutions.
You usually can sense how the conclusions you reach will emotionally impact individuals and groups.
This was another theme that I was expecting to be relatively high.
I find it hard to solve problems when I have yet to build empathy for my audience. If I can't relate to them, I will struggle to build a solution that I know they will like, and thus, adopt.
I tend to live by the words "people over technology". Put the people first, and the technology will follow. Which means I tend to make sure that people are cared for above all us, for example:
You mess with my team, you mess with me
I've always viewed teams as an extension of myself. If my team fails, then I fail. If you're inconsiderate to my team, you're inconsiderate to me and I am going to do something about it.
I was happy to see this callout from the Empathy section:
Act quickly and firmly when others behave in a way that is unhealthy for themselves or others. Understanding someone's emotional state does not mean that you must excuse this behavior.
As I have done this quite a few times in my career. If there is unjust behavior towards my team, I can't help but get involved and ensure they are properly represented. Typically conversations with upper management.
Many people are comfortable talking at length with you. Why? You refrain from interrupting them. Instinctively, you recognize that people feel most visible and valued when another human being puts everything aside to hear what they have to say
Another quote from the Empathy section that I hope rings true. Interruption is definitely always on my mind during meetings and conversations.
From my perspective, conversations are littered with interruptions; or at a minimum, a strong desire for the current person who is speaking to stop, so that they can speak. I see it all the time, through body language.
It's another way to state: "People often listen to reply, not understand"
I wish conversations were more around understanding and asking "Why?", to really understand a someone's point of view and feel where they are coming from.
I wish conversations involved making more of an effort to bring more people into the conversation. One of my favorite questions is "what are your thoughts?".
Through deep understanding of why people feel the way they do, and taking those feelings into consideration when designing our solutions, collaboration and adoption will only increase.
That's the goal, right?
This theme mostly speaks for itself.
Self improvement through education is something that I hold to high regard, especially in the technology scene.
The world is changing rapidly, and as they say, adapt or die.
You have a powerful ability to prioritize, set goals and work efficiently. You avoid time consuming distractions and stay on track toward an overall objective.
I see this theme applied to many areas of my day to day. From the theme description alone, "to do" lists are a critical part of the start of my day. I write down the tasks I want to get done, and expect myself to accomplish them by the end of the day.
The Focus theme is also probably why meetings drive me bananas.
Now to be clear, it's not so much the idea of meetings, as they can be immensely beneficial, it's how they are typically run.
Meetings should have very specific and deliberate reasons for being created.
What is being said during those meetings should be directly related to the reason for being created. For example, a meeting that is intended to serve as a status update is not a time to start talking about how a given solution works, a comparison of solutions, etc. It should be around the fact that you are still working on figuring out a solution, and call out any potential roadblocks that would impede progress.
A meeting without a defined agenda and outcome, probably shouldn't be a meeting
I can become quickly disengaged in a meeting that lacks focus and direction. If we're not working towards a solution and just talking to fill up the reserved space, we're just wasting time.
I love solving problems, working towards an end goal, but if no end goal is defined, it's hard to focus on anything because everyone is just talking about maybe similarily related topics.
While I may have digressed slightly on a meeting tangent, as I typically do, the concepts and ideals apply to any situation.
We need to be consistent about asking ourselves, does (insert thing here), bring value to our current objective? If it does not, why are we doing it?
I am reminded of the Focus theme every single day, which is most likely why it's rated so high.
The current objective, whatever that may be, should be our focus and it can be painful, almost in a literal sense, to not work towards it.
You can easily and quickly make judgments and create systems that are fair to everyone. As a result, others know what to expect from you.
I am a little on the fence about this result.
A large portion of this theme seems to revolve around the idea of fairness and consistency amongst people. Think police officers. A police officer needs to be consistent, because the law is the law no matter who you are.
While I agree that everyone is equal and special treatment is wrong, I wouldn't expect it to be so high up on the list.
What I can say, relating to consistency, is that I have an insatiable urge to keep user interfaces, interactions, codebases, etc consistent.
Why is one file in a codebase indented with two spaces, but another file, in the same project is indented with four? That bothers me.
Why does this project use a
create command, the other one uses a
build command, but the result is the same? That bothers me.
Why have we called a customer a business unit everywhere in this document, but here we decide to call it a tenant? That bothers me.
My first instinct when reviewing documents, codebases, applications, etc is to ensure that everything is consistent.
Consistency leads to ease of use, ease of use leads to adoption.
I have specifically mentioned it's one of the reasons why I love Go so much. The community has rallied behind a set of standards, which means that most codebases in Go all look the same. This approach makes learning new code bases almost trivial.
Reducing the ramp up time for getting new developers onto a project means they can contribute to the project faster, and add business value faster.
All said and done, I did feel taking the assessment did have value. It did not take long, around 20 minutes, and puts everything you thought you knew about yourself right in front of you.
It gave me an opportunity to take a step back, reflect on my perceived strengths, weaknesses, and passions to see if they lined up with what the assessment thinks they are.
For what it's worth, they say the real value add is around team interaction and design. Knowing who excels at what allows you to form diverse teams that includes individuals who bring different talents to the table.
It's an interesting idea. Without similar data, we rely on seniority and past performance which may not always produce the best teams.
There's a reason why "all star" teams in sports typically don't perform as well as teams that have chemistry.