In the previous post, I showed the Responsibility talent in examples. Now it’s time for my second top talent – Individualization.
Individualization as a programmer – 10 symptoms
1. Start with “why”
Before going into “what should we do”, you need to answer “what’s the goal”?
The problem and common misunderstanding are simple. Different people have different goals. I find it hard to start suggesting solutions before I know your pain.
2. Understanding business
I think I don’t have problems with stepping into someone else’s shoes.
I understand how the business picture us, programmers. I know why they may not like our attitude, and I know how to change it. Few ideas: refrain from technical language, focus on value, be predictable (how is another story), deliver in iterations, solve problems rather than move tasks around.
3. Importance of teams
If people were the same, there wouldn’t be any reason to form teams.
I like learning from other people. I love showing them my point of view and seeing the thought process and emerging ideas.
I especially enjoy working with people who are the polar opposite of me.
4. Attention to detail
I spot many little things that others may not pay attention to.
That could be details of other people or the projects (since projects consist of people). That, plus a constant reevaluation, can bring some problems. I can change my mind and my preferences too often for other people.
5. Define, pls
What is “quality” for your company? For managers, this could be a number of tasks done. For developers, this could mean test coverage. Two completely different metrics. If we don’t find a common ground, we would make each other’s lives so much harder.
There are many value terms that are used out there with no consideration. I opt for decomposing those terms or giving some examples.
6. “Strategy brought from the sky” anti-pattern
Once upon a time, the CEO descended from his ivory tower and said:
All right everybody, from now on, the strategy of our company is: efficiency, communication, transparency, and teamplay.
“Amazing!” – said nobody. In fact, nothing changed.
The vagueness of this “strategy” is one thing – see point 5. The other thing is where it came from.
I strongly believe that for a strategy to be effective, it should be the product of the whole group. Everybody should be engaged in creating it. Being able to add a value, remove a value, discuss or clarify a word. Only then it will be respected by the group.
7. Kink on “what differs us”
When it comes to defining vision. strategy etc. I look for traits that are really unique. “Teamwork” and “transparency” don’t speak to me. Too broad of terms. Everybody can write this.
On the other hand, think Arkency with their unique DNA. Some (if not most) programmers wouldn’t agree with it. And that makes it, first, interesting, and second, really appealing to all the programmers who do agree.
8. Awareness of information bubble
We would like to think that we’re on the same page with everything, but we rarely are. Everybody has a different perception. More or less different, but never the same as ours.
Luckily there are tools to address this problem. Overcommunicating, visibility, and techniques like pair programming and code review. All this helps in breaking the bubble and approaching “the same page”.
9. I don’t like giving advice
I can tell you how I did a certain thing. Or I can point you to some resources to learn from. I happily will (see, I’m a Developer too). But what works for you is beyond me.
Different people learn best from different resources. You do you.
10. No silver bullet
Everything has pros and cons. I often point out the cons not to criticize, but to make sure everything was taken into consideration.
I would love everyone to keep that in mind when making decisions. I like the idea of keeping a simple decision log in GitHub, just to state the context clearly.
Summary
The shortest summary of the Indie 😉 trait that I can think of is:
impatience with generalizations
That’s me. I’m an anti-fan of generalizations (see Black Swam book). You could read in this post how generalizations can trigger me in everyday programming work.
More Gallup
For the record, here are my top 5 CliftonStrengths themes.
- Responsibility – read more
- Individualization – this post
- Developer – read more
- Ideation – read more
- Consistency – read more
0 Comments
2 Pingbacks